Das Einrichten geht viel einfacher, die Beschreibung ist im Housekeepingartikel
Das Aktualisieren der IPAM-Einträge funktioniert weiterhin gut, und ich war eigentlich gerade dabei, das erste Ansible-Playbook auszuarbeiten, als ich gedanklich auf ein weiteres Problem gestoßen bin.
Beim Zusammenspiel von NetBox, Ansible und Technitium ist es notwendig, dass alle drei Beteiligten mit der gleichen Uhrzeit arbeiten. Soweit ich aktuell weiß, ist bei allen dreien intern UTC die gültige Zeit. Mir ist schon vor ein paar Tagen aufgefallen, dass die NetBox-Logs ebenfalls mit UTC-Zeit angezeigt werden. In Technitium habe ich bereits bei der Installation vor mehr als zwei Jahren die Logs auf Lokalzeit, also UTC+2h (wegen der besseren Lesbarkeit), umgestellt. Ich persönlich glaube jedoch inzwischen, dass es besser wäre, wenn alle Dienste die Ereignisse mit UTC-Timestamps loggen würden. Die Services/Programme, mit denen man später die Logs darstellt (z. B. Grafana), können dann die Umrechnung in die jeweilige Lokalzeit übernehmen. Das ist auch von großem Vorteil, wenn man Geräte in einer anderen Zeitzone hat (in dem Fall oft auch ohne Sommerzeit). Das Logging habe ich daher in Technitium wieder auf UTC zurückgestellt.
Als zentrale Datenbank für die Logs wird oft Loki/Alloy empfohlen oder der sogenannte ELK-Stack. Der ELK-Stack ist scheinbar deutlich komplexer einzurichten, wohl auch eher so ein Docker-Ding (Nachtrag: hier lag ich falsch, kann man genauso leicht installieren wie NetBox) (ich mag Docker einfach nicht), und da ich eigentlich viel lieber bei NetBox/Ansible weitermachen will, wähle ich den einfacheren Weg über Loki. Loki und Grafana gibt es bei den Community-Scripts als LXC, also muss ich mir hier wegen zukünftiger Updates keine allzu großen Sorgen machen. Ein sauberes zentrales Logging ist von größtem Vorteil zur geräteübergreifenden Fehlersuche und spätestens dann extrem zeitsparend, sobald ich anfange, andere Geräte via Ansible zu steuern. Von daher werde ich das Thema zentrales Logging hiermit vorziehen.
Ich installiere zunächst Loki und Grafana auf PVE und gebe ihnen, wie inzwischen auch dem NetBox-LXC, feste IPs. Die IPs dieser Dienste sollten sich nicht ändern können, sonst funktioniert das Zusammenspiel der einzelnen Dienste nicht mehr.
In Grafana verbinde ich zunächst das Loki-LXC als neue Datenquelle.
Es reicht bereits, die IP-Adresse und den Port des LXC mit Loki anzugeben, um eine Verbindung herstellen zu können.
Das muss ich natürlich später noch weiter absichern, aber zum Testen reicht es zunächst. Damit die Logs aber erst mal irgendwie in Loki “reinkommen”, brauche ich noch das Tool Alloy. Alloy empfängt Logs und/oder sammelt diese aktiv bei den hinterlegten Geräten ein und leitet sie anschließend an Loki weiter. Loki indexiert und komprimiert die Logs und regelt wohl auch das Aussortieren alter Logs. Alle drei Teile kommen vom gleichen Entwicklerteam, das sollte also gut zusammenarbeiten. Alloy ist weder Teil des Grafana-LXCs noch bei Loki dabei. Scheinbar hatten andere Leute bereits ähnliche Gedankengänge wie ich. MickLesk ist einer der Maintainer der Community-Scripts, und deswegen werde ich mich an seine Empfehlung halten. Ich hatte bereits überlegt, ob Alloy ein eigenes LXC benötigt. Erfreulicherweise ist das Nachrüsten von Alloy gar “nicht so deep”, wie man heute sagen würde. Es lässt sich mit einem simplen
apt install alloy
in dem LXC mit Loki nachinstallieren.
Bei der Installation des Loki-LXCs sind mir noch zwei weitere Punkte ins Auge gefallen. Man kann das Auswahlmenü mit
update
in der Shell des Loki-LXCs jederzeit erneut aufrufen.
Ich wähle beim zweiten Durchlauf auch noch Option 2, damit alle ankommenden Adressen ihre Logs bei Alloy/Loki loswerden können. Das werde ich in Zukunft vermutlich noch einschränken - als kleiner Reminder für mich selbst.
Bis hierher war die Einrichtung noch trivial, und ich wollte das Thema eigentlich in ein bis zwei Stunden abhaken. Ich musste dann aber doch fast zwei Tage meiner Freizeit aufwenden, um die Logs von NetBox in Loki zu bekommen. Ich stelle hier meine Konfiguration vor; sie lässt sich aber bestimmt besser einrichten als in meinem Beispiel. Für mich passt es aktuell, und ich kann das Logging im Verlauf sukzessive noch weiter verbessern.
In der /etc/alloy/config.alloy des Alloy/Loki-LXCs habe ich am Ende folgenden Codeblock angehängt:
// --- Logs: Syslog-Listener ---
loki.source.syslog "central" {
listener {
address = "0.0.0.0:1514"
protocol = "tcp"
labels = {job = "syslog"}
}
forward_to = [loki.write.default.receiver]
}
loki.write "default" {
endpoint {
url = "http://localhost:3100/loki/api/v1/push"
}
}
Danach den systemd-Dienst enablen mit
systemctl enable alloy
und starten mit
systemctl start alloy
.
Wie oben schon erwähnt, habe ich es zunächst nicht geschafft, die Logs von NetBox selbst über Alloy an Loki zu senden. Nach zwei Tagen des Herumprobierens meine ich, das Problem lokalisiert zu haben. NetBox ist eine Python/Django-Anwendung, und scheinbar sendet der SysLogHandler von Python keine RFC5424-konformen Logmeldungen. Alloy erwartet aber genau dieses Format und verwirft alle nicht RFC5424-konformen Nachrichten einfach. Das Problem sollte bei meinen anderen LXCs nicht auftreten, denn kein anderer meiner laufenden Services ist meines Wissens in Python geschrieben. Werde ich im Verlauf noch merken…
Jedenfalls musste ich in dem NetBox-LXC noch rsyslog nachinstallieren. rsyslog fungiert hier als Übersetzer: Es nimmt die minimale Nachricht von NetBox lokal entgegen (über /dev/log), reichert sie mit allen fehlenden Feldern an (Timestamp, Hostname, App-Name, Version) und schickt erst dann ein vollständiges, korrektes Paket weiter.
apt-get update apt-get install -y rsyslog systemctl enable rsyslog systemctl start rsyslog
Damit rsyslog die NetBox-Nachrichten (Facility local0) auch tatsächlich an Alloy weiterleitet, musste ich noch eine Forward-Regel anlegen:
echo "local0.* @@<loki-lxc-ip>:1514;RSYSLOG_SyslogProtocol23Format" >> /etc/rsyslog.d/99-loki-forward.conf systemctl restart rsyslog
Das Anhängsel ;RSYSLOG_SyslogProtocol23Format war dabei der Kern meines zweitägigen Problems: Ohne dieses Template sendet rsyslog standardmäßig im älteren RFC3164-Format, das Alloy nicht akzeptiert.
Nun muss man in dem NetBox-LXC noch die Config bezüglich des Loggings etwas anpassen. Bei mir war der Logging-Teil in der Config initial leer.
nano /opt/netbox/netbox/netbox/configuration.py
Hier folgendes beim Abschnitt Logging eintragen:
# https://docs.djangoproject.com/en/stable/topics/logging/
LOGGING = {
'version': 1,
'disable_existing_loggers': False,
'handlers': {
'console': {
'level': 'INFO',
'class': 'logging.StreamHandler',
},
'syslog': {
'level': 'INFO',
'class': 'logging.handlers.SysLogHandler',
'address': '/dev/log',
'facility': 'local0',
},
},
'loggers': {
'netbox': {
'handlers': ['console', 'syslog'],
'level': 'INFO',
},
'django': {
'handlers': ['console', 'syslog'],
'level': 'WARNING',
},
},
}
Um sicherzugehen, dass NetBox nicht das interne Logging zugunsten der neuen externen Lösung ganz deaktiviert, habe ich sicherheitshalber beide Handler
['console', 'syslog']
in meiner Config eingetragen. Danach NetBox neu starten mit
systemctl restart netbox netbox-rq
Ich hoffe, das passt so… es scheint jedenfalls zu funktionieren. Hier noch der Screenshot einer Abfrage von Loki via Grafana.
Man sieht schön die Aktivität des Dynamic IP Script aus dem vorherigen Beitrag, das momentan noch alle 30 Minuten ausgeführt wird. Grafana hat dabei auch die UTC Timestamps automatisch in die Lokalzeit umgerechnet.
Wie man auf dem letzten Bild sieht läuft das Logging in NetBox intern weiterhin auf UTC.
