Wir nutzen Cookies, um Ihnen eine optimale Nutzung dieser Webseite zu ermöglichen. Mehr Informationen finden Sie im Datenschutzhinweis. Wir nehmen an, dass Sie damit einverstanden sind, falls Sie diese Webseite weiter besuchen.

Ihre Cookie-Einstellungen
Ihre Einstellungen wurden aktualisiert.
Damit die Änderungen wirksam werden, löschen Sie bitte Ihre Browser-Cookies und den Cache und laden dann die Seite neu.

Docker überwachen

Checkmk Manual
Letzte Aktualisierung: 5. September 2019

Suche im Handbuch

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 ab der Version 1.5.0 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 Checkplugins.

Neben den Status- und Inventurinformationen, die Checkmk über die 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.

Ab Version 1.6.0 der  Checkmk Enterprise Editions können Sie mithilfe der dynamischen Konfiguration die Container-Hosts sogar automatisch anlegen und entfernen lassen.

2. Einrichtung

2.1. Installation von Agent und Plugins

Damit Sie eine Docker-Node mit Checkmk überwachen können, muss diese 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 folgende Agent-Plugins:

  • In der Version 1.5.0 die beiden Plugins mk_docker_node und mk_docker_container_piggybacked
  • Ab Version 1.6.0 nur das Plugin mk_docker.py

Installieren Sie die Plugins bzw. 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 entsprechende Regelsätze bereitstellt:

  • In der Version 1.5.0 die Regelsätze Docker node und Piggybacked Docker containers
  • Ab Version 1.6.0 der Regelsatz Docker node and containers

Bitte beachten Sie, das ab der 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 2019, 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 mit pip installieren:

root@linux# pip install docker

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 sicher zu stellen, dass die korrekte Version installiert ist, führen Sie in diesem Fall bitte folgenden Befehle aus:

root@linux# pip uninstall docker-py docker
root@linux# pip install docker

Wenn Sie jetzt im 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. Finetuning des Plugins

Ab der 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 nach /etc/check_mk/docker.cfg. 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 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:

  • Der Hostname muss exakt dem Verzeichnis entsprechen, welches in tmp/check_mk/piggyback angelegt 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 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 die Docker-Node und dessen Container von der selben Checkmk-Instanz aus überwacht werden.

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.

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 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 Piggydaten 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.

Ü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:

Den Agent direkt im Container betreiben

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 detailierteres 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.

3. Diagnosemöglichkeiten

3.1. Diagnose für eine Docker-Node

Sollte die Einrichtung nicht klappen, gibt es verschiedene Möglichkeiten der Analyse des Problems. Der Checkmk-Agent unterstützt die Überwachung von Docker erst ab Version 1.5.0. Prüfen Sie daher, ob auf dem Host ein Agent mit dieser oder einer höheren Version 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 über den Button Download agent output in der GUI in dem Dropdown des Hosts herunterladen:

Oder Sie durchsuchen direkt den Agent-Cache. Die Ausgabe in dem folgenden Beispiel ist für die Anschaulichkeit auf die Ausgaben zur 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 in Version 1.5.0 der folgende Befehl benutzt. Dieser muss auf dem Hostsystem in exakt dieser Form ausführbar sein. Prüfen Sie dann gegebenenfalls Ihre Docker-Installation:

root@linux# docker info 2>&1

3.2. Diagnose für einen Containerhost

Falls der Containerhost keine Daten erhält, bzw. keine Services erkannt werden, prüfen Sie zuerst, ob die Piggybackdaten zu diesem Host vorhanden sind. Der Name des Hosts muss identisch zu 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 Piggybackdaten angelegt werden, können Sie das folgende Verzeichnis prüfen:

OMD[mysite]:~$ ls -l tmp/check_mk/piggyback/
76adfc5a7794  f0bced2c8c96  bf9b3b853834

4. Hostlabels

Ab Version 1.6.0 von Checkmk gibt es sogenannte Hostlabels. Das überarbeitete Dockermonitoring 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 abhängig vom in einem Container verwendeten Image zu machen.

5. 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 dem Befehl cmk -d myserver123.