Verteiltes Monitoring

Livestatus ist eine in den Monitoring-Kern integrierte Schnittstelle, mit der andere Programme von außen Statusdaten abfragen und Kommandos ausführen können. Livestatus kann über das Netzwerk verfügbar gemacht werden, so dass eine entfernte Checkmk-Instanz (Remote-Instanz) zugreifen kann. Die Benutzeroberfläche von Checkmk nutzt Livestatus, um alle angebundenen Instanzen zu einer Gesamtsicht zusammenzuführen. Das fühlt sich dann „wie ein großes" Monitoring-System an.

Folgende Skizze zeigt schematisch den Aufbau eines verteilten Monitorings mit Livestatus über drei Standorte. In der Zentrale befindet sich die Checkmk-Instanz Central Site. Von dieser aus werden zentrale Systeme direkt überwacht. Außerdem gibt es die Instanzen Remote Site 1 und Remote Site 2, welche sich in anderen Netzen befinden und die dortigen Systeme überwachen:

Das Besondere an dieser Methode ist, dass der Monitoring-Status der entfernten Instanzen nicht ständig an die Zentrale übertragen wird. Die GUI ruft von den entfernten Instanzen immer nur live diejenigen Daten ab, die ein Benutzer in der Zentrale haben will. Die Daten werden dann in einer kombinierten Ansicht zusammengeführt. Es gibt also keine zentrale Datenhaltung, was riesige Vorteile für die Skalierung bedeutet!

Hier sind einige der Vorteile dieser Methode:

Bei einem verteilten System via Livestatus wie oben beschrieben, ist es durchaus möglich, dass die einzelnen Instanzen von unterschiedlichen Teams eigenverantwortlich gepflegt werden und die Zentralinstanz lediglich die Aufgabe hat, ein zentrales Dashboard bereitzustellen.

Falls aber mehrere oder alle Instanzen von den gleichen Menschen administriert werden sollen, ist eine zentrale Konfiguration viel komfortabler. Checkmk unterstützt dies und wir sprechen dann von einer verteilten Konfigurationsumgebung. Dabei werden alle Hosts und Services, Benutzer und Rechte, Zeitperioden, Benachrichtigungen u.s.w. im Setup der Zentralinstanz zentral gepflegt und dann automatisch nach Ihren Vorgaben auf die Remote-Instanzen verteilt.

So ein System hat nicht nur eine gemeinsame Statusoberfläche, sondern auch eine gemeinsame Konfiguration und fühlt sich dann endgültig wie „ein großes System“ an.

Sie können solch ein System sogar noch um reine Viewer-Instanzen erweitern, die nur als Statusoberflächen dienen, etwa für Teilbereiche oder bestimmte Nutzergruppen.

An die Zentrale werden keine speziellen Anforderungen gestellt. Das bedeutet, dass Sie auch eine schon länger bestehende Instanz ohne weitere Anpassungen zu einem verteilten Monitoring ausbauen können.

Die Remote-Instanzen werden zunächst als neue Instanzen wie üblich mit omd create erzeugt. Dies geschieht dann natürlich auf dem (entfernten) Server, der für die jeweilige Remote-Instanz vorgesehen ist.

Hinweise:

Hier ist ein Beispiel für das Anlegen einer Remote-Instanz mit dem Namen remote1:

Der wichtigste Schritt ist jetzt, dass Sie Livestatus via TCP auf dem Netzwerk freigeben. Beachten Sie dabei, dass Livestatus per se kein abgesichertes Protokoll ist und nur in einem sicheren Netzwerk (abgesichertes LAN, VPN etc.) verwendet werden darf. Das Freigeben geschieht als Instanzbenutzer bei noch gestoppter Instanz per omd config:

Wählen Sie jetzt Distributed Monitoring:

Setzen Sie LIVESTATUS_TCP auf on und tragen Sie für LIVESTATUS_TCP_PORT eine freie Portnummer ein, die auf diesem Server eindeutig ist. Der Default dafür ist 6557:

Nach dem Speichern starten Sie die Instanz wie gewohnt mit omd start:

Merken Sie sich das Passwort für cmkadmin. Sobald die Remote-Instanz der Zentralinstanz untergeordnet wurde, werden sowieso alle Benutzer durch die von der Zentralinstanz ausgetauscht.

Die Instanz ist jetzt bereit. Eine Kontrolle mit netstat zeigt, dass Port 6557 geöffnet ist. Die Bindung an diesen Port geschieht mit einer Instanz des Internet Superservers xinetd, welcher direkt in der Instanz läuft:

Die Konfiguration des verteilten Monitorings wird ausschließlich auf der Zentralinstanz im Menü Setup > General > Distributed Monitoring vorgenommen. Hier verwalten Sie die Verbindungen zu den einzelnen Instanzen. Dabei zählt die Zentrale selbst auch als Instanz und ist bereits in der Liste eingetragen:

Legen Sie jetzt mit Add connection die Verbindung zur ersten Remote-Instanz an:

Bei den Basic settings ist es wichtig, dass Sie als Site ID exakt den Namen der Remote-Instanz verwenden, so wie diese mit omd create erzeugt wurde. Den Alias können Sie wie immer frei vergeben und auch später ändern.

Bei den Einstellungen der Status connection geht es darum, wie die Zentralinstanz den Status der Remote-Instanzen per Livestatus abfragt. Das Beispiel im Screenshot zeigt eine Verbindung mit der Methode Connect via TCP (IPv4). Diese ist für stabile Verbindungen mit kurzen Latenzzeiten optimal (wie z.B. in einem LAN). Optimale Einstellungen bei WAN-Verbindungen besprechen wir weiter unten.

Tragen Sie hier die HTTP-URL zu der Weboberfläche der Remote-Instanz ein und zwar nur den Teil bis vor dem check_mk/. Wenn Sie grundsätzlich per HTTPS auf Checkmk zugreifen, dann ersetzen Sie das http hier durch https. Weitere Details erfahren Sie wie immer in der Inline-Hilfe oder dem Handbuchartikel zu HTTPS mit Checkmk.

Das Replizieren der Konfiguration und somit die Verwendung der verteilten Konfigurationsumgebung ist, wie eingangs besprochen, optional. Aktivieren Sie die Replikation, wenn Sie die Remote-Instanz von der Zentralinstanz aus mitkonfigurieren möchten. In diesem Fall wählen Sie genau die Einstellungen, die Sie in obiger Abbildung sehen.

Sehr wichtig ist eine korrekte Einstellung für URL of remote site. Die URL muss immer mit /check_mk/ enden. Eine Verbindung mit HTTPS ist empfehlenswert, setzt aber voraus, dass der Apache der Remote-Instanz HTTPS unterstützt. Dies muss auf Linux-Ebene des entfernten Servers von Hand aufgesetzt werden. Bei der Checkmk Appliance kann HTTPS über die webbasierte Konfigurationsoberfläche eingerichtet werden. Falls Sie ein selbstsigniertes Zertifikat verwenden, benötigen Sie die Checkbox Ignore SSL certificate errors.

Nachdem Sie die Maske gespeichert haben, sehen Sie in der Übersicht eine zweite Instanz:

Der Monitoring-Status der (noch leeren) Remote-Instanz ist jetzt schon korrekt eingebunden. Für eine verteilte Konfigurationsumgebung benötigen Sie noch einen Login auf die entfernte Instanz von Checkmk. Dabei tauscht die Zentralinstanz mit der Remote-Instanz ein Anmeldegeheimnis aus, über das dann in Zukunft alle weitere Kommunikation abläuft. Der Zugang cmkadmin auf der Instanz wird dann nicht mehr verwendet.

Verwenden Sie als Login credentials cmkadmin und das generierte Passwort der Remote-Instanz. Bestätigen Sie an dieser Stelle noch per Confirm overwrite, dass Sie die Einstellungen überschreiben wollen.

Ein erfolgreicher Login wird so quittiert:

Sollte es zu einem Fehler bei der Anmeldung kommen, kann dies verschiedene Gründe haben, z.B.:

Die Punkte eins und zwei können Sie einfach testen, indem Sie die URL der Remote-Instanz von Hand in Ihrem Browser aufrufen.

Wenn alles geklappt hat, führen Sie nun ein Activate pending changes aus. Auf der Übersichtsseite der noch nicht aktivierten Änderungen sehen Sie auch eine Übersicht der Livestatus-Verbindungen sowie des Synchronisationszustands der verteilten Konfigurationsumgebung der einzelnen Instanzen:

Die Spalte Version zeigt die Livestatus-Version der jeweiligen Instanz an. Bei der Verwendung des CMC als Checkmk-Kern (kommerzielle Editionen) ist die Versionsnummer des Kerns (Spalte Core) identisch mit der Livestatus-Version. Falls Sie Nagios als Kern verwenden (Checkmk Raw), sehen Sie hier die Versionsnummer von Nagios.

Folgende Symbole zeigen Ihnen den Replikationsstatus der Konfigurationsumgebung:

In der Spalte Status sehen Sie den Zustand der Livestatus-Verbindung zur jeweiligen Instanz. Dieser wird rein informativ angezeigt, da die Konfiguration ja nicht per Livestatus, sondern per HTTP übertragen wird. Folgende Werte sind möglich:

Ein Klick auf Activate on selected sites synchronisiert nun alle Instanzen und aktiviert die Änderungen. Dies geschieht parallel, so dass sich die Gesamtzeit nach der Dauer bei der langsamsten Instanz richtet. In der Zeit enthalten sind die Erstellung eines Konfigurations-Snapshots für die jeweilige Instanz, das Übertragen per HTTP, das Auspacken des Snapshots auf der Instanz und das Aktivieren der Änderungen.

Wichtig: Verlassen Sie die Seite nicht, bevor die Synchronisation auf alle Instanzen abgeschlossen wurde. Ein Verlassen der Seite unterbricht die Synchronisation.

Nachdem Ihre verteilte Umgebung eingerichtet ist, können Sie beginnen, diese zu nutzen. Eigentlich müssen Sie jetzt nur noch bei jedem Host sagen, von welcher Instanz aus dieser überwacht werden soll. Per Default ist die Zentralinstanz eingestellt.

Das nötige Attribut dazu heißt „Monitored on site“. Sie können das für jeden einzelnen Host individuell einstellen. Aber natürlich bietet es sich an, das auf Ordnerebene zu konfigurieren:

Das Aufnehmen von Hosts funktioniert wie gewohnt. Bis auf die Tatsache, dass die Überwachung und auch die Service-Erkennung von der jeweiligen Remote-Instanz durchgeführt wird, gibt es nichts Spezielles zu beachten.

Beim Umziehen von Hosts von einer zu einer anderen Instanz gibt es einige Dinge zu beachten. Denn es werden weder aktuelle noch historische Statusdaten dieser Hosts übernommen. Lediglich die Konfiguration des Hosts bleibt erhalten. Es ist quasi, als würden Sie den Host auf einer Instanz entfernen und auf der anderen neu anlegen. Das bedeutet unter anderem:

Wenn die Kontinuität der Historie für Sie wichtig ist, sollten Sie schon beim Aufbau des Monitorings genau planen, welcher Host von wo aus überwacht werden soll.

Um die Verschlüsselung zu realisieren, nutzt Checkmk das Programm stunnel zusammen mit einem eigenen Zertifikat und einer eigenen Certificate Authority (CA), mit der das Zertifikat signiert wird. Sie werden bei einer neuen Instanz automatisch zusammen mit dieser individuell erzeugt und sind daher keine vordefinierten, statischen CAs oder Zertifikate. Das ist ein sehr wichtiger Sicherheitsfaktor, um zu verhindern, dass gefälschte Zertifikate von Angreifern benutzt werden können, weil sie Zugriff auf eine allgemein zugängliche CA bekommen konnten. Die erzeugten

Zertifikate haben zusätzlich folgende Eigenschaften:

Dass das Standard-Zertifikat so lange gültig ist, verhindert sehr effektiv, dass Sie nach einiger Zeit Verbindungsprobleme bekommen, die Sie nicht einordnen können. Gleichzeitig ist es dadurch natürlich auch möglich ein einmal kompromittiertes Zertifikat auch entsprechend lange zu missbrauchen. Wenn Sie also befürchten, dass ein Angreifer Zugriff auf die CA oder das damit signierte Instanz-Zertifikat bekommen hat, ersetzen Sie immer beide Zertifikate (CA und Instanz)!

Im Zuge eines Updates von Checkmk werden die beiden Optionen LIVESTATUS_TCP und LIVESTATUS_TCP_TLS niemals automatisch verändert. Eine automatische Aktivierung von TLS könnte schließlich dazu führen, dass Ihre Remote-Instanzen nicht mehr abgefragt werden können.

Sollten Sie Livestatus bisher unverschlüsselt einsetzen und sich jetzt entscheiden die Verschlüsselung nutzen zu wollen, müssen sie diese manuell aktivieren. Stoppen Sie dazu zuerst die betroffenen Instanzen und aktivieren Sie TLS anschließend mit dem folgenden Befehl:

Da die Zertifikate bei dem Update automatisch erzeugt wurden, wird die Instanz danach sofort die Verschlüsselung nutzen. Damit Sie also von der Zentralinstanz weiterhin auf die Remote-Instanz zugreifen können, muss gewährleistet sein, dass im Menü unter Setup > General > Distributed Monitoring bei der jeweiligen Instanz unter Encryption die Option Encrypt data using TLS ausgewählt ist. Prüfen Sie dies und stellen Sie die Option gegebenenfalls, wie im folgenden Screenshots zu sehen ist, um:

Der letzte Schritt ist wieder derselbe wie oben beschrieben: Auch hier müssen Sie zunächst die CA der Remote-Instanz als vertrauenswürdig markieren.

Alle Zugriffe auf einen überwachten Host geschehen konsequent von der Instanz aus, der dieser Host zugeordnet ist. Das betrifft nicht nur die eigentliche Überwachung, sondern auch die Serviceerkennung, die Diagnoseseite, die Benachrichtigungen, Alert Handler und alles andere. Das ist sehr wichtig, denn es ist überhaupt nicht gesagt, dass die Zentralinstanz auf diese Hosts Zugriff hätte.

Manche der mitgelieferten Standardansichten sind gruppiert nach der Instanz, von der ein Host überwacht wird. Das gilt z.B. auch für All hosts:

Auch bei den Details eines Hosts oder Services wird die Instanz angezeigt:

Allgemein steht diese Information als Spalte beim Erzeugen von eigenen Ansichten zur Verfügung. Und es gibt einen Filter, mit dem Sie eine Ansicht nach Hosts aus einer bestimmten Instanz filtern können:

Es gibt für die Seitenleiste das Snapin Site status, welches Sie mit einbinden können. Dieses zeigt den Status der einzelnen Instanzen. Außerdem bietet es die Möglichkeit, vorübergehend eine einzelne Instanz durch einen Klick auf den Status zu deaktivieren und wieder zu aktivieren — oder auch gleich alle Instanzen auf einmal durch Klick auf Disable all oder Enable all.

Deaktivierte Instanzen werden mit dem Status angezeigt. Sie können so auch eine Instanz, die ist und somit Timeouts erzeugt, deaktivieren und die Timeouts damit vermeiden. Diese Deaktivierung entspricht nicht dem Abschalten der Livestatus-Verbindung über die Verbindungskonfiguration im Setup. Das Abschalten hier ist lediglich für den aktuell angemeldeten Benutzer wirksam und hat eine rein optische Funktion. Ein Klick auf den Namen einer Instanz bringt Sie zur Ansicht aller Hosts dieser Instanz.

Im verteilten Monitoring ändert das Snapin Master control sein Aussehen. Die globalen Schalter gibt es immer pro Instanz:

Falls Sie mit Checkmk HA-Cluster überwachen, so müssen die einzelnen Nodes des Clusters alle der gleichen Instanz zugeordnet sein, wie der Cluster selbst. Dies liegt daran, dass bei der Ermittlung des Zustands der geclusterten Services auf Cache-Dateien zugegriffen wird, welche beim Überwachen der Nodes entstehen. Diese liegen lokal auf der jeweiligen Instanz.

Manche Check-Plugins verwenden Piggyback-Daten, um z.B. Überwachungsdaten, die „huckepack“ von einem ESXi-Host geholt wurden, den einzelnen virtuellen Maschinen zuzuordnen. Aus den gleichen Gründen wie beim Cluster-Monitoring müssen im verteilten Monitoring sowohl der Piggyhost als auch die davon abhängigen Hosts von der gleichen Instanz aus überwacht werden. Im Falle von ESXi bedeutet das, dass Sie die virtuellen Maschinen in Checkmk immer der gleichen Instanz zuordnen müssen, wie das ESXi-System, von dem Sie die Überwachungsdaten holen. Das kann dann dazu führen, dass Sie anstelle eines globalen vCenters besser die ESXi Host-Systeme direkt abfragen. Details dazu finden Sie in der Dokumentation zur Überwachung von ESXi.

Die Checkmk-Inventarisierung funktioniert auch in verteilten Umgebungen. Dabei müssen die Inventurdaten regelmäßig aus dem Verzeichnis var/check_mk/inventory von den Remote-Instanzen zur Zentralinstanz übertragen werden. Die Benutzeroberfläche greift aus Gründen der Performance immer lokal auf dieses Verzeichnis zu.

In den kommerziellen Editionen geschieht die Synchronisation automatisch auf allen Instanzen, bei denen Sie den Livestatus-Proxy zur Verbindung einsetzen.

Falls Sie mit Checkmk Raw in einem verteilten System Inventarisierung verwenden, müssen Sie das Verzeichnis mit eigenen Mitteln regelmäßig zur Zentralinstanz spiegeln (z.B. mit rsync).

Auch wenn alle Instanzen zentral administriert werden, ist eine Anmeldung auf der Oberfläche der einzelnen Instanzen durchaus möglich und oft auch sinnvoll. Deswegen sorgt Checkmk dafür, dass das Passwort eines Benutzers auf allen Instanzen immer gleich ist.

Bei einer Änderung durch den Administrator ist das automatisch gegeben, sobald sie per Activate pending changes auf alle Instanzen verteilt wird.

Etwas anderes ist eine Änderung durch den Benutzer selbst in seinen persönlichen Einstellungen. Diese darf natürlich nicht zu einem Activate pending changes führen, denn der Benutzer hat dazu im Allgemeinen keine Berechtigung. Daher verteilt Checkmk in so einem Fall das geänderte Passwort automatisch auf alle Instanzen — und zwar direkt nach dem Speichern.

Nun sind aber, wie wir alle wissen, Netzwerke nie zu 100 % verfügbar. Ist eine Instanz zu diesem Zeitpunkt also nicht erreichbar, kann das Passwort auf diese nicht übertragen werden. Bis zum nächsten erfolgreichen Activate pending changes durch einen Administrator bzw. der nächsten erfolgreichen Passwortänderung hat diese Instanz also noch das alte Passwort für den Benutzer. Der Benutzer wird über den Status der Passwortübertragung auf die einzelnen Instanzen durch ein Statussymbol informiert.

Es versteht sich von selbst, dass die in der Remote-Instanz verwendeten Host-Merkmale (host tags) auch in der Zentralinstanz bekannt sein müssen, damit diese übernommen werden können. Kontrollieren Sie dies vor dem Umziehen und legen Sie fehlende Tags in der Zentrale von Hand an. Wichtig ist dabei, dass die Tag-ID übereinstimmt — der Titel der Tags spielt keine Rolle.

Als Zweites ziehen die Hosts und Regeln in die Konfigurationsumgebung auf der Zentralinstanz um. Das funktioniert nur für Hosts und Regeln, die in Unterordnern liegen (also nicht im Ordner Main). Hosts im Hauptordner sollten Sie auf der Remote-Instanz einfach vorher im Menü Setup > Hosts > Hosts in einen Unterordner verschieben.

Das eigentliche Umziehen geht dann recht einfach durch Kopieren der entsprechenden Verzeichnisse. Jeder Ordner in Checkmk entspricht einem Verzeichnis unterhalb von ~/etc/check_mk/conf.d/wato/. Dieses können Sie mit einem Werkzeug Ihrer Wahl (z.B. scp) von der angebundenen Instanz an die gleiche Stelle in die Zentralinstanz kopieren. Falls es dort bereits ein gleichnamiges Verzeichnis gibt, benennen Sie es einfach um. Achten Sie darauf, dass Linux-Benutzer und -Gruppe von der Zentrale verwendet werden.

Nach dem Kopieren sollten die Hosts in der Konfigurationsumgebung auf der Zentralinstanz auftauchen — und ebenso Regeln, die Sie in diesen Ordnern angelegt haben. Auch die Eigenschaften der Ordner wurden mit kopiert. Diese befinden sich im Verzeichnis in der versteckten Datei .wato.

Damit die Vererbung von Attributen von Elternordnern der Zentralinstanz korrekt funktioniert, müssen Sie als letzten Schritt nach dem Umziehen einmal die Eigenschaften des Elternordners öffnen und speichern. Damit werden alle Host-Attribute neu berechnet.

Das Aufsetzen des Livestatus-Proxys ist sehr einfach. In den kommerziellen Editionen ist dieser per Default aktiviert, wie Sie beim Starten einer Instanz sehen können:

Wählen Sie nun bei den Verbindungen zu der Remote-Instanz anstelle von „Connect via TCP“ die Einstellung „Use Livestatus Proxy-Daemon“:

Die Angaben zu Host und Port sind wie gehabt. Auf den Remote-Instanzen müssen Sie nichts ändern. Bei Number of channels to keep open geben Sie die Anzahl der parallelen TCP-Verbindungen an, die der Proxy zur Zielseite aufbauen und aufrechterhalten soll.

Der TCP-Verbindungspool wird von allen Anfragen der GUI gemeinsam genutzt. Die Anzahl der Verbindungen begrenzt die maximale Anzahl von gleichzeitig in Bearbeitung befindlichen Anfragen. Dies beschränkt indirekt die Anzahl der Benutzer. In Situationen, in denen alle Kanäle belegt sind, kommt es nicht sofort zu einem Fehler. Die GUI wartet eine gewisse Zeit auf einen freien Kanal. Die meisten Anfragen benötigen nämlich nur wenige Millisekunden.

Falls die GUI länger als Timeout waiting for a free channel auf so einen Kanal warten muss, wird mit einem Fehler abgebrochen und der Benutzer sieht eine Fehlermeldung. In so einem Fall sollten Sie die Anzahl der Verbindungen erhöhen. Beachten Sie dabei jedoch, dass auf der Gegenstelle (der Remote-Instanz) genügend gleichzeitige eingehende Verbindungen erlaubt sein müssen. Per Default ist das auf 20 eingestellt. Sie finden diese Einstellung in den globalen Optionen unter Monitoring core > Maximum concurrent Livestatus connections.

Der Regular heartbeat sorgt für eine ständige aktive Überwachung der Verbindungen direkt auf Protokollebene. Dabei sendet der Proxy regelmäßig eine einfache Livestatus-Anfrage, welche von der Remote-Instanz in der eingestellten Zeit (Default: 2 Sekunden) beantwortet sein muss. So werden auch Situationen erkannt, wo der Zielserver und der TCP-Port zwar erreichbar sind, aber der Monitoring-Kern nicht mehr antwortet.

Bleibt die Antwort aus, so werden alle Verbindungen als tot deklariert und nach einer Cooldown-Zeit (Default: 4 Sekunden) wieder neu aufgebaut. Das Ganze geschieht proaktiv — also ohne, dass ein Benutzer eine GUI-Seite abrufen muss. So werden Ausfälle schnell erkannt und bei einer Wiedergenesung die Verbindungen sofort wieder aufgebaut und stehen dann im besten Fall schon wieder zur Verfügung, bevor ein Benutzer den Ausfall mitbekommt.

Das Caching sorgt dafür, dass statische Anfragen nur einmal von der Remote-Instanz beantwortet werden müssen und ab dem Zeitpunkt direkt lokal ohne Verzögerung beantwortet werden können. Ein Beispiel dafür ist die Liste der überwachten Hosts, welche von Quicksearch gebraucht wird.

Der Livestatus-Proxy hat eine eigene Log-Datei, die Sie unter var/log/liveproxyd.log finden. Bei einer korrekt eingerichteten Remote-Instanz mit fünf Kanälen (Standard), sieht das etwa so aus:

In die Datei var/log/liveproxyd.state schreibt der Livestatus-Proxy regelmäßig seinen Status:

Und so sieht der Status aus, wenn eine Instanz gerade gestoppt ist:

Der Zustand ist hier starting. Der Proxy ist also gerade beim Versuch, Verbindungen aufzubauen. Channels gibt es noch keine. Während dieses Zustands werden Anfragen an die Instanz sofort mit einem Fehler beantwortet.

Als Erstes erzeugen Sie auf der Remote-Instanz einen Abzug der Konfiguration Ihrer Hosts und Services im Nagios-Konfigurationsformat. Leiten Sie dazu die Ausgabe von livedump -TC in eine Datei um:

Der Anfang der Datei sieht in etwa wie folgt aus:

Übertragen Sie die Datei zu der Zentralinstanz (z.B. mit scp) und legen Sie sie dort in das Verzeichnis ~/etc/nagios/conf.d/. In diesem erwartet Nagios die Konfiguration für Hosts und Services. Wählen Sie einen Dateinamen, der auf .cfg endet, z.B. ~/etc/nagios/conf.d/config-remote1.cfg. Wenn ein SSH-Zugang von der Remote-Instanz auf die Zentralinstanz möglich ist, geht das z.B. so:

Loggen Sie sich jetzt auf der Zentralinstanz ein und aktivieren Sie die Änderungen:

Nun sollten alle Hosts und Services der Remote-Instanz in der Zentralinstanz auftauchen — und zwar im Zustand PEND, in dem sie bis auf Weiteres auch bleiben:

Hinweise:

Nachdem die Hosts in der Zentralinstanz sichtbar sind, geht es jetzt an die (regelmäßige) Übertragung des Monitoring-Status der Remote-Instanz. Wieder erzeugen Sie mit livedump eine Datei, allerdings diesmal ohne weitere Optionen:

Diese Datei enthält den Zustand aller Hosts und Services in einem Format, welches Nagios direkt aus dem Check-Ergebnis einlesen kann. Der Anfang sieht etwa so aus:

Übertragen Sie diese Datei auf die Zentralinstanz in das Verzeichnis ~/tmp/nagios/checkresults. Wichtig: Der Name der Datei muss mit c beginnen und sieben Zeichen lang sein (Nagios-Vorgabe). Mit scp würde das etwa so aussehen:

Anschließend erzeugen Sie auf der Zentralinstanz eine leere Datei mit dem gleichen Namen und der Endung .ok. Dadurch weiß Nagios, dass die Statusdatei komplett übertragen ist und eingelesen werden kann:

Der Zustand der Hosts/Services der Remote-Instanz wird jetzt auf der Zentralinstanz sofort aktualisiert:

Das Übertragen des Status muss ab jetzt natürlich regelmäßig vorgenommen werden. Livedump unterstützt Sie dabei leider nicht und Sie müssen das selbst (z.B. in einem Skript) umsetzen. In ~/share/check_mk/doc/treasures/livedump finden Sie das Skript livedump-ssh-recv, welches Sie einsetzen können, um Livedump-Updates (auch solche von der Konfiguration) per SSH auf der Zentralinstanz zu empfangen. Details finden Sie in den Kommentaren im Skript selbst.

Sie können den Dump von Konfiguration und Status auch durch die Angabe von Livestatus-Filtern einschränken, z.B. die Hosts auf die Mitglieder der Host-Gruppe mygroup:

Weitere Hinweise zu Livedump finden Sie in der Datei README im Verzeichnis ~/share/doc/check_mk/treasures/livedump.

Die kommerziellen Editionen bieten einen eingebauten Mechanismus für zentralisierte Benachrichtigungen, welcher pro Remote-Instanz einzeln aktiviert werden kann. Solche Remote-Instanzen leiten dann alle Benachrichtigungen zur weiteren Verarbeitung an die Zentralinstanz weiter. Dabei ist die zentrale Benachrichtigung unabhängig davon, ob Sie Ihr verteiltes Monitoring auf dem klassischen Weg oder mit CMCDump oder einer Mischung davon eingerichtet haben. Genau genommen muss der zentrale Benachrichtigungs-Server nicht mal die Zentralinstanz sein. Diese Aufgabe kann jede Checkmk-Instanz übernehmen.

Ist eine Remote-Instanz auf Weiterleitung eingestellt, so werden alle Benachrichtigungen direkt wie sie vom Kern kommen — quasi in Rohform (wir sprechen hier auch von den Rohbenachrichtigungen) — an die Zentralinstanz weitergereicht. Erst dort werden die Benachrichtigungsregeln ausgewertet, welche entscheiden, wer und wie überhaupt benachrichtigt werden soll. Die dazu notwendigen Benachrichtigungsskripte werden auf der Zentralinstanz aufgerufen.

Die Benachrichtigung-Spooler von entfernter und zentraler (Benachrichtigungs-)Instanz tauschen sich untereinander per TCP aus. Benachrichtigungen werden von der Remote-Instanz zur Zentralinstanz gesendet. Die Zentrale quittiert empfangene Benachrichtigungen an die Remote-Instanz, was verhindert, dass Benachrichtigungen verloren gehen, selbst wenn die TCP-Verbindung abbrechen sollte.

Für den Aufbau der TCP-Verbindung haben Sie zwei Möglichkeiten:

