Dynamische Host-Konfiguration

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.

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 REST-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.

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.

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.

Beachten Sie, dass es mit der Regel Automatic host removal für alle Hosts die Möglichkeit gibt, diese automatisch entfernen zu lassen. Beide Optionen zum Lifecycle Management arbeiten unabhängig voneinander, d.h. ein Host wird entfernt, wenn eine der beiden Voraussetzungen erfüllt ist.

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.

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.

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.

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: