Podman überwachen

Auf dem Podman-Host muss der Checkmk-Agent bereits installiert und registriert sein.

Zusätzlich zum Agenten benötigen Sie noch das Agentenplugin mk_podman.py, das Sie in Checkmk Community über Setup > Agents > Linux > Plug-ins finden. In den kommerziellen Editionen gelangen Sie im Setup-Menü über Agents > Windows, Linux, Solaris, AIX zunächst in die Agentenbäckerei, wo Sie die gebackenen Pakete finden. Von dort aus kommen Sie mit dem Menüeintrag Related > Linux, Solaris, AIX files zur Liste der Agentendateien.

Installieren Sie das Plugin auf dem Podman-Host in das Plugin-Verzeichnis des Agenten (im Standardfall /usr/lib/check_mk_agent/plugins):

Ausführlichere Informationen zur Installation eines Agentenplugins finden Sie im Artikel zum Linux-Agenten.

Wenn Sie im Anschluss in Checkmk eine Service-Erkennung auf dem zugehörigen Host durchführen, sollten Sie bereits einige Services sehen, die das Wort Podman im Namen tragen:

Sollten Sie an dieser Stelle jedoch noch keine Podman-Services finden, dann kann dies daran liegen, dass die automatische Erkennung des Agentenplugins auf den üblichen Wegen nicht mit Ihrer Podman-Instanz kommunizieren konnte. In diesem Fall, und auch wenn Sie gewisse Parameter umstellen wollen, müssen Sie dem Agentenplugin noch eine Konfiguration mitgeben. Wie das machen, erfahren Sie im folgenden Kapitel Agentenplugin konfigurieren.

Das Agentenplugin findet im Regelfall selbst heraus, wie es mit Podman auf dem jeweiligen Host kommunizieren kann. Falls diese automatische Erkennung jedoch fehlschlägt oder Sie festlegen möchten, dass nur bestimmte Sockets oder beispielsweise nur das Root-Socket abgefragt werden sollen, dann können Sie das Plugin entsprechend konfigurieren.

Erstellen Sie dazu auf dem Podman-Host eine Konfigurationsdatei mit dem Namen mk_podman.cfg im Konfigurationsverzeichnis des Agenten. Im Standardfall lautet dieses /etc/check_mk/.

Eine Vorlage für diese Konfigurationsdatei mit ausführlichen Erläuterungen finden Sie als Instanzbenutzer Ihrer Checkmk-Instanz im Verzeichnis ~/share/check_mk/agents/cfg_examples/mk_podman.cfg. In der grafischen Oberfläche von Checkmk Community finden Sie die Beispielkonfiguration wieder über Setup > Agents > Linux > Plug-ins. In den kommerziellen Editionen gelangen Sie im Setup-Menü über Agents > Windows, Linux, Solaris, AIX zunächst in die Agentenbäckerei. Von dort aus kommen Sie mit dem Menüeintrag Related > Linux, Solaris, AIX files zur Liste der Agentendateien.

Auf eine zentrale Einstellungsmöglichkeit möchten wir allerdings auch an dieser Stelle kurz eingehen. Dabei handelt es sich um die connection_method, also die Art und Weise, wie mk_podman.py versucht, Ihre Podman-Instanz anzusprechen. Standardmäßig versucht das Agentenplugin, über ein Unix-Socket mit der API von Podman zu sprechen. Alternativ können Sie das Plugin anweisen, die Überwachung über das Kommando podman durchzuführen. Eine entsprechende Konfiguration dafür könnte so aussehen:

Nachdem Sie Ihre Konfiguration wie gewünscht angepasst haben, sind Sie bereit zum Überwachen von Podman-Containern.

Das eigentlich Interessante bei der Überwachung von Podman ist natürlich das Überwachen der Container. Auch diese Daten besorgt das Agentenplugin. Allerdings werden die Services nicht dem Podman-Host zugeordnet, sondern Checkmk bildet jeden Container als eigenen überwachbaren Host ab.

Die Zuordnung geschieht über den Piggyback-Mechanismus. 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 Host-Verwaltung den Verbindungstyp Piggyback data. Sie können die Hosts auch von Hand anlegen.

Beachten Sie dabei Folgendes:

Nachdem Sie die Container-Hosts angelegt und die Service-Erkennung durchgeführt haben, tauchen in dieser weitere Services auf.

Die Namen für die Container-Hosts erzeugt bereits das Agentenplugin mk_podman.py. Standardmäßig verknüpft das Plugin dafür den Namen des Podman-Hosts per Unterstrich mit dem Namen des Containers. Abweichend davon können Sie das Agentenplugin anweisen, den Container-Namen mit der Container-ID zu kombinieren, oder tatsächlich nur den Container-Namen zu verwenden. In der Konfigurationsdatei des Agentenplugin müssen Sie dafür die Option piggyback_name_method auf name_id beziehungsweise name setzen. Wenn Sie sich für eine dieser beiden Methoden entscheiden, müssen Sie allerdings anderweitig sicherstellen, dass es in Checkmk nicht zu Namenskollisionen kommt. In Checkmk kann es jeden Host-Namen nur genau einmal geben.

Falls Sie diese Namen dann noch nachträglich ändern wollen, um beispielsweise direkt am Host-Namen bestimmte Informationen ablesen zu können, steht Ihnen der Regelsatz Host name translation for piggybacked hosts zur Verfügung. Damit können Sie recht flexibel Regeln zur Umbenennung von Host-Namen, die in Piggyback-Daten enthalten sind, festlegen. In dem folgenden Beispiel wird allen Containern, die über den Host mypodmanhost Huckepack mitgebracht werden, die Zeichenkette mypodmanhost- vorangestellt.

Im Artikel Der Piggyback-Mechanismus finden Sie weitere Möglichkeiten und eine genauere Beschreibung hierzu.

Im Auslieferungszustand enthält jede Checkmk-Instanz bereits eine Regel im Regelsatz Host check command, die dafür sorgt, dass jeder Container-Host den Zustand des zu diesem Host gehörigen Service Status erhält. Diese Regel sollte unverändert bleiben bzw. genau so eingerichtet werden:

Der Service Status prüft eben, ob der Container läuft und kann daher als sicheres Mittel verwendet werden, um den Host-Zustand zu ermitteln. Da jeder Container-Host automatisch das Host-Label cmk/podman/object:container zugewiesen bekommt, wird dieses hier als Bedingung verwendet.

Sollte die Einrichtung nicht klappen, gibt es verschiedene Möglichkeiten der Analyse des Problems.

Prüfen Sie zuerst die Ausgabe des Checkmk-Agenten. Diesen erhalten Sie in der Host-Ansicht im Monitoring über den Eintrag Download agent output des Aktionsmenüs.

Oder Sie durchsuchen als Instanzbenutzer direkt den Agent-Cache.

Sollte die Ausgabe des Agenten keine Sektionen beinhalten, die mit <<<podman beginnen, müssen Sie auf dem Podman-Host weiter nach der Ursache suchen.

Führen Sie dafür auf dem Podman-Host das Agentenplugin manuell aus:

Die Ausgabe von mk_podman.py wird auch im Fehlerfall Hinweise darauf geben, was schief gelaufen ist. Falls das Agentenplugin Podman auf dem Host beispielsweise nicht finden kann, dann wird es diesen Umstand unumwunden mitteilen:

Falls nur ein Container-Host keine Daten erhält bzw. keine Services für diesen erkannt werden, prüfen Sie zuerst, ob die Piggyback-Daten zu diesem Host vorhanden sind. Prüfen Sie dazu erneut den Inhalt der Agentenausgabe dahingehend, ob Sektionen für den Container-Host vorhanden sind. Sie können die Agentenausgabe beispielsweise nach der ID des Containers durchsuchen.

Als Instanzbenutzer können Sie prüfen, ob zu einem Container Piggyback-Daten angelegt wurden. Im Verzeichnis tmp/check_mk/piggyback müssen Sie Verzeichnisse finden, die zu Ihren Containern gehören.

Wenn Sie die Host-Namen nicht per Host name translation for piggybacked hosts verändern, sollten Sie hier Verzeichnisse finden, die der in der Konfiguration vorgegebenen Piggyback-Host-Benennung entsprechen. Die Verzeichnisse im folgenden Beispiel setzen sich aus dem Namen des Containers und seiner ID zusammen.