Somit steht dem Weiterleiten von Benachrichtigungen auch dann nichts im Wege, wenn aus Netzwerkgründen der Verbindungsaufbau nur in eine bestimmte Richtung möglich ist. Die TCP-Verbindungen werden vom Spooler mit einem Heartbeat-Signal überwacht und bei Bedarf sofort neu aufgebaut — nicht erst im Falle einer Benachrichtigung.

Da Remote-Instanz und Zentralinstanz für den Spooler unterschiedliche globale Einstellungen brauchen, müssen Sie diese für alle Remote-Instanzen instanzspezifische Einstellungen machen. Die Konfiguration der Zentrale geschieht über die normalen globalen Einstellungen. Beachten Sie, dass diese automatisch an alle Remote-Instanzen vererbt wird, für die Sie keine spezifischen Einstellungen definiert haben.

Betrachten Sie zuerst den Fall, dass die Zentralinstanz die TCP-Verbindungen zu den Remote-Instanzen aufbauen soll.

Schritt 1: Editieren Sie bei der Remote-Instanz die instanzspezifische globale Einstellung Notifications > Notification Spooler Configuration und aktivieren Sie Accept incoming TCP connections. Als TCP-Port wird 6555 vorgeschlagen. Sofern nichts dagegen spricht, übernehmen Sie diese Einstellung.

Schritt 2: Setzen Sie nun ebenfalls nur auf der Remote-Instanz die Einstellung Notification Spooling auf den Wert Forward to remote site by notification spooler.

Schritt 3: Auf der Zentralinstanz — also in den normalen globalen Einstellungen — richten Sie nun zu der Remote-Instanz (und später dann auch eventuell zu weiteren Remote-Instanzen) die Verbindungen ein:

Schritt 4: Setzen Sie die globale Einstellung Notification Spooling auf Asynchronous local delivery by notification spooler, damit auch die Meldungen der Zentrale über den gleichen zentralen Spooler abgewickelt werden.

Schritt 5: Aktivieren Sie die Änderungen.

Soll die TCP-Verbindung von der Remote-Instanz aus aufgebaut werden, so ist das Vorgehen identisch, bis auf die Tatsache, dass Sie die oben gezeigten Einstellungen einfach zwischen Zentralinstanz und Remote-Instanz vertauschen.

Auch eine Mischung ist möglich. In diesem Fall muss die Zentrale so aufgesetzt werden, dass sie sowohl auf eingehende Verbindungen lauscht, als auch Verbindungen zu entfernten Instanzen aufbaut. Für jede Beziehung zwischen Zentralinstanz und Remote-Instanz darf aber nur einer von beiden die Verbindung aufbauen!

Der Benachrichtigungs-Spooler loggt in die Datei var/log/mknotifyd.log. In den Spooler-Einstellungen können Sie das Loglevel erhöhen, so dass Sie mehr Meldungen kommen. Bei einem Standard-Loglevel sollten Sie auf der Zentralinstanz etwa Folgendes sehen:

Die Datei var/log/mknotifyd.state enthält stets einen aktuellen Zustand des Spoolers und aller seiner Verbindungen:

Die gleiche Datei gibt es auch auf der Remote-Instanz. Dort sieht die Verbindung etwa so aus:

Zum Testen wählen Sie z.B. einen beliebigen Service, der auf der Remote-Instanz überwacht wird, und setzen diesen per Kommando Fake check results auf CRIT.

Auf der Zentrale sollen Sie nun in der entsprechenden Log-Datei (notify.log) die eingehenden Benachrichtigung sehen:

Das gleiche Ereignis sieht bei der Remote-Instanz so aus:

In den globalen Einstellungen können Sie sowohl die normale Log-Datei für Benachrichtigungen (notify.log) als auch die Log-Datei des Benachrichtigungs-Spoolers auf ein höheres Loglevel umstellen.

Nachdem Sie alles wie beschrieben aufgesetzt haben, werden Sie feststellen, dass sowohl auf der Zentralinstanz, als auch auf den Remote-Instanzen jeweils ein neuer Service gefunden wird, den Sie unbedingt in die Überwachung aufnehmen sollten. Dieser überwacht den Benachrichtigungs-Spooler und dessen TCP-Verbindungen. Dabei wird jede Verbindung zweimal überwacht: einmal durch die Zentralinstanz und einmal durch die Remote-Instanz: