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: 11. Oktober 2018

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 Edition 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 der  Checkmk Enterprise Edition 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

Beachten Sie, das ab der 1.6.0 die Python Bibliothek docker mindestens in der Version 2.0.0 installiert sein muss (nicht docker-py). Diese können sie mit dem Befehl

root@linux# pip install docker

installieren.

Sie können die installierte docker Version prüfen mit dem Befehl

root@linux# python -c 'import docker; print(docker.__version__)'

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 bitte die Befehle

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

aus.

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 Standart 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 der  Checkmk Enterprise Edition 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  Checkmk Enterprise Edition 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 Standarteinstellung 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 Edition dies in der Agentenbäckerei einstellen.

.

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

Agentenplugins im Container

In dem Moment, wo Sie im Container spezielle Agentenplugins benötigen (z. B. zur Überwachung von Logdateien oder von einer Datenbank), müssen Sie in jedem Fall den Checkmk-Agenten inklusive der Plugins im Container installieren. Der Aufruf erfolgt ab nach wie vor über den Docker-Node im Piggyback-Verfahren.

Den Agent direkt im Container betreiben

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-Hosts geholt. Stattdessen läuft ein separater Agent in jedem Container. Checkmk erkennt vollkommen automatisch, ob in dem Container ein Agent vorhanden ist, so dass die Daten immer nur einmal abgeholt werden.

Das 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 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 --format "{{json .}}" 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. 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.