Posted by
eumel8
on January 13, 2025 ·
38 mins read
Einstieg
Wenn man in der IT verschiedene Dienste laufen lässt, will man meistens auch wissen, ob diese denn auch laufen. Um das nicht jedes Mal selbst zu überprüfen, gibt es Monitoring-Systeme.
Solche Systeme gibt es in beliebiger Grösse und man kann auch beliebig viel Resourcen, Zeit und Geld reinstecken. Unter Umständen ist das Monitoring-System grösser als die eigentliche Anwendung. Minimal gehalten ist es nur ein Oneliner:
while true;do p=$(ping -q-c 1 -w 1 blog.eumel.de)||echo"FAILED";sleep 1;done
Anforderungen
Okay, der Ping-Oneliner informiert mich auf der Text-Console, ob ein Server erreichbar ist und gibt FAILED aus, wenn dem nicht so ist. Vielleicht darf es auch ein bisschen mehr sein.
Hier meine Liste nach Prio:
Mein Webserver und Mailserver ist auf den Protokollen icmp, tcp und den Diensten https, smtp, imap, pop3 erreichbar
SSL Zertifikate sind gültig und nicht abgelaufen
Informiere mich per SMS, wenn dem nicht so ist
Die Festplatte des Linux-Servers ist nicht zu 100% voll
Memory und CPU ist genug frei
Anzahl der Prozesse ist im Rahmen, keine Zombi-Prozesse
Alle LXD-Container laufen, ZFS hat genug freien Speicher
Security-Updates sind verfügbar (kritisch/nicht kritisch)
Informiere mich per E-Mail, wenn dem nicht so ist
Letzteres ist gar keine Anforderung, da ich regelmässig etliche tausend E-Mails lösche, die jeder LXD-Container verschickt, weil er mal ein Debian-Package updaten möchte.
Wenn der Dienst “vor Kunde” nicht verfügbar ist, brauche ich allerdings schon eine Notifizierung und die ist nicht unbedingt nur E-Mail.
Icinga
Icinga ist ein Fork von Nagios, ein Monitoring-System aus dem letzten Jahrtausend. Es ist auch heute noch relativ häufig im Einsatz. Die Architektur besteht aus dem Icinga-Server mit Web-Frontend und den sogenannten NRPE-Agenten. Diese kann der Icinga mit einem speziellen Protokoll abfragen und bekommt Statusinformationen, etwa “läuft Prozess xyz?”. Es existiert eine grosse Azahl von Plugins, die quasi schon vorgefertigt Dienste abfragen können, etwa SMTP. Aus der Geschichte der Zeit sind diese Plugin in bash geschrieben, oder die meisten in Perl. Und da fängt das Problem auch an. Ab Ubuntu 20.04 gabs schon die ersten Inkompatibilitäten von bereitgestellten Perl-Versionen und verfügbaren Plugin-Paketen. Es funktionierte noch, wenn man alte universe-Pakete noch irgendwo fand und die lokal sicherte. Ab Ubuntu 24.04 ist damit aber Schluss. Der Zeit- und Versionsunterschied ist einfach zu gross. Was tun? Von Icinga 1 nach Icinga 2 migrieren und damit einen Burst von Resourcen starten wie eigene Datenbank und dann natürlich alle Checks umschreiben und nach neuen Plugins suchen? Viele Tests haben sich als überflüssig rausgestellt, werden gar nicht genutzt. Die Liste der harten Anforderungen ist doch recht kurz und rechtfertigt kein grosses Monitoring-System. Also: weg damit!
Prometheus
Prometheus ist der de facto Standard in der cloud-nativen Monitoring-Welt. Es gibt wieder einen zentralen Server. Das Web-Frontend ist eher spartanisch. Deswegen wird meist Grafana eingesetzt, um Metriken zu visualisieren. Dazu gibt es eine grosse Zahl von frei verfügbaren Dashboards. Die Daten bekommt Prometheus von sogenanten Scrape-Endpunkten, die er in einem vorgegeben Format über http abfragen kann. Viele Applikationen bieten so einen /metric-Endpunkt an und stellen dort eine Vielzahl von Metriken bereit, die den aktuellen Zustand der Applikation beschreiben. Durch die grosse Community um Prometheus gibt es aber auch eine Vielzahl von Exportern, die diese Aufgabe übernehmen. Github listet über 2000.
Rant: Witzigerweise gibt es auch einen Nagios-Exporter für Prometheus und Icinga XI unterstützt jetzt auch Prometheus-Metriken. Muss man wissen, ob man sein Monitoring ein bisschen umstellt und dann doppelte Arbeit hat.
Exporter
Folgende Exporter wollen wir verwenden:
Node-Exporter Ein sehr mächtiger Exporter, der uns hunderte von Metriken zu unserem Linux-Server bereitgestellt, sei es CPU-Metriken, Memory-Verbrauch, Festplattenbelegung usw.
LXD-Exporter LXD ist im Einsatz und hier der passende Exporter-Fork, läuft mit Incus/LXD 4.0
ZFS-Exporter Liefert Metriken zum ZFS-Pool unter LXD, wird aber teilweise schon durch den Node-Exporter zur Verfügung gestellt.
Blackbox-Exporter Testet Dienste “von aussen” (Blackbox), etwa Webseiten oder Mailserver
Ausserdem liefert Prometheus ebenfalls Metriken über den eingebauten Exporter, wir können ihn also auch selber abfragen.
Prom-LXD
Unser neues Zielsystem ist ein LXD-Container mit Ubuntu 24.04. Bislang wurde die Konfiguration mit Puppet ausgerollt. Hier gab es aber in Puppet 8 auch Breaking Changes, die zusätzlichen Verwaltungsaufwand bedeuten. Wir werden die Konfiguration direkt aus dem Git als Debian-Package aufs System bringen.
In einer Gitlab-CI-Pipeline geht das mit
Wir kopieren mit lxc file push unser debian-Paket in den LXD Container. Oder über ein internes Apt-Repo ist das Paket verfügbar. Es enthält folgende Dateien:
index.html - diese Datei stammt von prometheus-dashboard und ist unser angepasstes Template dafür
alertmanager.yaml - diese Datei beinhaltet die Konfiguration des Alertmanagers und wie Alarme behandelt werden sollen. Wir schicken zum Beispiel kritische Alarme an einen Webhook.
blackbox.yaml - das ist die default Konfigurationsdatei des Blackbox-Exporters. Man kann nicht genutzte Module dort auch entfernen oder anpassen:
eumelnet_rules.yaml - hier sind spezielle Alarmrules definiert, also Prometheus Queries, die den Alertmanager triggern sollen.
hooks.yaml - das ist die Konfigurationsdatei für den Webhook vom Alertmanager
twilio.sh - das ist die Datei, die vom Webhook ausgeführt wird. Seit Jahren im Einsatz ist Twilio, ein API-gesteuerter Router von text2sms oder text2voice Nachrichten. Mit diesem Script wird eine SMS versendet man dem vom Webhook und dem Alertmanager übermitelten Daten:
prometheus.yaml - Die Kernkonfiguration des Prometheus. Zum Einen wird der Endpunkt des Alertmanagers angegeben, an den Alarme aus den Metrik-Rules geschickt werden soll. Die Rule-Datei wird dazu included.
Zum Anderen sind die Scrape-Endpunkte der Exporter angegeben, also von wo die Daten bezogen werden.
Im Beispiel unten laufen der ZFS- und LXD-Exporter auf dem Server und werden über das Default-Gateway des LXD-Servers angesprochen. Bei diesen Exportern ist auch darauf zu achten, dass der Listener nicht auf :<port> oder 0.0.0.0:<port> steht und Metriken so möglicherweise ins Internet exposed werden.
Den Node-Exporter haben wir auf dem LXD-Container installiert. Er könnte natürlich auch auf dem LXD-Server laufen und so noch zusätzliche Metriken liefern. Blackbox-Exporter läuft im LXD-Container, sowie auch Prometheus, Prometheus-Dashboard und Alertmanager.
install.sh - diese Datei führen wir im LXD-Container aus
host.sh - Diese Datei führen wir auf dem LXD-Server aus