1. Einleitung
Docker hat sich weltweit zu einem der am häufigsten verwendeten Softwareprodukte zur Container-Virtualisierung entwickelt. So notwendig eine durchgängige und transparente Überwachung der Container ist, so komplex ist sie aber auch aufgrund von deren dynamischer und vielschichtiger Architektur.
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-Bezeichnung für: Host, auf dem die Container laufen) ermitteln kann, kann Checkmk auch detaillierte Statusinformationen der Container selbst ermitteln. Hierzu wird in Checkmk jeder Container als eigenständiger Host angelegt, wenn er überwacht werden soll. Seine Daten werden im Piggyback-Verfahren an diesen Host geliefert.
In den kommerziellen Editionen können Sie mithilfe der dynamischen Konfiguration die Container-Hosts auch automatisch anlegen und entfernen lassen.
2. Einrichtung
2.1. Agent und Plugin installieren
Damit Sie einen Docker-Node mit Checkmk überwachen können, muss diese zunächst mit dem normalen Linux-Agenten überwacht werden. Dadurch erhalten Sie ein Grund-Monitoring 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, das Sie hier finden: Setup > Agents > Other operating systems > Plugins
Installieren Sie das Plugin in das Plugin-Verzeichnis des Agenten (im Regelfall /usr/lib/check_mk_agent/plugins).
Detaillierte Informationen zur Installation eines Agentenplugins finden Sie im Artikel zum Linux-Agenten.
root@linux# install -m 0755 mk_docker.py /usr/lib/check_mk_agent/pluginsIn den kommerziellen Editionen können Sie alternativ auch mit der Agentenbäckerei arbeiten, welche für Docker den entsprechenden Regelsatz bereitstellt: Docker node and containers
Beachten Sie, das die Python-Bibliothek docker benötigt wird (nicht docker-py).
Es ist mindestens Version 2.6.1 notwendig.
Mit python auf der Kommandozeile können Sie dies leicht überprüfen:
root@linux# python3
Python 3.8.10 (default, Nov 26 2021, 20:14:08)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import docker
>>> docker.version
'5.0.3'Falls notwendig, können Sie die Bibliothek mit pip3 installieren:
root@linux# pip3 install dockerAchtung: 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 Namensraum zur Verfügung!
Wenn Sie docker-py (oder beide Varianten) installiert haben, reicht eine alleinige Deinstallation nicht aus, da pip3 den Namensraum nicht reparieren kann.
Um sicher zu stellen, dass die korrekte Version installiert ist, führen Sie in diesem Fall folgende Befehle aus:
root@linux# pip3 uninstall docker-py docker
root@linux# pip3 install dockerWenn Sie jetzt in Checkmk die Service-Erkennung durchführen und die Änderungen aktivieren, sollten Sie zunächst einige neue Services finden, welche den Docker-Node selbst betreffen:
2.2. Plugin feinjustieren
Sie können 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).
Erstellen Sie dazu auf dem Docker-Host eine Konfigurationsdatei unter /etc/check_mk/docker.cfg.
Eine Vorlage mit ausführlichen Erläuterungen hierzu finden Sie im Checkmk Verzeichnis unter ~/share/check_mk/agents/cfg_examples/docker.cfg.
In den kommerziellen Editionen können Sie alle Parameter bequem mit der Agentenbäckerei einstellen.
2.3. Container überwachen
Container-Hosts anlegen
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 im Setup Hosts mit den richtigen Namen anzulegen und die Services werden diesen automatisch zugeordnet.
In den kommerziellen Editionen können Sie diese Hosts automatisch anlegen lassen. Verwenden Sie dazu in der dynamischen Konfiguration den Konnektor Piggyback. Sie können die Hosts auch von Hand anlegen. Beachten Sie dabei Folgendes:
Der Host-Name 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).Falls die Container keine eigene IP-Adresse haben (was meist der Fall ist), stellen Sie im Abschnitt Network address das Attribut bei IP address family auf No IP ein.
Bei Monitoring agents stellen Sie Checkmk agent / API integrations unbedingt auf No API integrations, no Checkmk agent ein.
Das Feld Parents im Abschnitt Basic settings können Sie auf den Host-Namen des Docker-Nodes setzen.
Wichtig ist ferner, dass der Docker-Node und deren Container von der selben Checkmk Instanz aus überwacht werden.
Nachdem Sie die Container-Hosts angelegt und die Service-Erkennung durchgeführt haben, tauchen in dieser 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 Informationen des Node zeigen (z.B. CPU load, Temperatur und viele weitere Betriebssystemparameter), wurden diese entfernt.
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 optional anders konfigurieren.
Setzen Sie hierzu in der Konfigurationsdatei docker.cfg (siehe Plugin feinjustieren) die Option container_id auf long, um die vollständige Container-ID als Name zu verwenden, oder auf name, um den Container-Namen zu verwenden.
Nutzer der kommerziellen Editionen können dies in der Agentenbäckerei mit Hilfe der Regel Docker node and containers, Option Host name used for containers einstellen.
Übrigens: Mit dem Regelsatz Access to Agents > General Settings > Hostname translation for piggybacked hosts können Sie recht flexibel Regeln zur Umbenennung von Host-Namen, die in Piggyback-Daten enthalten sind, festlegen. Damit können Sie z.B. auch eine Lösung erstellen, für den Fall, dass Sie auf zwei verschiedenen Docker-Nodes Container mit dem gleichen Namen haben.
Im Artikel Der Piggyback-Mechanismus finden Sie weitere Möglichkeiten und eine genauere Beschreibung hierzu.
Host-Zustand überwachen
Da der Host-Zustand eines Containers nicht unbedingt über TCP-Pakete oder ICMP geprüft werden kann, muss dieser anders ermittelt werden. Hier bietet sich der zum jeweiligen Container gehörige Service Docker container status an. Dieser prüft ohnehin, ob der Container läuft und kann daher als sicheres Mittel verwendet werden, um den Host-Zustand zu ermitteln. Legen Sie dazu eine Regel in dem Regelsatz 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:
Den Agenten direkt im Container betreiben
Um Details im Container selbst zu überwachen (z.B. laufende Prozesse, Datenbanken, Log-Dateien, etc.), ist es notwendig, dass der Checkmk Agent im Container selbst installiert ist und dort ausgeführt wird.
Das gilt insbesondere für das Ausrollen von Agentenplugins.
Die drei Plugins mem, cpu und diskstat (Disk-I/O) funktionieren allerdings auch ohne Agent im Container und werden vom Checkmk Agenten auf dem 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 des Docker-Nodes berechnet. Stattdessen läuft ein separater Agent in jedem Container. Der Aufruf erfolgt aber nach wie vor gebündelt über den 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 dem 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.
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 gegebenenfalls, ob auf dem Host ein Checkmk Agent der Version 1.5.0 oder höher installiert ist.
Falls die Version des Agenten auf dem Host passt, prüfen Sie als nächstes, ob die Daten in der Ausgabe des Agenten enthalten sind. Sie können die Ausgabe als Textdatei herunterladen: in einer Host-Ansicht im Monitoring über den Eintrag Download agent output des Aktionsmenüs:
Oder Sie durchsuchen direkt den Agent-Cache. Die Ausgabe in dem folgenden Beispiel ist für die Anschaulichkeit auf die Ausgaben zum Node 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. Für den Service Docker node info wird der folgende Befehl benutzt. Dieser muss auf dem Host in exakt dieser Form ausführbar sein. Prüfen Sie dann gegebenenfalls Ihre Docker-Installation:
root@linux# docker info 2>&13.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 den Regelsatz 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 das folgende Verzeichnis prüfen:
OMD[mysite]:~$ ls -l tmp/check_mk/piggyback/
76adfc5a7794 f0bced2c8c96 bf9b3b8538344. Host-Labels
In Checkmk gibt es sogenannte Host-Labels. Das Docker-Monitoring setzt unter anderem diese automatischen Labels:
für den Docker-Node das Label
cmk/docker_object:node,für jeden Container die Labels
cmk/docker_image,cmk/docker_image_name,cmk/docker_image_versionundcmk/docker_object.
Diese Labels können Sie z.B. in Bedingungen für Ihre Regeln verwenden, um Ihre Monitoring-Konfiguration abhängig von dem Image zu machen, das in einem Container verwendet wird.
5. Dateien und Verzeichnisse
| Pfad | Bedeutung |
|---|---|
|
Hier legt Checkmk die Piggyback-Daten 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. |
|
Hier wird die jeweils jüngste Agentenausgabe aller Hosts temporär gespeichert. Der Inhalt einer Datei zu einem Host ist identisch zu dem Befehl |