Serverüberwachung mit checkmk
Meine ersten Schritte mit Serverüberwachungstools habe ich vor vielen Jahren mit nagios1 gemacht. Irgendwann bin ich dann zu Icinga2 gewechselt. Immer wieder bin ich auch über checkmk3 gestolpert und habe mich nun endlich einmal dazu entschieden, es mir einmal genauer anzuschauen. Während man nagios und Icinga die Verwandtschaft - gerade wenn es an die Configdateien geht - noch recht gut ansieht, sieht checkmk deutlich anders aus und dieser Eindruck bleibt mitunter auch bestehen, wenn man sich an die Konfigurationsdateien wagt (wenngleich auch hier der Nagios-Ursprung noch gut erkennbar ist). Denn alle zuvor genannten Tools entstammen einer gemeinsamen Wurzel. Und sie sind bis heute in Teilen kompatibel.
checkmk wirkt an einigen Stellen etwas moderner als seine Geschwister und es lässt sich weitestgehend - ohne manuelles Eingreifen in die Konfigurationsdateien - über seine Weboberfläche konfigurieren. Wer mehr Automatisierung wünscht, kann u.a. die REST-API von checkmk nutzen.
Bei der Installation muss man zwischen dem eigentlichen checkmk-Servers und dem sog. checkmk-Agent unterscheiden. Den eigentlichen Server kann man z.B. sehr einfach mittels Docker betreiben. Der Agent sollte direkt im Hostsystem selbst installiert werden, schließlich wollen wir dessen Zustand erfassen, nicht den eines Docker-Containers. Aber beginnen wir mit checkmk selbst, ein fertiger Docker-Container wird vom checkmk-Projekt bereits zur Verfügung gestellt, wir können diesen also einfach direkt starten4:
docker container run --rm -dit -p 8080:5000 -p 8000:8000 --tmpfs /opt/omd/sites/cmk/tmp:uid=1000,gid=1000 -v /omd/sites --name monitoring -v /etc/localtime:/etc/localtime:ro checkmk/check-mk-raw:2.2.0-latestBeim ersten Start des Containers generiert checkmk automatisch ein Kennwort für den User cmkadmin, wer lieber direkt ein eigenes Kennwort nutzen möchte, kann dem docker run Befehl den Parameter -e CMK_PASSWORD='meinsupergeheimespassword' mitgeben5:
docker container run --rm -dit -p 8080:5000 -p 8000:8000 --tmpfs /opt/omd/sites/cmk/tmp:uid=1000,gid=1000 -v /omd/sites --name monitoring -v /etc/localtime:/etc/localtime:ro -e CMK_PASSWORD='meinsupergeheimespassword' checkmk/check-mk-raw:2.2.0-latestNach einer kurzen Wartezeit sollte checkmk unter http://127.0.0.1:8080/cmk/check_mk zur Verfügung stehen. Wer checkmk gerne hinter einem Reverse-Proxy betreiben möchte, kann z.B. folgende nginx-Konfiguration nutzen:
server {
listen 443 ssl;
listen [::]:443;
server_name checkmk.example.org;
ssl_certificate /var/lib/dehydrated/certs/checkmk.example.org/fullchain.pem;
ssl_certificate_key /var/lib/dehydrated/certs/checkmk.example.org/privkey.pem;
ssl_trusted_certificate /var/lib/dehydrated/certs/checkmk.example.org/fullchain.pem;
location / {
proxy_pass http://127.0.0.1:8080/;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Host $server_name;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
}
}Wichtig ist hier insbesondere die Angabe des Host-Headers, ohne diesen leitet checkmk gerne mal auf die eigentliche Docker-URL um und auch Funktionen wie 2FA stehen (trotz https) nicht zur Verfügung.
Hat man sich erfolgreich an der Weboberfläche angemeldet, sollte zunächst der Agent für das gewünschte Zielbetriebssystem heruntergeladen werden. Diese finden sich unter dem Menüpunkt Setup => Agents in der linken Seitenleiste. Ich werde hier beispielhaft den Linux-Client im .deb Format nutzen. Wo wir schon auf der entsprechenden Downloadseite sind, können wir uns außerdem schon einmal das Plugin mk_docker.py und die zugehörige Konfigurationsdatei docker.cfg herunterladen. Bestenfalls kopieren wir uns auf der Seite einfach nur die Downloadlinks und laden die Dateien direkt auf dem Zielsystem mittels wget herunter:
wget https://checkmk.example.org/cmk/check_mk/agents/check-mk-agent_2.2.0p7-1_all.deb
wget https://checkmk.example.org/cmk/check_mk/agents/cfg_examples/docker.cfg
wget https://checkmk.example.org/cmk/check_mk/agents/plugins/mk_docker.pyDie Installation des Agents erfolgt dann mittels:
apt install ./check-mk-agent_2.2.0p7-1_all.debOb alles geklappt hat, kann mittels systemctl status check-mk-agent.socket überprüft werden. Der Output sollte in etwa wie folgt aussehen:
● check-mk-agent.socket - Local Checkmk agent socket
Loaded: loaded (/lib/systemd/system/check-mk-agent.socket; enabled; preset: enabled)
Active: active (listening) since Fri 2023-08-04 06:18:37 CEST; 5h 59min ago
Triggers: ● check-mk-agent@2220-3235481-998.service
Docs: https://docs.checkmk.com/latest/en/agent_linux.html
Listen: /run/check-mk-agent.socket (Stream)
Accepted: 2221; Connected: 1;
Tasks: 0 (limit: 9300)
Memory: 0B
CPU: 2ms
CGroup: /system.slice/check-mk-agent.socket
Aug 04 06:18:37 example systemd[1]: Starting check-mk-agent.socket - Local Checkmk agent socket...
Aug 04 06:18:37 example systemd[1]: Listening on check-mk-agent.socket - Local Checkmk agent socket.Hat dies geklappt, können wir unseren zu überwachenden Host in checkmk erzeugen. Hierzu wählen wir in der Weboberfläche den Menüpunkt Setup => Hosts und klicken dort auf den Button Add host. Im folgenden Formular geben wir unter Hostname den Namen unseres Hosts ein. Dies ist bestenfalls dessen FQDN6, es kann aber auch einfach eine beliebige Bezeichnung sein. Sollte letzteres der Fall sein, müssen wir noch die Option IPv4 address aktivieren und die IP-Adresse des Hosts eintragen.
Ist dies erledigt, klicken wir den Button Save & run service discovery. Auf dem jeweiligen Host führen wir nun folgenden Befehl aus:
cmk-agent-ctl register --server checkmk.example.org --user cmkadmin --password meinsupergeheimspassword --hostname $(hostname) --site cmk --trust-certEs wird nun einen Moment dauern, danach wird checkmk eine Liste von Services und sonstigen Daten anzeigen, die ihm über den Host bekannt sind. Über die Buttons vor den jeweiligen Einträgen kann festgelegt werden, welche Datenpunkte man in die Überwachung aufnehmen möchte. Alternativ kann man über den Button Accept all auch einfach alle verfügbaren Datenpunkte übernehmen. Diese Entscheidung kann man später auch problemlos und jederzeit noch einmal anpassen.7
Oben rechts sollte checkmk uns nun anzeigen, dass Änderungen an der Konfiguration vorgenommen wurden:
Klickt man auf diesen Bereich (die Zahl kann natürlich abweichen), gelangt man zur Seite Activate pending changes. Hier klickt man auf den roten Button beim Eintrag Local site cmk:
Ist dieser Vorgang abgeschlossen, können wir uns unser Monitoring-Dashboard unter Monitor => Main Dashboard anschauen. Hier werden ggf. noch einige Service-Problems gemeldet, dies liegt in der Regel daran, dass deren Zustand noch nicht vom System erfasst wurde. In den nächsten Minuten sollten diese automatisch den Status "OK" annehmen und nicht mehr unter Service Problems (unhandled) gelistet werden.
Der Add Host Vorgang kann nun für alle weiteren Systeme wiederholt werden. Wer hier lieber auf Automatisierung setzt, kann dies z.B. über die REST-API von checkmk tun. Entsprechende Beispiele finden sich in der Dokumentation von checkmk unter 8. Wichtig sind hier insbesondere die Beispiele zum Anlegen neuer Hosts, zur Service Discovery und dem Aktivieren der Änderungen. Zur Nutzung der REST-API sollte bestenfalls ein eigener Benutzer über die Weboberfläche angelegt werden.
Als Alternative kann auch das Kommandozeilentool cmk anstelle der REST-API genutzt werden.
Nachdem wir nun alle unsere Hosts im System haben, können wir uns um unser Docker-Plugin kümmern. Mit diesem kann der Zustand von Docker-Containern auf unseren Hosts genauer überwacht werden. Es ist hierzu nicht zwingend nötig (aber möglich) einen Agent innerhalb der jeweiligen Container zu betreiben. Das bereits heruntergeladene Plugin muss in das Verzeichnis /usr/lib/check_mk_agent/plugins/ die zugehörige Konfigurationsdatei in der Verzeichnis /etc/check_mk unserer Hosts kopiert werden.
Die Konfigurationsdatei sollte außerdem noch auf unsere Bedürfnisse angepasst werden:
[DOCKER]
container_id: name
skip_sections: docker_container_mem
base_url: unix://var/run/docker.sockDer Eintrag container_id: name sorgt dafür, dass wir unsere Docker-Container über deren Namen statt deren ID referenzieren können. Das ist wichtig, da sich die ID ändert, wenn wir den Container neu erzeugen. Der Name hingegen bleibt stets gleich. Allerdings müssen wir hierbei beachten, dass es ggf. mehrere Hosts mit Containern des gleichen Namens gibt. Die Option skip_section enthält den Eintrag docker_container_mem, da diese Daten nur dann erfasst werden, wenn ein Agent direkt im Container aktiv wäre, was in unserem Setup nicht der Fall ist.
Dieses Problem kann aber einfach unter Setup => AgentsAccess to agents => Hostname translation for piggybacked hosts gelöst werden. Hier können Regeln zur Umbenennung der Docker-Hostnames angelegt werden. Wichtig: Es sollte pro Host nur eine Regel angelegt werden, bei mir wurde sonst nur die jeweils erste Regel angewendet:
Die Docker-Container können nun wie ganz normale Hosts hinzugefügt werden. Es müssen lediglich zwei zusätzliche Settings vorgenommen werden:
- IP address family: No IP
- Checkmk agent / API integration: No API integrations, no Checkmk agent
Optional kann noch die Option Parents genutzt werden, um anzugeben, auf welchem Host der Container betrieben wird. Auch hier muss der Auswahlprozess der Services durchlaufen werden. Da wir in der Regel alle verfügbaren Serviceinformationen nutzen wollen, bietet sich hier die Bulk service discovery an.
Die Docker-Container werden nach einiger Zeit auch unter Monitor => Applications => Docker containers aufgelistet. Hier bekommt man einen guten und schnellen Überblick über die CPU Nutzung der Container. Um den Bereich Monitor => Applications => Docker nodes zu befüllen, musste ich den Docker-Hosts unter Setup => Hosts => Host monitoring rules => Host labels manuell das Label cmk/docker_object:node zuweisen.
Neben den speziellen Plugins für checkmk können auch Plugins genutzt werden, die für Nagios/Icinga erstellt wurden. Hierzu können ganz normal die Debian-Pakete für die Nagios Plugins installiert werden:
apt install monitoring-plugins-basic monitoring-plugins-common monitoring-plugins-contribUm diese zu aktivieren, werden diese in die Konfigurationsdatei /etc/check_mk/mrpe.cfg eingetragen:
check_apt /usr/lib/nagios/plugins/check_aptAndere Überwachungen lassen sich auch gänzlich ohne Plugins hinzufügen, z.B. mittels Setup => ServicesHTTP, TCP, Email, ... => Check HTTP service. Fügt man hier neue Überwachungen hinzu, werden diese Standardmäßig für alle Hosts angewendet. Das kann sehr praktisch aber auch unerwünscht sein. Am Ende des Edit rule-Formulars lassen sich daher Conditions festlegen. Hier können z.B. explizit bestimmte Hosts oder auch Tags bzw. Labels angegeben werden, auf denen die Checks ausgeführt werden sollen.
Eine weitere wichtige Einstellung ist die Konfiguration der Notifications. Ich empfehle hier einen Push-Service wie z.B. pushover einzurichten. Eine Benachrichtigung via E-Mail ist aber natürlich ebenfalls möglich.
Auf eher schwächeren und/oder nicht ganz so wichtigen Systemen empfiehlt es sich zudem den standardmäßig auf eine Minute eingestellten Check interval anzupassen. Dies ist über Setup => Services => Service monitoring rules => Normal check interval for service checks möglich.
Ebenfalls hilfreich kann es sein, den Wert service_check_timeout in /omd/sites/cmk/etc/nagios/nagios.d/tuning.cfg zu erhöhen.
Wie unschwer zu erkennen ist, wenn man sich durch die checkmk Menüs klickt, gibt es noch zahlreiche andere Möglichkeiten und Einrichtungsoptionen. Das checkmk Handbuch9 10 leistet hier gute Hilfestellungen. Bei einigen Dingen sollte man jedoch sehr genau lesen, da sich viele wichtige Schritte auch gern mal im Fließtext "verstecken". Auch ist es anfangs manchmal etwas schwierig die Pfadangaben richtig zuzuordnen. Nach kurzer Zeit hat man sich aber gut eingefunden.