1. Einleitung
In Cloud- und Containerumgebungen ist es immer öfter der Fall, dass zu überwachende Hosts automatisch entstehen und vergehen. Die Konfiguration des Monitorings hier aktuell zu halten, ist manuell nicht mehr sinnvoll möglich. Aber auch klassische Infrastrukturen wie z.B. VMware-Cluster können sehr dynamisch sein, und selbst wenn eine manuelle Pflege hier noch möglich ist, ist sie doch auf jeden Fall lästig.
Die 
Checkmk Enterprise Editions von Checkmk unterstützen Sie bei diesem
Thema mit einem smarten Werkzeug: dem Dynamic Configuration Daemon
oder kurz DCD. Die dynamische Konfiguration von Hosts bedeutet, dass
aufgrund von Informationen aus der Überwachung von AWS,
Azure, Kubernetes,
VMware und anderen Quellen vollautomatisch Hosts in das
Monitoring aufgenommen, aber auch wieder entfernt werden können.
Der DCD ist dabei sehr generisch gehalten und nicht auf das Anlegen von Hosts beschränkt. Er bildet die Grundlage für künftige Erweiterungen von Checkmk, welche dynamisch die Konfiguration anpassen. Das kann z.B. auch das Verwalten von Benutzern bedeuten. Zu diesem Zweck arbeitet der DCD mit sogenannten Konnektoren. Jeder Konnektor kann aus einer ganz bestimmten Art von Quelle Informationen holen und hat dazu seine eigene spezifische Konfiguration.
Mit speziellen Konnektoren wird es in Zukunft noch einfacher werden, Hosts aus einer vorhandenen CMDB automatisch nach Checkmk zu übernehmen.
2. Verwalten von Hosts mit dem DCD
2.1. Der Piggyback-Konnektor
Derzeit ist der DCD von Checkmk nur mit einem einzigen Konnektor ausgestattet: demjenigen für Piggyback-Daten. Dieser ist jedoch sehr universell, denn der Piggyback-Mechanismus wird von Checkmk in allen Situationen verwendet, wo die Abfrage von einem Host (meist per Spezialagent) Daten zu anderen Hosts liefert (meist virtuelle Maschinen oder Cloud-Objekte).
Hier sind einige Beispiele, wo Checkmk bei der Überwachung Piggyback einsetzt:
In allen diesen Fällen werden beim Monitoring automatisch Daten zu anderen Hosts (z.B. den VMs) geholt, die nicht direkt per Netzwerk angesprochen werden und auf denen auch kein Checkmk-Agent laufen muss. Mit dem DCD können Sie solche Hosts automatisch ins Monitoring aufnehmen und auch wieder entfernen lassen, um so immer zeitnah die Realität abzubilden.
Dazu analysiert der DCD die vorhandenen Piggyback-Daten, vergleicht, welche der Hosts bereits im Setup vorhanden sind und legt die fehlenden Hosts neu an bzw. entfernt inzwischen weggefallene. Dabei sind Hosts, welche vom DCD automatisch angelegt wurden, trotzdem für Sie in der Setup-GUI editierbar.
2.2. Der Automationsbenutzer
In Checkmk gibt es standardmäßig einen Automationsbenutzer. Dieser Benutzer wird von Checkmk angelegt, um automatisierte Abrufe durchführen zu können. Ein existierender Automationsbenutzer ist auch für die dynamische Host-Konfiguration zwingend notwendig.
Haben Sie, aus welchen Gründen auch immer, in Ihrem System diesen Benutzer gelöscht oder geändert, so müssen Sie einen anderen Benutzer mit automatisiertem Zugriff auf die API schaffen. In diesem Fall öffnen Sie über Setup > General > Global settings die globalen Grundeinstellungen:
Mit einem Klick auf Credentials: Use "Checkmk Automation" user kommen Sie zur Bearbeitungsseite der Web-API Verbindung:
Hier können Sie einen anderen Benutzer und dessen Zugriffsdaten (Name, Passwort) eintragen oder Änderungen am bestehenden Automationsbenutzer eintragen.
Sobald Sie die Änderungen mit 
Save gespeichert haben, wird der definierte Benutzer für die Automatisierung genutzt und Sie können mit der dynamischen Host-Konfiguration fortfahren.
2.3. Dynamische Konfiguration einrichten
Sind Piggyback-Daten da?
Als einzige Voraussetzung, um den DCD zu nutzen, benötigen Sie
Piggyback-Daten. Diese haben Sie immer dann, wenn Sie das Monitoring für AWS,
Azure und Co. korrekt aufgesetzt haben. Sie können das auch leicht auf der
Kommandozeile überprüfen, denn die Piggyback-Daten werden von Checkmk im Verzeichnis tmp/check_mk/piggyback
angelegt:
OMD[mysite]:~$ ls tmp/check_mk/piggyback
myvm01 myvm02 myvm03Wenn dieses Verzeichnis nicht leer ist, dann wurden in dieser Instanz Piggyback-Daten erzeugt.
Generelle Einstellungen eines Konnektors
Gehen Sie nun in die Host-Verwaltung. Der Menüeintrag Setup > Hosts > Dynamic host management bringt Sie zur Konfiguration des DCD beziehungsweise dessen Konnektoren:
Legen Sie mit 
Add connection eine neue Verbindung an.
Der erste Teil der Konfiguration sind die General Properties:
Hier vergeben Sie, wie so oft, eine eindeutige ID dieses Konnektors und einen Titel. Wichtig ist ferner die Auswahl der Checkmk-Instanz, auf der dieser Konnektor laufen soll. Da Piggyback-Daten immer nur lokal verarbeitet werden können, muss der Konnektor immer einer konkreten Instanz zugeordnet werden.
Eigenschaften des Konnektors
Der zweite Teil sind die Connection Properties:
Hier ist bereits der Konnektor Piggyback data vorausgewählt (und aktuell auch der einzig mögliche).
Mit dem Sync interval bestimmen Sie, wie oft der Konnektor nach neuen Hosts suchen soll. Wenn Sie den regulären Check-Zeitraum von einer Minute beibehalten haben, macht es keinen Sinn, das wesentlich öfter zu machen, da ja maximal einmal pro Minute eine Änderung der Piggyback-Daten stattfinden kann. In dynamischeren Umgebungen können Sie sowohl Check-Zeitraum als auch Konnektorintervall auch auf deutlich kleinere Werte einstellen. Dies hat allerdings auch eine höhere CPU-Auslastung auf dem Checkmk-Server zur Folge.
Wichtig ist jetzt, dass Sie unter Piggyback creation options mindestens ein neues Element hinzufügen (Add new element). Damit gelangen Sie zu den Einstellungen für automatisch erzeugte Hosts:
Hier können Sie zwei wichtige Dinge festlegen: In welchem Ordner die Hosts erzeugt werden sollen (hier z.B. AWS Cloud 02) und welche Host-Attribute gesetzt werden sollen (für letzteres müssen Sie den Show-more-Modus aktiviert haben). Vier wichtige Attribute sind dabei voreingestellt, welche für piggybacked Hosts meistens Sinn ergeben:
Kein Monitoring per SNMP.
Kein Checkmk-Agent auf dem Host selbst (Daten kommen ja per Piggyback).
Piggyback-Daten werden immer erwartet (und es gibt einen Fehler, wenn diese fehlen).
Die Hosts haben keine IP-Adresse.
Wichtig: Nur wenn Sie Delete vanished hosts aktivieren, werden Hosts auch wieder entfernt, wenn Sie in Ihrer dynamischen Umgebung verschwunden sind.
Möchten Sie nicht automatisch alle Hosts anlegen, so können Sie das mit der Option Only add matching hosts mit einem regulären Ausdruck einschränken. *Wichtig:*Gemeint sind hier die Hosts, welche angelegt werden und nicht die Hosts, über die Sie die Überwachung von z.B. AWS eingerichtet haben.
Letzteres können Sie mit der Option Restrict source hosts erreichen. Diese bezieht sich auf die Namen der Hosts, welche Piggyback-Daten erzeugen.
Änderungen aktivieren
Zwei weitere Optionen befassen sich mit dem automatischen Aktivieren von Änderungen — für den Fall, dass wirklich Hosts angelegt oder entfernt wurden. Denn nur dadurch tauchen diese dann auch im Monitoring auf.
Wenn das Aktivieren der Änderungen bei Ihrer Instanz sehr lange dauert, können Sie mit Group "Activate changes" dafür sorgen, dass das nach Möglichkeit nicht bei jedem neuen Host sofort passiert, sondern nachdem einige „zusammengekommen" sind.
Ferner können Sie das automatische Aktivieren von Änderungen auch für bestimmte Tageszeiten komplett verbieten — z.B. für die Tageszeiten, wo ihr Monitoring-System aktiv betreut wird. Denn wenn der DCD Änderungen aktiviert, werden auch alle anderen Änderungen aktiv, die Sie oder ein Kollege gerade gemacht haben!
Nachdem Sie gespeichert haben, erscheint der Konnektor in der Liste. Er kann aber erst ausgeführt werden, wenn Sie die Änderungen aktiviert haben. Erst dadurch nimmt er seinen Dienst auf. Lassen Sie sich daher nicht von der Meldung Failed to get the status from DCD (The connection 'piggy01' does not exist) irritieren, welche zunächst nach dem Speichern erscheint.
3. Den Konnektor in Betrieb nehmen
3.1. Erstes Aktivieren
Nach dem Speichern der Konnektoreigenschaften und einem Aktivieren der Änderungen nimmt die Verbindung automatisch ihren Betrieb auf. Das kann so schnell gehen, dass Sie bereits direkt nach dem Aktivieren der Änderungen sehen, wie Hosts im Monitoring angelegt wurden:
Wenn Sie diese Seite kurz darauf neu laden, sind diese Änderungen wahrscheinlich schon wieder verschwunden, weil sie ja vom DCD automatisch aktiviert wurden. Die neuen Hosts sind dann bereits im Monitoring und werden regelmäßig überwacht.
4. Automatisches Löschen von Hosts
4.1. Wann werden Hosts entfernt?
Wie oben erwähnt, können Sie den DCD selbstverständlich Hosts, die es „nicht mehr gibt“, automatisch aus dem Monitoring löschen lassen. Das klingt erst einmal sehr logisch. Was genau das „nicht mehr gibt“ allerdings bedeutet, ist auf den zweiten Blick doch etwas komplexer, da es verschiedene Fälle zu betrachten gibt. Wir gehen in folgender Übersicht davon aus, dass Sie die Löschoption aktiviert haben. Denn sonst werden grundsätzlich nie Hosts automatisch entfernt.
| Situation | Was geschieht? |
|---|---|
Entfernen eines DCD-Konnektors |
Wenn Sie einen DCD-Konnektor stilllegen (do not activate this dynamic configuration connection) oder ganz entfernen, bleiben alle Hosts, die durch diesen Konnektor erzeugt wurden, erhalten. Bei Bedarf müssen Sie diese von Hand löschen. |
Piggybacked Host wird nicht mehr überwacht |
Wenn Sie den Host, über den Sie Ihre Cloud- oder Containerumgebung überwachen, aus dem Monitoring entfernen, erzeugt dieser natürlich keine Piggyback-Daten mehr. In diesem Fall werden die automatisch erzeugten Hosts nach einer Stunde automatisch entfernt. |
Piggybacked Host ist nicht erreichbar |
Wenn Ihre Cloud-Umgebung mal nicht erreichbar ist, und der Checkmk-Service, der diese abfragt, auf CRIT geht, so bleiben die erzeugten Hosts auf unbestimmte Zeit im Monitoring. Hier gibt es keinen einstündigen Timeout! |
Der Checkmk-Server selbst ist gestoppt |
Ein Stoppen des ganzen Monitorings führt zwar dazu, dass Piggyback-Daten veralten. Aber natürlich werden angelegte Hosts deswegen nicht gelöscht. Das gleiche gilt, wenn der Checkmk-Server neu gebootet wird (wodurch vorübergehend alle Piggyback-Daten verloren gehen, da diese in der RAM-Disk liegen). |
Ein Host ist nicht mehr in den Piggyback-Daten enthalten |
Das ist quasi der Normalfall: Ein Host in der Cloud-/Containerumgebung ist verschwunden. In diesem Fall wird er sofort aus dem Monitoring entfernt. |
4.2. Konfigurationsmöglichkeiten
Neben der Frage, ob Hosts überhaupt automatisch entfernt werden sollen, gibt es bei den Konnektoreigenschaften noch drei weitere Optionen, die das Löschen beeinflussen und die wir vorhin übersprungen haben:
Die erste Einstellung — Prevent host deletion right after initialization — betrifft einen kompletten Neustart des Checkmk-Servers selbst. Denn in dieser Situation fehlen erst einmal Piggyback-Daten von allen Hosts, bis diese zum ersten Mal abgefragt wurden. Um ein sinnloses Löschen und Wiedererscheinen von Hosts zu vermeiden (welches auch mit wiederholten Benachrichtigungen zu schon bekannten Problemen einhergeht), wird standardmäßig in den ersten 10 Minuten auf ein Löschen generell verzichtet. Diese Zeit können Sie hier einstellen.
Die Option Validity of missing data behandelt den Fall, dass ein Host, aufgrund dessen Monitoring-Daten etliche Hosts automatisch angelegt wurden, keine Piggyback-Daten mehr liefert. Das kann z.B. der Fall sein, wenn ein Zugriff auf AWS und Co. nicht mehr funktioniert. Oder natürlich auch, wenn Sie den Spezialagenten aus der Konfiguration entfernt haben. Die automatisch erzeugten Hosts bleiben dann noch die eingestellte Zeit im System, bevor sie aus der Setup-GUI entfernt werden.
Die Option Validity of outdated data ist ähnlich, behandelt aber den Fall, dass schon noch Piggyback-Daten kommen, allerdings für manche Hosts nicht mehr. Das ist der normale Fall wenn z.B. virtuelle Maschinen oder Cloud-Dienste nicht mehr vorhanden sind. Wenn Sie möchten, dass die entsprechenden Objekte aus Checkmk dann zeitnah verschwinden, dann setzen Sie hier eine entsprechend kurze Zeitspanne.
5. Diagnose
5.1. Ausführungshistorie
Wenn Sie dem DCD bei der Arbeit zusehen möchten, finden Sie in der Liste der Konnektoren bei jedem Eintrag
das Symbol 
. Dieses führt Sie zur Ausführungshistorie:
Sollte aus irgendwelchen Gründen die Erstellung eines Hosts fehlschlagen, sehen Sie dies in der Ausführungshistorie.
5.2. Audit log
Mit Setup > General > Audit log öffnen Sie eine Seite mit der Liste aller Änderungen, die in
der Setup-GUI gemacht wurden — egal ob diese bereits aktiviert wurden oder nicht. Suchen Sie nach
Einträgen vom Benutzer automation bzw. dem Benutzer, den Sie stattdessen autorisiert haben (siehe hierzu Abschnitt Der Benutzer 'automation'). Unter diesem Account arbeitet der DCD und erzeugt
Änderungen. So können Sie nachvollziehen, wann er welchen Host angelegt oder entfernt hat.
5.3. Log-Datei des DCD
Die Log-Datei des DCD ist var/log/dcd.log.
Hier ist ein Beispiel, welches zu obiger Abbildung passt. Auch hier finden Sie die Fehlermeldung,
dass ein bestimmter Host nicht angelegt werden konnte:
2021-11-10 14:45:22,916 [20] [cmk.dcd] ---------------------------------------------------
2021-11-10 14:45:22,916 [20] [cmk.dcd] Dynamic Configuration Daemon (2.0.0p14) starting (Site: mysite, PID: 7450)...
2021-11-10 14:45:22,917 [20] [cmk.dcd.ConnectionManager] Initializing 0 connections
2021-11-10 14:45:22,918 [20] [cmk.dcd.ConnectionManager] Initialized all connections
2021-11-10 14:45:22,943 [20] [cmk.dcd.CommandManager] Starting up
2021-11-10 15:10:58,271 [20] [cmk.dcd.Manager] Reloading configuration
2021-11-10 15:10:58,272 [20] [cmk.dcd.ConnectionManager] Initializing 1 connections
2021-11-10 15:10:58,272 [20] [cmk.dcd.ConnectionManager] Initializing connection 'piggy01'
2021-11-10 15:10:58,272 [20] [cmk.dcd.ConnectionManager] Initialized all connections
2021-11-10 15:10:58,272 [20] [cmk.dcd.ConnectionManager] Starting new connections
2021-11-10 15:10:58,272 [20] [cmk.dcd.piggy01] Starting up
2021-11-10 15:10:58,273 [20] [cmk.dcd.ConnectionManager] Started all connections6. Dateien und Verzeichnisse
| Pfad | Bedeutung |
|---|---|
|
Hier entstehen Piggyback-Daten. Für jeden in den Piggyback-Daten enthaltenen piggybacked Host entsteht ein Verzeichnis. |
|
Logdatei des Dynamic Configuration Daemon (DCD) |