1. Einleitung
In den vergangenen Jahren hat das Containerkonzept die IT-Welt im Sturm erobert. Das wirft natürlich auch Fragen zu der Überwachung solcher Container auf. Checkmk kann Docker-Container direkt über den Linux-Agenten überwachen. Dabei werden nicht nur Rahmendaten, wie der Status des Daemons oder des Containers, sondern auch die Container selbst überwacht. Eine vollständige Liste der aktuell überwachbaren Dinge finden Sie wie immer im Katalog der Check-Plugins.
Neben den Status- und Inventurinformationen, die Checkmk über den Node (Docker-Sprech für: Host, auf dem die Container laufen) ermitteln kann, kann Checkmk detaillierte Statusinformationen der Container ermitteln. Hierzu wird in Checkmk jeder Container als eigenständiger Host angelegt, wenn er überwacht werden soll. Seine Daten werden im Huckepackverfahren (piggyback) an diesen Host geliefert.
Seit Version VERSION[1.6.0] der 
Checkmk Enterprise Editions können Sie mit Hilfe der dynamischen Konfiguration
die Container-Hosts sogar automatisch anlegen und entfernen lassen.
2. Einrichtung
2.1. Installation von Agent und Plugins
Damit Sie einen Docker-Node mit Checkmk überwachen können, muss dieser zunächst mit dem normalen Linux-Agenten überwacht werden. Dadurch erhalten Sie wie gewohnt ein Grundmonitoring des Wirtssystems, jedoch noch keine Information über den Docker-Daemon oder gar über die Container.
Dazu benötigen Sie noch das Agentenplugin mk_docker.py.
Installieren Sie das Plugin wie gewohnt nach /usr/lib/check_mk_agent/plugins.
In den Enterprise Editions können Sie natürlich alternativ auch mit der Agentenbäckerei
arbeiten, welche für Docker den entsprechenden Regelsatz bereitstellt: Docker node and containers.
Bitte beachten Sie, dass seit Version VERSION[1.6.0] die Python-Bibliothek docker benötigt wird --, nicht docker-py. Es ist mindestens Version 2.0.0 notwendig.
Mit python auf der Kommandozeile können Sie dies leicht überprüfen:
root@linux# python
Python 2.7.16 (default, Sep 24 2020, 22:49:21)
[GCC 8.2.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import docker
>>> docker.version
'4.0.2'Falls notwendig, können Sie die Bibliothek als root-Nutzer mit pip installieren:
root@linux# pip install dockerBei Nodes ohne Internet-Anbindung kopieren Sie die Bibliothek und installieren sie offline:
root@linux# pip install docker-4-3-1.tar.gzEinige Distributionen erlauben auch die Installation über ihre Paketmanager,
also zum Beispiel per apt-get install python-docker unter Debian,
Ubuntu und deren Derivaten. Dabei kann es allerdings passieren, dass darüber
zu alte, nicht kompatible Versionen installiert werden (beispielsweise Version
1.9 unter Debian 9). Gehen Sie in solchen Fällen wie oben beschrieben mit
pip install vor.
Achtung: Die Pakete docker-py beziehungsweise
python-docker-py dürfen nicht installiert sein. Diese stellen
eine veraltete und nicht kompatible Version der Docker-Bibliothek unter dem
selben Namesraum zur verfügung! Wenn Sie docker-py (oder beide Varianten)
installiert haben, reicht eine alleinige Deinstallation nicht aus, da pip
den Namesraum nicht reparieren kann. Um sicherzustellen, dass die korrekte
Version installiert ist, führen Sie in diesem Fall bitte folgende Befehle aus:
root@linux# pip uninstall docker-py docker
root@linux# pip install dockerAn diesem Punkt können Sie nun testen, ob das Plugin läuft und Informationen ausgibt und ob die Ausgabe auch im Agenten vorhanden ist. Das Plugin selbst testen Sie auf dem Host mit:
root@linux# python /usr/lib/check_mk_agent/plugins/mk_docker.pyUnd die Ausgabe im Agenten testen Sie auf dem Checkmk-Server mit:
OMD[mysite]:~$ strings tmp/check_mk/cache/mydockerhost | grep "<<<docker"Wenn Sie jetzt in WATO die Serviceerkennung durchführen und die Änderungen aktivieren, sollten Sie zunächst einige neue Services finden, welche den Docker-Node selbst betreffen (hier von Version 1.6.0):
2.2. Feintuning des Plugins
Seit der VERSION[1.6.0] können Sie verschiedene Parameter des Plugins konfigurieren.
So können Sie zum Beispiel Ressourcen schonen, in dem Sie nicht benötigte Sektionen
deaktivieren, oder — falls nötig — den Docker-API-Engine-Endpunkt anpassen (der Standard
ist das Unix-Socket unix://var/run/docker.sock).
Legen Sie dazu wie üblich eine Konfigurationsdatei /etc/check_mk/docker.cfg an.
Eine Vorlage mit ausführlichen Erläuterungen finden Sie im Checkmk-Verzeichnis unter
share/check_mk/agents/cfg_examples/docker.cfg.
In den Enterprise Editions können Sie alle Parameter bequem mit der Agentenbäckerei einstellen.
2.3. Überwachung der Container
Anlegen der Container-Hosts
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, vielmehr geht Checkmk 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
in einem eigenen Unterverzeichnis ab. Sie brauchen dann nur noch in WATO Hosts anzulegen, die
genauso heißen, wie eben die zugehörigen Piggyback-Unterverzeichnisse. Services werden diesen
dann automatisch zugeordnet.
Seit Version VERSION[1.6.0] der Enterprise Editions können Sie diese Hosts aber auch automatisch anlegen lassen. Verwenden Sie dazu in der dynamischen Konfiguration den Konnektor Piggyback.
Wenn Sie die Hosts dennoch von Hand anlegen, beachten Sie dabei Folgendes:
Der Hostname muss exakt dem Verzeichnis entsprechen, welches in
tmp/check_mk/piggybackangelegt wird. Per Default ist das die zwölfstellige Short-ID des Containers (z.B.2ed23056480f). Sie können das allerdings auch die vollständige ID oder den Namen ändern, wie im nachfolgenden Kapitel näher beschrieben.Falls die Container keine eigene IP-Adresse haben (was meist der Fall ist), stellen Sie das Attribut bei IP-Address-Family auf No IP ein.
Bei Data sources stellen Sie Check_MK Agent unbedingt auf No agent ein.
Das Feld Parent können Sie auf den Hostnamen der Docker-Node setzen.
Wichtig ist ferner, dass der Docker-Node und dessen Container von derselben Checkmk-Instanz aus überwacht werden.
Nachdem Sie die Container-Hosts angelegt und die Serviceerkennung durchgeführt haben, tauchen auf diesen weitere Services auf. Dort finden Sie auch einen Hinweis auf die Piggyback-Herkunft:
Alternative Benennung der Container-Hosts
Als Standardeinstellung wird wie oben erwähnt die zwölfstellige Short-ID
des Containers als Name des Container-Hosts verwendet. Dies können Sie
anders konfigurieren. Setzen Sie hierzu in der Konfigurationsdatei
die Option container_id auf long, um die vollständige
Container-ID als Namen 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. auch das 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.
Überwachen des Hoststatus
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:
Überwachen von Services im Container
Um Details im Container selbst zu überwachen (z.B. laufenden Prozesse, Datenbanken, Logdateien, etc.), ist es notwendig, dass der Checkmk-Agent im Container ausgeführt wird.
Ausnahme: Die drei Plugins mem, cpu und diskstat
(Disk-I/O) funktionieren auch ohne Agenten im Container und
werden dann vom Checkmk-Agenten auf dem Node selbst berechnet. In Containern laufende Agenten
geben diese Werte entsprechend nicht (nochmals) aus, da sie wissen, dass sie in einem
Container laufen.
Der Aufruf erfolgt aber auch mit Agenten im Container nach wie vor gebündelt über den Docker-Node im Piggyback-Verfahren. Der Container-Agent wird dazu schlicht vom Node-Agenten abgefragt.
Der im Container installierte Agent funktioniert natürlich 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 dem Docker-Node heraus überwachen — auch wenn sich so nicht alle Details erfassen lassen. Diese oben erläuterte Verwendung des Regelsets Host Check Command zur Überwachung des Hoststatus wird aber nur benötigt, wenn der Container nicht pingbar ist.
3. Diagnosemöglichkeiten
3.1. Diagnose für einen Docker-Node
Sollte die Einrichtung nicht klappen, gibt es verschiedene Möglichkeiten der Analyse des Problems. Prüfen Sie zunächst, ob der Agent in der korrekten, aktuellen Version läuft; beispielsweise mit:
OMD[mysite]:~$ cmk -n myhost | grep -o -P '\[agent\] Version:.*?,'Anschließend sollten Sie sicherstellen, dass auch das Plugin — ganz unabhängig vom Agenten — funktioniert:
root@linux# python /usr/lib/check_mk_agent/plugins/mk_docker.pyFalls die Version des Agenten auf dem Host passt und das Plugin läuft, prüfen Sie als Nächstes, ob die Daten in der Ausgabe des Agenten enthalten sind. Sie können die Ausgabe als Textdatei über den Button Download agent output in der GUI über das Dropdown-Menü des Hosts herunterladen:
Oder Sie durchsuchen direkt den Agenten-Cache. Die Ausgabe in dem folgenden Beispiel ist der Anschaulichkeit halber auf die Docker-relevanten Bereiche gekürzt:
OMD[mysite]:~$ strings tmp/check_mk/cache/mydockerhost | grep "<<<docker"
<<<docker_node_info>>>
<<<docker_node_disk_usage:sep(44)>>>
<<<docker_node_images>>>
<<<docker_node_network:sep(0)>>>Werden die Sektionen hier nicht geführt, wird die Docker-Installation nicht erkannt.
Der Service Docker node info verwendet folgenden Befehl, mit dem Sie auch manuell testen können, ob Ihre Docker-Installation korrekt läuft:
root@linux# docker info 2>&1Eine typische Fehlerquelle, insbesondere, wenn Docker-Installation, Agent und dessen Plugin einzeln korrekt laufen, ist die oben bereits erwähnte Python-Bibliothek für Docker. Wenn die beschriebene Neuinstallation keine Abhilfe schafft, schauen Sie mal nach weiteren Fehlermeldungen beim Import in Python:
root@linux# python
>>> import dockerBeispiel: Unter Debian 9 kann es hier zu Problemen mit den
SSL-Backports kommen. die sich mit einer Deinstallation via pip und
einer Neuinstallation via apt-get lösen lassen:
root@linux# pip uninstall backports.ssl-match-hostname
root@linux# apt-get install backports.ssl-match-hostname3.2. Diagnose für einen Container-Host
Falls der Container-Host keine Daten erhält, bzw. keine Services erkannt werden, prüfen Sie zuerst, ob die Piggyback-Daten zu diesem Host vorhanden sind. Der Name des Hosts muss identisch mit der ID des Containers sein. Alternativ können Sie auch über das Regelset Hostname translation for piggybacked hosts eine manuelle Zuordnung vornehmen. Hier bietet sich allerdings nur die Option Explicit hostname mapping an:
Um zu prüfen, ob zu einer ID Piggyback-Daten angelegt werden, können Sie folgenden Befehl nutzen:
OMD[mysite]:~$ ls -l tmp/check_mk/piggyback/
76adfc5a7794 f0bced2c8c96 bf9b3b8538344. Hostlabels
Seit Version VERSION[1.6.0] von Checkmk gibt es sogenannte Hostlabels. Das
überarbeitete Docker-Monitoring setzt automatisch die drei Labels
cmk/docker_image, cmk/docker_image_name und
cmk/docker_image_version. Diese Labels können Sie z.B. in Bedingungen
für Ihre Regeln verwenden, um Ihre Monitoringkonfiguration von den
jeweiligen Images abhängig zu machen, die in Containern verwendet werden.
5. Besonderheiten in Version 1.5
Das Docker-Monitoring wurde in Checkmk Version VERSION[1.5] eingeführt und in Version VERSION[1.6] massiv umgebaut. Sofern Sie noch die Version VERSION[1.5] nutzen, gibt es ein paar Punkte zu beachten, die sich vom aktuellen, bis hier hin dokumentierten Stand unterscheiden.
Plugins: mk_docker_node und mk_docker_container_piggybacked (statt mk_docker.py).
Regelsätze für Agentenbäckerei: Docker node und Piggybacked Docker containers (statt Docker node and containers).
Falls kein Agent im Container installiert ist, wird der Agent des Docker-Nodes im Container ausgeführt (diese Funktion wurde aus Gründen der Performance in der Version VERSION[1.6] entfernt).
6. Dateien und Verzeichnisse
| Pfad | Bedeutung |
|---|---|
tmp/check_mk/piggyback/ | Hier legt WATO die Huckepackdaten ab. Für jeden Host wird ein Unterordner mit seinem Namen erzeugt. Darin befindet sich eine Textdatei mit den Daten des Hosts. Dateiname ist der Host, welcher die Daten angeliefert hat. |
tmp/check_mk/cache/ | Hier wird die jeweils jüngste Agentenausgabe aller Hosts temporär gespeichert. Der Inhalt einer Datei zu einem Host ist identisch zu der Ausgabe des Befehls |