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.

Checkmk 1.6 ist da! Mehr dazu hier!

Dynamische Hostkonfiguration

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.

Ab Version 1.6.0 der  Checkmk Enterprise Edition unterstützt Sie Checkmk bei diesem Thema mit einem neuen 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 und 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 alle künftigen 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 kann es in Zukunft auch viel einfacher werden, Hosts aus einer vorhandenen CMDB automatisch nach Checkmk zu übernehmen.

2. Verwalten von Hosts mit dem DCD

2.1. Der Piggback-Konnektor

In Version 1.6.0 von Checkmk ist der DCD zunächst nur mit einem einzigen Konnektor ausgestattet: demjenigen für Piggybackdaten. 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 Cloudobjekte).

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 in WATO aufnehmen und auch wieder entfernen lassen, um so immer zeitnah die Realität abzubilden.

Dazu analysiert der DCD die vorhandenen Piggbackdaten, vergleicht, welche der Hosts bereits in WATO 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 WATO editierbar.

2.2. Dynamische Konfiguration einrichten

Sind Piggybackdaten da?

Als einzige Voraussetzung, um den DCD zu nutzen, benötigen Sie Piggybackdaten. 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 Piggybackdaten werden von Checkmk im Verzeichnis tmp/check_mk/piggyback angelegt:

OMD[mysite]:~$ ls tmp/check_mk/piggyback
myvm01  myvm02  myvm03

Wenn dieses Verzeichnis nicht leer ist, dann wurden in dieser Instanz Piggybackdaten erzeugt.

Generelle Einstellungen eines Konnektors

Gehen Sie nun in die Hostverwaltung von WATO. Dort finden Sie den Knopf Dynamic config. Dieser bringt Sie zur Konfiguration des DCD bzw. von dessen Konnektoren:

Legen Sie mit New connection eine neue Verbindung an. 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 dieser Konnektor laufen soll. Da Piggybackdaten 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 das regulären Checkintervall von einer Minute beibehalten haben, macht es keinen Sinn, das wesentlich öfter zu machen, da ja maximal einmal pro Minute eine Änderung der Piggybackdaten stattfinden kann. In höher dynamischen Umgebungen können Sie sowohl Checkinterval als auch das Konnektorintervall auch auch deutlich kleinere Werte einstellen. Dies hat allerdings auch eine höhere CPU-Auslastung auf dem Checkmk-Server zur Folge.

Wichtig ist jetzt, dass Sie mindestens eine Piggyback creation option hinzufügen (Add new element).

Hier können Sie zwei wichtige Dinge festlegen: In welchem Ordner die Hosts erzeugt werden sollen (hier z. B. AWS Cloud 02) und welche Hostattribute gesetzt werden sollen. Vier wichtige Attriute sind dabei voreingestellt, welche für Piggyhosts meistens Sinn ergeben:

  1. Kein Monitoring per SNMP
  2. Kein Checkmk-Agent auf dem Host selbst (Daten kommen ja per Piggyback)
  3. Dass Piggybackdaten immer erwartet werden (und es einen Fehler gibt, wenn diese fehlen)
  4. Und dass die Hosts keine IP-Adresse haben

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 den Sie die Überwachung von z. B. AWS eingerichtet haben.

Letzteres können Sie mit der Option Only add hosts from matching source hosts erreichen. Diese bezieht sich auf die Namen der Hosts, welche Piggybackdaten erzeugen.

Activate Changes

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 operativen Monitoring auf.

Wenn das Activate changes bei Ihrer Installation sehr lange dauert, können Sie mit Group "Activate changes" dafür sorgen, dass das nach Möglichkeit nicht sofort bei jedem neuen Host sofort passiert, sondern man etwas „zusammenkommen lässt“.

Ferner können Sie das automatische Aktivieren von Änderungen auch für bestimmte Tageszeiten komplett verbieten – z. B. für die Tageszeiten, wo ihr Monitoringsystem 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 noch nicht ausgeführt werden, bevor Sie ein Activate Changes durchgeführt 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 Activate Changes nimmt die Verbindung automatisch ihren Betrieb auf. Das kann so schnell gehen, dass Sie bereits direkt nach dem Aktivieren der Änderungen sofort sehen, wie in WATO Hosts 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 WATO löschen lassen. Das klingt erstmal sehr logisch. Was genau das „nicht mehr gibt“ allerdings bedeutet, 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 eine DCD-Verbindung stilllegen (do not activate this dynamic configuration connection) oder ganz entfernen, bleiben alle Hosts, die durch diese Verbindung erzeugt wurden, erhalten. Bei Bedarf müssen Sie diese von Hand löschen.
Piggyback-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 Piggybackdaten mehr. In diesem Fall werden die automatisch erzeugten Hosts nach einer Stunde automatisch entfernt.
Piggyback-Host ist nicht erreichbar Wenn Ihre Cloudumgebung mal nicht erreichbar 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 Piggybackdaten 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 Piggybackdaten verloren gehen, da diese in der RAM-Disk liegen).
Ein Host ist nicht mehr in den Piggybackdaten 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 Konnektoreneigenschaften 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 Neustarts des Checkmk-Servers selbst. Denn in dieser Situation fehlen erstmal Piggybackdaten 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 Alarmen zu schon bekannten Problemen einhergeht), wird per Default in den ersten 10 Minuten auf ein Löschen generell verzichtet. Diese Zeit können Sie hier einstellen.

Die Option Keep hosts while piggyback source sends no piggyback data at all for behandelt den Fall, dass ein Host, aufgrund dessen Monitoringdaten etliche Hosts automatisch angelegt wurden, keine Piggybackdaten 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 WATO entfernt werden.

Die Option Keep hosts while piggyback source sends piggyback data only for other hosts for ist ähnlich, behandelt aber den Fall, dass schon noch Piggybackdaten kommen, allerdings für manche Hosts nicht mehr. Das ist der normale Fall wenn z. B. virtuelle Maschinen oder Clouddienste 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:

Im abgebildeten Beispiel sehen Sie einen Fehler, der beim Erzeugen der Konfiguration auftritt: Der Host mit dem Namen Guest_Introspection_(4) konnte nicht angelegt werden, weil durch die runden Klammern im Namen sich kein für Checkmk gültiger Hostname ergibt.

5.2. Das WATO Auditlog

Wenn Sie im WATO auf der Seite sind, wo Sie Änderungen aktivieren können, finden Sie dort einen Knopf mit dem Namen Audit Log. Dieser bringt Sie zu einer Liste aller Änderungen, die in WATO gemacht wurden – egal ob diese bereits aktiviert wurden oder nicht. Suchen Sie nach Einträge vom Benutzer automation. Unter diesem Account arbeitet der DCD und erzeugt Änderungen. So können Sie nachvollziehen, wann er welchen Host angelegt oder entfernthat.

5.3. Die Logdatei des DCD

Die Logdatei des DCD finden Sie auf der Kommandozeile in der Datei var/log/dcd.log. Hier ist ein Beispiel, welches zu obiger Abbilung passt. Auch hier finden Sie die Fehlermeldung, dass ein bestimmter Host nicht angelegt werden konnte:

var/log/dcd.log
2019-09-25 14:45:22,916 [20] [cmk.dcd] ---------------------------------------------------
2019-09-25 14:45:22,916 [20] [cmk.dcd] Dynamic Configuration Daemon (1.6.0-2019.09.25) starting (Site: mysite, PID: 7450)...
2019-09-25 14:45:22,917 [20] [cmk.dcd.ConnectionManager] Initializing 0 connections
2019-09-25 14:45:22,918 [20] [cmk.dcd.ConnectionManager] Initialized all connections
2019-09-25 14:45:22,943 [20] [cmk.dcd.CommandManager] Starting up
2019-09-25 15:10:58,271 [20] [cmk.dcd.Manager] Reloading configuration
2019-09-25 15:10:58,272 [20] [cmk.dcd.ConnectionManager] Initializing 1 connections
2019-09-25 15:10:58,272 [20] [cmk.dcd.ConnectionManager] Initializing connection 'piggy01'
2019-09-25 15:10:58,272 [20] [cmk.dcd.ConnectionManager] Initialized all connections
2019-09-25 15:10:58,272 [20] [cmk.dcd.ConnectionManager] Starting new connections
2019-09-25 15:10:58,272 [20] [cmk.dcd.piggy01] Starting up
2019-09-25 15:10:58,273 [20] [cmk.dcd.ConnectionManager] Started all connections
2019-09-25 15:10:58,768 [40] [cmk.dcd.piggy01] Creation of "Guest_Introspection_(4)" failed: Please enter a valid hostname or IPv4 address. Only letters, digits, dash, underscore and dot are allowed.

6. Dateien und Verzeichnisse

Pfad Bedeutung
tmp/check_mk/piggyback Hier entstehen Piggybackdaten. Für jeden in den Piggbackdaten enthaltenen Zielhost entsteht ein Verzeichnis.
var/log/dcd.log Logdatei des Dynamic Configuration Daemon (DCD)