Workshop: Monitoring mit Checkmk – Teil 14 Container im Blick: Docker mit Checkmk überwachen

Container? Kann Checkmk natürlich monitoren. Das Vorgehen? Simpel, aber nicht unbedingt intuitiv – ein paar Konzepte von Checkmk und Docker müssen schon bekannt sein.

Wenn Sie interessiert genug sind, um Ihre Infrastruktur zu überwachen, werden Sie auch Container nutzen. Selbst viele Consumer-Produkte wie Medienserver werden mittlerweile als simple, fertig konfigurierte Docker-Kisten angeboten.

Nun kümmert sich Checkmk sowohl um Hosts als auch deren Services. Docker-basierte Anwendungen liegen im Grunde irgendwo dazwischen. Es sind keine kompletten virtuellen Maschinen, haben oft bis aufs Skelett abgespeckte Betriebssysteme als Basis und fungieren im Grunde doch nur als Service/Anwendungsprogramm.

Und obendrein sind sie auch noch auf den Docker-Node angewiesen. Selbst wenn ein Container also zum Beispiel ein komplettes Ubuntu beinhalten sollte, unter dem natürlich der reguläre Checkmk-Agent laufen kann, würde diese Art des Monitorings der Sache nicht gerecht. Denn tendenziell wollen Sie ja wissen, welche Container überhaupt existieren, wie viel Speicherplatz diese und zugehörige Images sowie Volumes einnehmen, und so weiter.

Noch schlimmer: In größeren Umgebungen sind Container häufig flüchtig, werden automatisch erzeugt und gelöscht. Da diesem Umstand nur die kommerziellen Versionen Rechnung zollen, wird er am Ende des Artikels nur kurz abgehandelt.

Piggyback-Prinzip für Container-Monitoring

Das Konzept zum Überwachen von (unter anderem) Containern hört in Checkmk auf den Namen Piggyback. Das meint: Daten von Hosts, auf denen kein Checkmk-Agent läuft oder die als Container von einem Node abhängig sind, nicht von den Hosts selbst kommen, sondern von einem regulären Host mit regulärem Agenten, der diese Daten dann huckepack mit zum Checkmk-Server nimmt.

Mal ganz konkret: Der Host „mein-docker-server“ fungiert als Docker-Node. Auf „mein-docker-server“ läuft ein ganz normaler Checkmk-Agent – mit dem zugehörigen Docker-Plugin. Das Plugin kann die API von Docker nutzen, um Informationen zu vorhandenen Containern, Volumes und Images zu bekommen. Mehr noch: Daten zur CPU-Nutzung, RAM- und Dateisystemauslastung der einzelnen Container können ebenso direkt vom Node-Agenten berechnet werden.

Die Einrichtung ist simpel: Es muss das Agenten-Plugin „mk_docker.py“ konfiguriert und ausgerollt werden. In Checkmk ist es unter „Setup/Agents/Other operating systems/Plugins“ zu finden. Die Installation auf dem Docker-Host:

So weit so gut. Der Agent auf dem Node erzeugt also Daten für seine Container und schickt sie samt seiner eigenen Daten an Checkmk. Nun kennt Checkmk freilich den Host „mein-docker-server“, aber von den 20 Containern, zu denen dieser Host Piggyback-Daten mitliefert, hat es vermutlich noch nie gehört.

Für jeden überwachten Container muss eben auch ein Host in Checkmk existieren.

Diese Hosts müssen manuell angelegt werden – und jetzt wird es pingelig: Mit genau dem Namen, der auch huckepack übermittelt wird. Standardmäßig ist das die 12-stellige ID eines Containers. Sie haben zwei Möglichkeiten, die exakten Namen zu erfahren und beim Anlegen von Hosts zu nutzen: Zum einen liefert Docker diese Informationen natürlich selbst, sobald man die laufenden Container auflisten lässt („docker ps“). Zum anderen finden sie sich aber auch auf dem Checkmk-Server. Im Instanz-Verzeichnis werden unter „~/tmp/check_mk/piggyback“ Ordner mit eben diesen Namen/IDs angelegt, für jeden gefundenen Container. Und nimmt man die Namen aus diesem Verzeichnis, darf man sich auch sicher sein, dass es die richtigen sind (siehe Abbildung 1).

Also nochmal das Prozedere soweit:

• Docker-Node wird per Agent überwacht

• Agent wird mit dem Docker-Plugin erweitert

• Docker-Plugin bekommt via Docker-API Informationen zu Containern

• Agent liefert die Container-Daten huckepack an Checkmk

• In Checkmk werden Hosts mit den Namen der Container-IDs angelegt

• Checkmk ordnet die Huckepack-Daten vom Node den Containern zu

Bis hierhin bekämen Sie schon einige Daten pro Container: Uptime, CPU-Nutzung, RAM- und Dateisystemauslastung sowie den „Docker container status“ – das alles allerdings für Hosts mit wenig aussagekräftigen Namen (siehe Abbildung 2). Es fehlen für den Alltag noch ein paar Schritte.

Zusätzliche Konfiguration

Die Berechnung von CPU, RAM- und Festplattennutzung vieler Container ist einigermaßen rechenaufwändig. Wenn diese Daten nicht benötigt werden, können sie ausgeschlossen werden. Auf dem Docker-Host benötigt die Datei „/etc/check_mk/docker.cfg“ dafür entsprechende Einträge:

Weitere ausschließbare Daten finden sich in den Konfigurationsbeispielen im Instanzverzeichnis unter „~/share/check_mk/agents/cfg_examples“.

Ebenfalls eine denkbare Option in dieser Config-Datei:

Damit würde statt der Container-ID der Container-Name verwendet – entsprechen könnten die Container-Hosts in Checkmk zum Beispiel „mein-container-1“ statt „abc123def456ghi“ heißen.

Der Vollständigkeit halber: Checkmk bietet auch eine Funktion „Host name translation for piggybacked hosts“ an. Damit lassen sich Hostnamen wie „abc123def456ghi“ per Regel umbenennen – etwa einzeln und direkt in „mein-umbenannter-host“ oder auch gesammelt via Regex in „container_ abc123def456ghi“ und so weiter (siehe Abbildung 3).

Wichtig dabei: Die Regel muss dem Docker-Host zugeordnet werden, nicht dem Container-Host. Zudem muss auch der umbenannte Container-Host überhaupt erst angelegt werden! Dafür steht dieser dann nebst allen anderen in diversen Docker-Ansichten zur Verfügung, die über das Monitor-Menü erreichbar sind (siehe Abbildungen 4 und 5).

Und noch eine letzte Konfiguration könnte nützlich sein: Was ist eigentlich mit dem Host-Status eines Container-Hosts? Standardmäßig pingt Checkmk Hosts einfach an, Container dürften sehr regelmäßig aber gar nicht direkt erreichbar sein. Der Docker-Node spendiert den Containern allerdings den bereits erwähnten Service „Docker container status“ – der nichts weiter tut, als zu vermelden, ob der Container nun läuft oder nicht. Und erfreulicherweise kann eben dieser Service statt des Standard-Pings genutzt werden, um den Host-Status des Containers zu ermitteln (über die Regel „Host check command“).

Praxistipps

In vielen Fällen bietet es sich an, die Container in einen separaten Ordner zu verfrachten. Das ist nicht nur für die menschlichen Nutzer übersichtlich, sondern kann auch bei der Konfiguration helfen. So lassen sich etwa Regeln einfach für Ordner setzen. Und die Service-Erkennung lässt sich so ganz fix für alle Container-Hosts auf einmal ausführen.

Sie nutzen eine fixe Anzahl an Containern? Dann könnte es sich auch lohnen, hier die genaue Anzahl überwachen zu lassen. Dafür gibt es die Regel „Docker node container levels“.

Docker ist durchaus bekannt dafür, selbst Probleme bezüglich RAM- und Dateisystemauslastung zu verursachen, letztere gerne im Zusammenhang mit Cache-Dateien. Da der Docker-Node sowieso mit dem regulären Checkmk-Agenten überwacht wird, sollten Sie darüber nachdenken, Alarme und Benachrichtigungen speziell dafür einzurichten.

Und zu guter Letzt: Das Docker-Agenten-Plugin benötigt auf dem Docker-Node die Python-Bibliothek Docker. Dokumentation und Checkmk-Oberfläche sind hier leider nicht ganz synchron und Ubuntu meldet in der Version 24.04 wiederum eigene Problemchen an. Die Installation von Plugin und Bibliothek auf dem Docker-Node funktioniert im Prinzip aber genau so:

Sollte auf dem System aber tatsächlich systemweit bereits eine Docker-Python-Bibliothek laufen, sollten Sie die Pip-Flag „break-system-packages“ besser Ernst nehmen.

Flüchtige Container

Es bleibt ein großes Problem: Häufig werden Container als Cloud-Instanzen verwendet, automatisch generiert, verschoben, geklont, gelöscht – sie sind flüchtig. Nun können Sie freilich Mitarbeiter damit beauftragen, den lieben langen Tag Hosts zu erstellen und löschen. Ganz praktikabel ist das aber nicht.

Für eine solche Infrastruktur lohnt sich dann doch der Griff zur kommerziellen Version: Hier kann Checkmk all diese Hosts vollautomatisch erstellen und bei Bedarf auch wieder löschen. So ist die gesamte Container-Flotte immer auf dem neuesten Stand. Nun, auch Verteilung/Installation/Konfiguration von Agent und Plugins wird einfacher, aber das ist in der Open-Source-Version auch kein Hexenwerk.

Workshop: Monitoring mit Checkmk – Teil 1

Wie funktioniert das Monitoring mit Checkmk?

Workshop: Monitoring mit Checkmk – Teil 2

Monitoring von Servern und Workstations

Workshop: Monitoring mit Checkmk – Teil 3

Monitoring von Webseiten, Mailkonten und Applikationen

Workshop: Monitoring mit Checkmk – Teil 4

Wie sieht eine gute Strukturierung in Checkmk aus?

Workshop: Monitoring mit Checkmk – Teil 5

Die wichtigsten Schritte zur Backup-Überwachung mit Checkmk

Workshop: Monitoring mit Checkmk – Teil 6

Wie funktioniert das Überwachen von Schnittstellen und Ports mit Checkmk?

Workshop: Monitoring mit Checkmk – Teil 7

Dashboards aus Daten: So wird das Checkmk-Inventar sichtbar

Workshop: Monitoring mit Checkmk – Teil 8

Checkmk aktualisieren – vorsichtig!

Workshop: Monitoring mit Checkmk – Teil 9

Checkmk: Android-Geräte überwachen – oder nicht?

Workshop: Monitoring mit Checkmk – Teil 10

So monitoren Sie Proxmox VE mit Checkmk

Workshop: Monitoring mit Checkmk – Teil 11

Webseiten mit check_httpv2 überwachen – auch ohne Checkmk!

Workshop: Monitoring mit Checkmk – Teil 12

Zertifikate mit check_cert überwachen – auch ohne Checkmk!

Workshop: Monitoring mit Checkmk – Teil 13

Checkmk anpassen: Ansichten nach Belieben gestalten

Workshop: Monitoring mit Checkmk – Teil 15

So kommt die Netzwerk-Topologie ins Monitoring

Workshop: Monitoring mit Checkmk – Teil 16

Zusammenspiel: Integrationen von und in anderen Systemen

(ID:50613170)