Dynamische Host-Verwaltung

Mit der Piggyback-Verbindung werden — wenig überraschend — Piggyback-Daten ausgewertet. Dieser Verbindungstyp ist in Checkmk universell einsetzbar, denn der Piggyback-Mechanismus wird von Checkmk in allen Situationen verwendet, wo die Abfrage eines Hosts (meist per Spezialagent) Daten zu anderen Hosts liefert (meist virtuelle Maschinen oder Cloud-Objekte).

Checkmk nutzt Piggyback zum Beispiel bei der Überwachung von Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP), Kubernetes, Docker und VMware ESXi. In allen diesen Fällen werden beim Monitoring automatisch Daten zu anderen Hosts, z.B. den virtuellen Maschinen (VM), geholt, die nicht direkt per Netzwerk angesprochen werden und auf denen auch kein Checkmk-Agent laufen muss. Solche Hosts können Sie automatisch ins Monitoring aufnehmen und auch wieder entfernen lassen.

Um eine Piggyback-Verbindung zu nutzen, benötigen Sie als einzige Voraussetzung 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:

Wenn dieses Verzeichnis nicht leer ist, dann wurden in dieser Instanz Piggyback-Daten erzeugt.

Checkmk 2.4.0 bietet ab Checkmk Cloud, d. h. für Checkmk Cloud und Checkmk MSP, eine experimentelle Unterstützung für die Verarbeitung von OpenTelemetry-Metriken. Dafür sammelt in Checkmk ein OpenTelemetry-Kollektor Metrikdaten, die der Kollektor per OpenTelemetry Protocol (OTLP) erhält oder über einen Prometheus-Endpunkt abruft. Bei der Konfiguration des Kollektors werden außerdem Regeln aufgestellt, um aus den Daten Host-Namen für Checkmk zu erzeugen. Fertig konfiguriert legt der Kollektor los, sammelt die Daten und legt sie in der Checkmk-Instanz ab mit Dateinamen, die den Host-Namen entsprechen.

Die Einrichtung von OpenTelemetry einschließlich des OpenTelemetry-Kollektors wird in einem eigenen Artikel beschrieben, der hier verlinkt wird, sobald er geschrieben ist.

Die OpenTelemetry-Daten sind in der Instanz immer dann verfügbar, wenn der OpenTelemetry-Kollektor korrekt aufgesetzt wurde. Sie können das auf der Kommandozeile überprüfen, denn die OpenTelemetry-Daten werden im Verzeichnis ~/tmp/check_mk/otel_collector angelegt:

Wenn dieses Verzeichnis nicht leer ist, dann wurden in dieser Instanz OpenTelemetry-Daten erzeugt.

Der erste Teil der Konfiguration sind die General properties:

Hier vergeben Sie, wie so oft, eine eindeutige ID dieser Verbindung und einen Titel. Wichtig ist ferner die Auswahl der Checkmk-Instanz, auf der diese Verbindung laufen soll. Da die Daten immer nur lokal verarbeitet werden können, muss die Verbindung immer einer konkreten Instanz zugeordnet werden.

Der zweite Teil sind die Verbindungseigenschaften (Connection properties). Da es hier einiges zu konfigurieren gibt, nehmen wir uns die Optionen Stück für Stück vor.

Für eine Piggyback-Verbindung wählen Sie Piggyback data als Connector type aus.

Mit Restrict source hosts können Sie die Hosts auf die Piggyback-Hosts einschränken. Das sind in der Regel die Hosts, für die jeweils ein Spezialagent eingerichtet wurde. Nur für diese Hosts wird die dynamische Host-Verwaltung aktiv. Die Einschränkung erfolgt in dem zugehörigen Eingabefeld, dessen Inhalt als regulärer Ausdruck interpretiert wird. Wenn Sie das erste Eingabefeld editiert haben, wird automatisch das nächste geöffnet, das heißt, Sie können mehrere reguläre Ausdrucke festlegen.

Mit dem Sync interval bestimmen Sie, wie oft die Verbindung 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 Daten stattfinden kann. In dynamischeren Umgebungen können Sie sowohl Check-Zeitraum als auch Verbindungsintervall auch auf deutlich kleinere Werte einstellen. Dies hat allerdings auch eine höhere CPU-Auslastung auf dem Checkmk-Server zur Folge.

Unter Piggyback creation options muss mindestens ein Eintrag existieren. Mit Add new entry können Sie auch weitere hinzufügen:

Hier geht es um die Eigenschaften der automatisch erzeugten Hosts, für die Sie zwei wichtige Dinge festlegen können: In welchem Ordner die Hosts erzeugt werden sollen (Create hosts in) und welche Host-Attribute gesetzt werden sollen. Vier wichtige Attribute sind dabei voreingestellt, welche für Piggybacked-Host meistens sinnvoll sind:

Nur wenn Sie die Checkbox bei Delete vanished hosts aktivieren, werden Hosts auch wieder entfernt, wenn Sie in Ihrer dynamischen Umgebung verschwunden sind.

Möchten Sie nicht automatisch alle Piggybacked-Hosts anlegen, so können Sie das mit der Option Only add matching hosts mit einem regulären Ausdruck einschränken.

Im dritten und letzte Teil der Verbindungseigenschaften können Sie durch Aktivieren der Checkbox bei Service discovery festlegen, dass auf den automatisch erzeugten Hosts eine Service-Erkennung durchgeführt wird:

Die restlichen drei Optionen beeinflussen das Entfernen der automatisch erstellten Hosts, ein Thema, das in einem eigenen Kapitel noch detailliert erläutert wird.

Die Option Prevent host deletion after initialization betrifft einen kompletten Neustart des Checkmk-Servers selbst. Denn in dieser Situation fehlen erst einmal die 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 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.

Die Optionen bei der Erstellung einer Piggyback- und OpenTelemetry-Verbindung, die ab Checkmk Cloud eingerichtet werden kann, sind nahezu identisch. Daher werden die Eigenschaften einer OpenTelemetry-Verbindung im Schnelldurchlauf vorgestellt.

Für eine OpenTelemetry-Verbindung wählen Sie Opentelemetry collector data als Connector type aus.

Restrict source hosts ist für OpenTelemetry nicht relevant. Möchten Sie nicht automatisch alle Hosts anlegen lassen, so können Sie das mit der Option Only add matching hosts weiter unten erreichen. Mit Sync interval bestimmen Sie, wie oft die Verbindung nach neuen Hosts suchen soll.

Unter Open telemetry hosts creation options legen Sie fest, in welchem Ordner die Hosts erzeugt werden sollen (Create hosts in) und welche Host-Attribute gesetzt werden sollen. Zwei Attribute sind dabei voreingestellt:

Nur wenn Sie die Checkbox bei 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 lassen, so können Sie das mit der Option Only add matching hosts mit einem regulären Ausdruck einschränken.

Durch Aktivieren der Checkbox bei Service discovery legen Sie fest, dass auf den automatisch erzeugten Hosts eine Service-Erkennung durchgeführt wird. Dies führt allerdings nur dann zum gewünschten Ergebnis, wenn der Spezialagent für OpenTelemetry eingerichtet ist.

Die beiden letzten Optionen Prevent host deletion after initialization und Validity of outdated data beeinflussen das Entfernen der automatisch erstellten Hosts. Diese Optionen wirken so, wie es bei der Piggyback-Verbindung beschrieben ist. Das Entfernen der automatisch erstellten Hosts wird in einem eigenen Kapitel detailliert erläutert.

Nachdem Sie gespeichert haben, erscheint die Verbindung in der Verbindungsliste. Sie kann aber erst ausgeführt werden, wenn Sie die Änderungen aktiviert haben. Erst dadurch nimmt die Verbindung ihren Dienst auf.

Lassen Sie sich daher nicht von der Meldung irritieren, welche zunächst nach dem Speichern in der Status-Spalte erscheint:
Connection 'my_connection' isn’t found: consider activating changes

Nach dem Speichern der Verbindungseigenschaften 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 von der dynamischen Host-Verwaltung automatisch aktiviert wurden. Die neuen Hosts sind dann bereits im Monitoring und werden regelmäßig überwacht.

Für jede Verbindung zeigt die Verbindungsliste in der Spalte Actions Symbole, um Aktionen auszuführen:

Einige der folgenden Symbole werden nur für eine aktivierte Verbindung angezeigt:

Wenn Sie dem DCD bei der Arbeit zusehen möchten, finden Sie in der Liste der Verbindungen 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.

Die Log-Datei des DCD ist ~/var/log/dcd.log. Hier ist ein Beispiel, welches zur vorherigen Abbildung passt: