Docker überwachen

Das eigentlich Interessante ist natürlich das Überwachen der Docker-Container. Dies geschieht durch Installation der Plugins automatisch. Allerdings werden die Services nicht dem Docker-Node zugeordnet sondern Checkmk geht von einem eigenen Host pro Docker-Container aus.

Der Mechanismus, der hier zum Einsatz kommt, heißt Piggyback (Huckepack). Dabei transportiert ein Plugin oder Spezialagent Daten zu anderen Hosts quasi „huckepack“ in seiner Ausgabe mit. Checkmk legt diese Daten im Verzeichnis tmp/check_mk/piggyback ab. Sie brauchen dann nur noch in WATO Hosts mit den richtigen Namen anzulegen und die Services werden diesen automatisch zugeordnet.

Ab Version 1.6.0 der Enterprise Editions können Sie diese Hosts automatisch anlegen lassen. Verwenden Sie dazu in der dynamische Konfiguration den Konnektor Piggyback. Sie können die Hosts auch von Hand anlegen. Beachten Sie dabei Folgendes:

Nachdem Sie die Container-Hosts angelegt und die Serviceerkennung durchgeführt haben, tauchen auf diesen weitere Services auf.

Falls Sie in dem Container einen Linux-Agenten installiert haben, wird er automatisch ausgeführt. Da allerdings viele Services, welche der Agent innerhalb des Containers überwacht, eigentlich die Information der Node zeigen (z.B. CPU load, Temperatur und viele weitere Betriebssystemparameter), wurden diese bei Version 1.6.0 entfernt.

Als Standardeinstellung wird wie oben erwähnt die zwölfstellige Short-ID des Containers als Name des Container-Hosts verwendet. Dies können sie optional anders konfigurieren. Setzen sie hierzu in der Konfigurationsdatei die Option container_id auf long, um die vollständinge Container-ID als Name zu verwenden, oder auf name, um den Containernamen zu verwenden. Selbstverständlich können Nutzer der Checkmk Enterprise Editions dies in der Agentenbäckerei einstellen.

Übrigens: Mit dem Regelsatz Access to agents > General settings > Hostname translation for piggybacked hosts können Sie recht flexibel Regeln definieren, nach denen Hostnamen, welche in Piggyback-Daten enthalten sind, umgewandelt werden, um bessere Hostnamen für Checkmk zu generieren. Damit können Sie z.B. das auch Problem lösen, wenn Sie auf zwei verschiedenen Docker-Nodes Container mit dem gleichen Namen haben. Über geeignete Translation-Regeln können Sie die Namen dann z.B. mit einem Präfix versehen, um diese eindeutig zu machen.

Da der Hoststatus eines Containers nicht unbedingt über TCP-Pakete oder ICMP geprüft werden kann, muss dieser anders ermittelt werden. Hier bietet sich der Service Docker container status an. Dieser prüft ohnehin, ob der Container läuft oder nicht und kann daher als sicheres Mittel verwendet werden, um den Hoststatus zu ermitteln. Legen Sie dazu eine Regel in dem Regelset Host Check Command an und setzen Sie die Option Use the status of the service auf den erwähnten Service. Vergessen Sie nicht die Bedingungen so zu setzen, dass sie nur Container betreffen. In unserem Beispiel liegen alle Container in einem gleichnamigen Ordner:

Um Details im Container selbst zu überwachen (z.B. laufenden Prozesse, Datenbanken, Logdateien, etc.), ist es notwendig, dass der Checkmk-Agent im Container selbst ausgeführt wird. Das gilt insbesondere für das Ausrollen von Agentenplugins. Falls sie keinen Agenten im Container installiert haben, wird bis zur Version 1.5.0 von Checkmk dazu automatisch der auf der Node installierte Agent im Container ausgeführt, sobald Sie die Node mit Checkmk überwachen.

Da sich dieses Verfahren als nicht sehr performant herausgestellt hat, ist es ab Version 1.6.0 notwendig, dass Sie den normalen Checkmk-Agenten direkt im Container installieren, um ein detaillierteres Monitoring im Container zu bekommen. Die drei Plugins mem, cpu und diskstat (Disk-I/O) funktionieren hier allerdings auch ohne Agent im Container und werden vom Checkmk-Agenten auf der Node selbst berechnet.

Gerade für selbst erstellte Docker-Images möchten Sie vielleicht den Agenten selbst in den Container ausrollen. In diesem Fall werden die Daten nicht mehr, wie oben beschrieben, von dem Agenten der Docker-Node berechnet. Stattdessen läuft ein separater Agent in jedem Container. Der Aufruf erfolgt aber nach wie vor gebündelt über die Docker-Node im Piggyback-Verfahren.

Der im Container installierte Agent funktioniert allerdings nur dann, wenn in dem Container auch alle benötigten Befehle vorhanden sind. Speziell bei minimal gebauten Containern auf Basis von Alpine-Linux kann es gut sein, dass elementare Dinge wie die Bash nicht vorhanden sind. In diesem Fall sollten Sie den Container aus der Docker-Node heraus überwachen.

Die Verwendung des Regelsets Host Check Command wird in diesem Fall nur benötigt, wenn der Container nicht pingbar ist, funktioniert aber ansonsten exakt so wie oben beschrieben.