Verteiltes Monitoring


1. Einleitung

Unter dem Begriff „verteiltes Monitoring“ (Distributed Monitoring) versteht wahrscheinlich nicht jeder das Gleiche. Und eigentlich ist Monitoring ja immer über viele Rechner verteilt – solange das Monitoringsystem nicht nur sich selbst überwacht, was schließlich wenig nützlich wäre.

In diesem Handbuch sprechen wir immer dann von einem verteilten Monitoring, wenn das gesamte Monitoringsystem aus mehr als einer Check_MK-Instanz besteht. Dabei gibt es verschiedene Gründe für das Aufteilen in mehrere Instanzen:

  • Performance: Die Rechenlast des Monitorings soll oder muss auf mehrere Maschinen verteilt werden.
  • Organisation: Die Instanzen sollen von unterschiedlichen Personenkreisen eigenverantwortlich administriert werden.
  • Verfügbarkeit: Das Monitoring an einem Standort soll unabhängig von anderen Standorten funktionieren.
  • Sicherheit: Datenströme zwischen zwei Sicherheitsbereichen sollen getrennt und genau kontrolliert werden (DMZ, etc.).
  • Netzwerk: Standorte, die nur schmalbandig oder unzuverlässig angebunden sind, können nicht zuverlässig von der Ferne aus überwacht werden.

Check_MK unterstützt mehrere Verfahren für den Aufbau eines verteilten Monitorings. Manche davon beherrscht Check_MK, weil es mit Nagios weitgehend kompatibel ist bzw. darauf aufbaut (falls Nagios als Kern eingestellt wurde). Dazu gehören z. B. das alte Verfahren mit NSCA und das etwas modernere mit mod_gearman. Diese bieten gegenüber den Check_MK-eigenen Verfahren keine Vorteile und sind noch dazu umständlicher einzurichten. Wir empfehlen sie daher nicht.

Das von Check_MK bevorzugte Verfahren basiert auf Livestatus und einer Konfigurationsverteilung durch WATO. Für Situationen mit stark abgeschotteten Netzen oder sogar einer strikt unidirektionalen Daten­übertragung von der Peripherie in die Zentrale gibt eine Methode mit Livedump bzw. CMCDump. Beide Methoden können kombiniert werden.

2. Verteiltes Monitoring mit Livestatus

2.1. Grundprinzip

Zentraler Status

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

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

Das Besondere an dieser Methode ist, dass der Monitoringstatus der Slaves nicht ständig an den Master übertragen wird. Die GUI ruft von den entfernten Instanzen immer nur live diejenigen Daten ab, die ein Benutzer in der Zentrale 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:

  • Skalierung: Das Monitoring selbst erzeugt keinerlei Netzwerkverkehr zwischen Master und Slaves. Dadurch können hundert und mehr Standorte angebunden werden.
  • Zuverlässigkeit: Fällt die Netzwerkverbindung zu einem Slave aus, so geht das Monitoring dort trotzdem völlig normal weiter. Es gibt keine Lücke in der Datenaufzeichnung und auch keinen Datenstau. Eine lokale Alarmierung funktioniert weiterhin.
  • Einfachheit: Instanzen können sehr einfach eingebunden und wieder entfernt werden.
  • Flexibilität: Die Slaveinstanzen sind weiterhin eigenständig und können an dem jeweiligen Standort für das Operating genutzt werden. Das ist insbesondere dann interessant, wenn der „Standort“ auf keinen Fall Zugriff auf den Rest des Monitorings haben darf.

Zentrale Konfiguration

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 der Master 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. Check_MK unterstützt dies und spricht dabei von „verteiltem WATO“ (distributed WATO). Dabei werden alle Hosts und Services, Benutzer und Rechte, Zeitperioden, Alarme u.s.w. auf dem Master per WATO zentral gepflegt und dann automatisch nach Ihren Vorgaben auf die Slaves 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.

2.2. Verteiltes Monitoring Aufsetzen

Das Aufsetzen eines verteilten Monitorings via Livestatus/verteiltem WATO geschieht in folgenden Schritten:

  1. Masterinstanz zunächst ganz normal wie eine Einzelinstanz aufsetzen
  2. Slaveinstanzen aufsetzen und Livestatus per Netzwerk freigegen
  3. Auf dem Master Slaveinstanzen per WATO-Modul Distributed monitoring einbinden
  4. Bei Hosts und Foldern festlegen, von welcher Instanz aus diese gemonitort werden sollen
  5. Serviceerkennung für umgezogene Hosts neu durchführen und Änderungen aktivieren

Masterinstanz aufsetzen

An den Master 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.

Slaveinstanzen aufsetzen und Livestatus per Netzwerk freigegen

Die Slaveinstanzen 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 Slaveinstanz vorgesehen ist.

Hinweise:

  • Verwenden Sie für die Slaveinstanzen IDs, die in Ihrem verteilten Monitoring eindeutig sind.
  • Die Check_MK-Version der Slaves darf sich von der Version des Masters maximal im Patchlevel unterscheiden (also die Ziffer nach dem p bei stabilen Versionen). Andere Versionen können kompatibel sein, müssen aber nicht. Hinweise zu dem Schema der Check_MK-Versionsnummern finden Sie in einem eigenen Artikel.
  • Da Check_MK mehrere Instanzen auf einem Server unterstützt, kann die Slaveinstanz auch auf dem gleichen Server laufen.

Hier ist ein Beispiel für das Anlegen einer Slaveinstanz mit dem Namen slave1:

root@linux# omd create slave1
Adding /opt/omd/sites/slave1/tmp to /etc/fstab.
Creating temporary filesystem /omd/sites/slave1/tmp...OK
Restarting Apache...OK
Created new site slave1 with version 1.2.8p12.

  The site can be started with omd start slave1.
  The default web UI is available at http://Klappfisch/slave1/
  The admin user for the web applications is omdadmin with password omd.
  Please do a su - slave1 for administration of this site.

Der wichtigste Schritt ist jetzt, dass Sie Livestatus via TCP auf dem Netzwerk freigeben. Bitte 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 Site per omd config:

root@linux# ~# su - slave1
OMD[mysite]:~$ omd config

Wählen Sie jetzt Distributed Montioring:

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:

OMD[slave1]:~$ omd start
Starting mkeventd...OK
Starting Livestatus Proxy-Daemon...OK
Starting rrdcached...OK
Starting Check_MK Micro Core...OK
Starting dedicated Apache for site slave1...OK
Starting xinetd...OK
Initializing Crontab...OK

Lassen Sie das Passwort für omdadmin vorübergebend auf den Defaultwert eingestellt. Sobald der Slave dem Master untergeordnet wurde, werden sowieso alle Benutzer durch die vom Master ausgetauscht.

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

root@linux# netstat -lnp | grep 6557
tcp        0      0 0.0.0.0:6557            0.0.0.0:*     LISTEN      10719/xinetd

Slaveinstanzen in den Master einbinden

Die Konfiguration des verteilten Monitorings wird ausschließlich auf dem Master vorgenommen. Das notwendige WATO-Modul dazu heißt Distributed monitoring und dient dem Verwalten der Ver­bindungen zu den einzelnen Instanzen. Dabei zählt der Master selbst auch als Instanz und ist bereits in der Liste eingetragen:

Legen Sie jetzt mit die Verbindung zum ersten Slave an:

Bei den Basic settings ist es wichtig, dass Sie als Site-ID exakt den Namen der Slaveinstanz 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 Livestatus settings geht es darum, wie die Zentralinstanz den Status des Slaves per Livestatus abfragt. Das Beispiel im Screenshot zeigt eine Verbindung mit der Methode Connect via TCP. 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.

Der URL prefix ist notwendig für das Einbinden von anderen Anwendungen (z. B. PNP4Nagios). Darauf gehen wir weiter unten gesondert ein. Tragen Sie hier die HTTP-URL zu der Weboberfläche des Slaves ein und zwar nur den Teil bis vor dem check_mk/. Wenn Sie grundsätzlich per HTTPS auf Check_MK zugreifen, dann ersetzen Sie das http hier durch https. Weitere Details erfahren Sie wie immer in der Onlinehilfe.

Die Verwendung von Distrbuted WATO ist, wie eingangs besprochen, optional. Aktivieren Sie diese, wenn Sie den Slave vom Master aus mitkonfigurieren möchten. In diesem Fall wählen Sie genau die Einstel­lungen, die Sie in obiger Abbildung sehen.

Sehr wichtig ist eine korrekte Einstellung für Multisite-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 Slaveinstanz HTTPS unterstützt. Dies muss auf Linux-Ebene auf dem Slave von Hand aufgesetzt werden. Bei der Check_MK 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 Monitoringstatus des (noch leeren) Slaves ist jetzt schon korrekt eingebunden. Für das verteilte WATO benötigen Sie noch einen Login auf das WATO des Slaves. Dabei tauscht der Master per HTTP mit dem Slave ein zufällig erzeugtes Passwort aus, über das dann in Zukunft alle weitere Kommunikation abläuft. Der Zugang omdadmin auf dem Slave wird dann nicht mehr verwendet.

Verwenden Sie zum Login die Zugangsdaten omdadmin und omd (bzw. die von einem Administratorkonto auf dem Slave):

Ein erfolgreicher Login wird so quittiert:

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

  1. Die Slaveinstanz ist gerade gestoppt.
  2. Die Multisite-URL of remote site ist nicht korrekt eingestellt.
  3. Der Slave ist unter dem in der URL eingestellten Hostnamen vom Master aus nicht erreichbar.
  4. Master und Slave haben (zu) unterschiedliche Check_MK-Versionen.
  5. Benutzer und/oder Passwort sind falsch.

Punkte eins und zwei können Sie einfach testen, indem Sie die URL des Slaves von Hand in Ihrem Browser aufrufen.

Wenn alles geklappt hat, führen Sie nun ein Activate Changes aus. Dieser bringt Sie wie immer zur Übersicht der noch nicht aktivierten Änderungen. Gleichzeitig zeigt er Ihnen einen Status der Livestatus­verbindungen sowie des WATO-Synchronisationszustands der einzelnen Instanzen:

Die Spalte Version zeigt die Livestatusversion der jeweiligen Site an. Bei der Verwendung des CMC als Check_MK-Kern ( Check_MK Enterprise Edition) ist die Versionsnummer des Kerns (Spalte Core) identisch mit der Livestatusversion. Falls Sie Nagios als Kern verwenden ( Check_MK Raw Edition), sehen Sie hier die Versionsnummer von Nagios.

Folgende Symbole zeigen Ihnen den Replikationsstatus von WATO:

Diese Instanz hat ausstehende Änderungen. Die Konfiguration stimmt mit dem Master überein, aber es sind nicht alle Änderungen aktiviert. Mit dem Knopf Restart können Sie diese gezielt für diese Instanz aktivieren.
Die WATO-Konfiguration dieser Instanz ist nicht synchron und muss übertragen werden. Danach ist dann natürlich auch ein Neustart notwendig, um die Konfiguration zu aktiveren. Beides zusammen erreichen Sie mit dem Knopf Sync & Restart.

In der Spalte Status sehen Sie den Zustand der Livestatusverbindung 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:

Die Instanz ist per Livestatus erreichbar.
Die Instanz ist gerade nicht erreichbar. Livestatusanfragen laufen in einen Timeout. Dies verögert den Seitenaufbau. Statusdaten dieser Instanz sind in der GUI nicht sichtbar.
Die Instanz ist gerade nicht erreichbar, aber das ist aufgrund der Einrichtung eines Statushosts oder durch den Livestatusproxy bekannt (siehe unten). Die Nichterreichbarkeit führt nicht zu Timeouts. Statusdaten dieser Instanz sind in der GUI nicht sichtbar.
Die Livestatusverbindung zu dieser Instanz ist vorübergehend durch den Administrator (des Masters) deaktiviert worden. Die Einstellung entspricht der Checkbox Temporarily disable this connection in der Einstellung dieser Verbindung.

Ein Klick auf 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 Konfigurationssnapshots für die jeweilige Instanz, das Übertragen per HTTP, das Auspacken des Snapshots auf dem Slave 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.

. Bei Hosts und Foldern festlegen, von welcher Instanz aus diese gemonitort werden sollen

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 der Master 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:

. Serviceerkennung für umgezogene Hosts neu durchführen und Änderungen aktivieren

Das Aufnehmen von Hosts funktioniert wie gewohnt. Bis auf die Tatsache, dass die Überwachung und auch die Serviceerkennung von der jeweiligen Slaveinstanz 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 mit umgezogen. Lediglich die Konfiguration des Hosts im WATO 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:

  • Automatisch erkannte Services werden nicht umgezogen. Führen Sie daher nach dem Umziehen eine Serviceerkennung durch.
  • Host und Services beginnen wieder bei PEND. Eventuell aktuell vorhandene Probleme werden dadurch neu alarmiert.
  • Historische Metriken gehen verloren. Dies können Sie vermeiden, indem Sie betroffene RRD-Dateien von Hand kopieren. Die Lage der Dateien finden Sie unter Dateien und Verzeichnisse.
  • Daten zur Verfügbarkeit und zu historischen Ereignissen gehen verloren. Diese sind leider nicht so einfach umzuziehen, da diese Daten sich in einzelnen Zeilen im Monitoringlog befinden.

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.

2.3. Besonderheiten im verteiltem Setup

Ein verteiltes Monitoring via Livestatus verhält sich zwar fast wie ein einzelnes System, hat aber dennoch ein paar Besonderheiten:

Zugriff auf die überwachten Hosts

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 Alarmierung, Alerthandler und alles andere. Das ist sehr wichtig, denn es ist überhaupt nicht gesagt, dass der Master auf diese Hosts Zugriff hätte.

Angabe der Instanz in den Ansichten

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 Site filtern können:

Sitestatus-Element

Es gibt für die Seitenleiste das Element Site status, welches Sie mit einbinden können. Dieses zeigt den Status der einzelnen Instanzen und bietet darüber hinaus die Möglichkeit, vorübergehend einzelne Sites durch einen Klick auf den Status aus- und wieder einzublenden. Diese werden dann mit dem Status angezeigt. Sie können so auch eine Instanz, die ist und somit Timeouts erzeugt, abschalten und die Timeouts damit vermeiden:

Dies entspricht nicht dem Abschalten der Livestatusverbindung über die Verbindungskonfiguration in WATO. 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.

Mastercontrol-Element

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

Check_MK Clusterhosts

Falls Sie mit Check_MK 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 Ermittlungs des Zustands der geclusterten Services auf Cachedateien zugegriffen wird, welche beim Überwachen der Nodes entstehen. Diese liegen lokal auf der jeweiligen Instanz.

Huckepackdaten (z. B. ESXi)

Manche Checkplugins verwenden „Huckepackdaten“ (Piggyback), um z. B. Überwachungsdaten, die von einem ESXi-Host geholt wurden, den einzelnen virtuellen Maschinen zuzuordnen. Aus den gleichen Gründen wie beim Clustermonitoring 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 Check_MK immer der gleichen Site 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-Hostsysteme direkt abfragen. Details dazu finden Sie in der Dokumentation zur ESXi-Überwachung.

Hardware-/Softwareinventur

Die Check_MK-Inventurisierung funktioniert auch in verteilten Umgebungen. Dabei müssen die Inventurdaten regelmäßig aus dem Verzeichnis var/check_mk/inventory von den Slaves zum Master übertragen werden. Die Benutzeroberfläche greift aus Performancegründen immer lokal auf dieses Verzeichnis zu.

In der  Check_MK Enterprise Edition geschieht die Synchronisation automatisch auf allen Sites, bei denen Sie den Livestatusproxy zur Verbindung einsetzen.

Falls Sie mit der  Check_MK Raw Edition in einem verteilten System Inventurisierung verwenden, müssen Sie das Verzeichnis mit eigenen Mitteln regelmäßig zum Master spiegeln (z. B. mit rsync).

Passwortänderung

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 WATO dafür, dass das Passwort eines Benutzers auf allen Sites immer gleich ist.

Bei einer Änderung durch den Administrator ist das automatisch gegeben, sobald sie per Activate 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 changes führen, denn der Benutzer hat dazu im Allgemeinen keine Berechtigung. Daher verteilt WATO 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 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.

2.4. Anbinden von bestehenden Instanzen

Wie bereits oben erwähnt, können Sie auch bestehende Instanzen nachträglich an ein verteiltes Monitoring anbinden. Sofern die oben beschriebenen Voraussetzungen erfüllt sind (passende Check_MK-Version), geschieht dies genau wie beim Einrichten eines neuen Slaves. Geben Sie Livestatus per TCP frei, tragen Sie die Instanz im Modul Distributed monitoring ein – fertig!

Der zweite Schritt, also die Umstellung auf eine zentrale Konfiguration, ist etwas kniffliger. Bevor Sie wie oben beschrieben die Instanz in das verteilte WATO einbinden, sollten Sie wissen, dass dabei die komplette lokale Konfiguration der Instanz überschrieben wird!

Wenn Sie also bestehende Hosts und eventuell auch Regeln übernehmen möchten, benötigen Sie drei Schritte:

  1. Schema der Hostmerkmale anpassen
  2. WATO-Verzeichnisse kopieren
  3. Eigenschaften im Elternordner einmal editieren

. Hostmerkmale

Es versteht sich von selbst, dass die im Slave verwendeten Hostmerkmale (Tags) auch im Master bekannt sein müssen, damit diese übernommen werden können. Kontrollieren Sie dies vor dem Umziehen und legen Sie fehlende Tags im Master von Hand an. Wichtig ist dabei, dass die Tag-ID übereinstimmt – der Titel der Tags spielt keine Rolle.

. WATO-Verzeichnisse

Als Zweites ziehen die Hosts und Regeln in das zentrale WATO auf dem Master um. Das funktioniert nur für Hosts und Regeln, die in Unterordnern liegen (also nicht im „Main directory“). Hosts im Hauptverzeichnis sollten Sie auf dem Slave einfach vorher per WATO in einen Unterordner verschieben.

Das eigentliche Umziehen geht dann recht einfach durch Kopieren der entsprechenden Verzeichnisse. Jeder Hostordner in WATO 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 Site an die gleiche Stelle in den Master kopieren. Falls es dort bereits ein gleichnamiges Verzeichnis gibt, benennen Sie es einfach um. Bitte achten Sie darauf, dass Linux-Benutzer und -Gruppe von der Mastersite verwendet werden.

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

. Einmal editieren und speichern

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

2.5. Instanzspezifische globale Einstellungen

Zentrale Konfiguration per WATO bedeutet zunächst einmal, dass alle Instanzen eine gemeinsame und (bis auf die Hosts) gleiche Konfiguration haben. Was ist aber, wenn Sie für einzelne Instanzen abweichende globale Einstellungen benötigen? Ein Beispiel könnte z. B. die Einstellung Maximum concurrent Check_MK checks des CMC sein. Vielleicht benötigen Sie für eine besonders kleine oder große Instanz eine angepasste Einstellung.

Für solche Fälle gibt es instanzspezifische globale Einstellungen. Zu diesen gelangen Sie über das Symbol im WATO-Modul Distributed monitoring:

Damit gelangen Sie zur Auswahl aller globalen Einstellungen – allerdings gilt alles, was Sie jetzt einstellen, nur für die ausgewählte Instanz. Die optische Hinterlegung für eine Abweichung vom Standard bezieht sich jetzt nur auf diese Instanz:

Hinweis: Sitespezifische Einstellungen für den Master sind nur auf Umwegen möglich. Denn der Master gibt ja gerade die Konfiguration vor. In einer Situation, in der der Master als einziger eine abweichende Einstellung hat, müssen Sie in jeder einzelnen Site eine sitespezifische Einstellung machen, die diese wieder auf den „Default“ zurücksetzt.

2.6. Verteilte Event Console

Die Event Console verarbeitet Syslog-Meldungen, SNMP Traps und andere Arten von Ereignissen asyn­chroner Natur.

Bis zur Version 1.2.8 ist der empfohlene Weg in einer verteilten Umgebung, dass Sie nur eine einzige Instanz der Event Console betreiben – und zwar innerhalb der Masterinstanz. Dorthin leiten Sie direkt alle Events der Hosts.

Dieses Setup hat den Nachteil, dass die Ereignisse von Hosts an eine andere Instanz gesendet werden müssen als von der sie aktiv überwacht werden. Eine Folge davon ist, dass bei der Erzeugen von Alarmen aus der Event Console die Informationen zu den Hosts unvollständig sind, da das lokale Check_MK diese nicht kennt. Das betrifft zum einen die Ermittlung von Kontaktgruppen von Hosts und zum anderen Events, in denen der Absenderhost nur durch seine IP-Adresse identifiziert wird und ein echter Hostname fehlt. In so einem Fall können Alarmierungsregeln, die Bedingungen über den Hostnamen enthalten, nicht funktionieren.

Ab Version 1.4.0i1 bietet Check_MK die Möglichkeit, die Event Console ebenfalls verteilt laufen zu lassen. Auf jeder Instanz läuft dann eine eigene Eventverarbeitung, welche die Ereignisse von allen Hosts erfasst, die von dieser Instanz aus überwacht werden. Die Events werden dann aber nicht alle zum Zentralsystem geschickt, sondern verbleiben auf den Instanzen und werden nur zentral abgefragt. Dies geschieht analog zu den aktiven Zuständen über Livestatus und funtioniert sowohl mit der  Check_MK Raw Edition als auch mit der  Check_MK Enterprise Edition.

Eine Umstellung auf eine verteilte Event Console nach dem neuen Schema erfordert folgende Schritte:

  • In den Verbindungseinstellungen WATO-Replication zur EC einschalten (Replicate Event Console configuration to this site).
  • Syslogziele und SNMP-Trap-Destinations der betroffenen Hosts auf den Slave umstellen. Das ist der aufwendigste Teil.
  • Falls Sie den Regelsatz Check event state in Event Console verwenden, diesen wieder auf Connect to the local Event Console umstellen.
  • Falls Sie den Regelsatz Logwatch Event Console Forwarding verwenden, diesen ebenfalls auf lokale Event Console umstellen.
  • In den Settings der Event Console den Access to event status via TCP wieder auf no access via TCP zurückschalten.

2.7. PNP4Nagios

In der  Check_MK Raw Edition kommt zur Visualisierung von Messwerten das Open-Source-Projekt PNP4Nagios zum Einsatz. Dieses verfügt über eine eigene Weboberfläche, die in Check_MK integriert ist. Dabei werden an manchen Stellen einzelne Graphen eingebettet, an anderen eine komplette Seite inklusive eigener Navigation:

Im verteilten Monitoring liegen die Metrikdatenbanken (RRDs) immer lokal auf den Slavesites. Das ist sehr wichtig, da so eine ständige Übertragung aller Messdaten zum Master vermieden wird – und der damit verbundene Netzwerkverkehr. Außerdem bleiben so auch die ganzen anderen Vorteile des verteilten Monitorings per Livestatus erhalten, die eingangs beschrieben wurden.

Leider bietet PNP4Nagios keine zu Livestatus kompatible Schnittstelle für den Zugriff auf die Graphen. Daher holt Check_MK einfach die einzelnen Graphen bzw. die ganze Webseite von PNP4Nagios über dessen Standard-URLs per HTTP. Dabei gibt es zwei Methoden:

  1. Die PNP4Nagios-Daten werden direkt vom Browser des Benutzers abgerufen.
  2. Die PNP4Nagios-Daten werden vom Master abgerufen und an den Benutzer weitergeleitet.

. Abruf durch den Browser des Benutzers

Die erste Methode ist sehr einfach einzurichten. Konfigurieren Sie bei den entsprechenden Sites in den Eigenschaften der Verbindung das URL-Präfix und setzen Sie es auf die URL, mit der Sie diese Instanz erreichen, allerdings ohne das /check_mk/:

Check_MK wird in der GUI die Graphen nun so einbetten, dass der Browser die PNG-Bilder der Graphen bzw. die Iframes der Webseite von PNP4Nagios über diese URL abholt. Geben Sie die URL also so an, wie Sie vom Browser des Anwenders aus funktioniert. Ein Zugriff auf den Slave vom Master aus ist nicht notwendig.

Die gerade gezeigte Methode mit der URL ist schnell und einfach eingerichtet, hat aber einige kleine Nachteile:

  • Da der Browser die PNP4Nagios-Daten von einem anderen Host als die Check_MK-GUI holt, wird das Check_MK-Sitzungscookie nicht gesendet. Für jede Slaveinstanz muss sich der Benutzer daher einmal neu anmelden. Beim ersten Zugriff auf einen Graphen erscheint dann eine Anmeldemaske.
  • Der Slaveserver ist eventuell vom Browser des Benutzers garnicht erreichbar – sondern nur vom Master aus. In diesem Fall funktioniert die Methode gar nicht.
  • Der URL-Präfix muss entweder auf http:// oder auf https:// eingestellt sein. Eine Wahl des Benutzers funktioniert dann nicht mehr.

. Abruf durch den Master

Die beste Lösung für diese Probleme ist, die PNP4Nagios-Daten nicht mehr vom Browser des Nutzers selbst, sondern vom Master holen zu lassen. Dazu legen Sie auf dem Apache-Server des Masters eine Proxyregel an. Diese leitet Anfragen an PNP4Nagios per HTTP oder HTTPS auf den richtigen Slaveserver weiter. Wichtig: Dies muss auf dem Apache des Betriebssystems gemacht werden, nicht auf dem in der Instanz laufenden. Deswegen benötigen Sie root-Berechtigung.

Voraussetzung für dieses Setup ist, dass alle Instanz-IDs von Check_MK in Ihrem Netzwerk eindeutig sind, denn Apache muss anhand der Slave-ID entscheiden können, an welchen Server weitergeleitet wird.

Gehen wir von folgendem Beispiel aus:

ID IP-Addresse Livestatus URL von Check_MK
master 10.15.18.223 lokal http://10.15.18.223/master/check_mk/
slave1 10.1.1.133 Port 6557 http://10.1.1.133/slave1/check_mk/

Setzen Sie nun in der Verbinungseinstellung als URL-Präfix lediglich /slave1/ ein:

Dadurch gehen Anfragen an PNP4Nagios zunächst an den Master an der URL /slave1. Sollte die Instanz slave1 zufällig auf dem gleichen Server laufen wie der Master, sind Sie jetzt schon fertig und brauchen auch keine Proxyregel, da die Daten dann direkt ausgeliefert werden können.

Im allgemeinen Fall, dass der Slave auf einem anderen Host läuft, benötigen Sie nun root-Berechtigung und legen eine Konfigurationsdatei für den systemweiten Apache-Server an. Der Pfad dieser Datei hängt von Ihrer Linux-Distribution ab:

Distribution Pfad
RedHat, CentOS /etc/httpd/conf.d/check_mk_proxy.conf
SLES, Debian, Ubuntu /etc/apache2/conf.d/check_mk_proxy.conf

Die Datei besteht pro angebundener Slaveinstanz aus fünf Zeilen. Ersetzen Sie in folgendem Beispiel den Namen der Instanz (hier slave1) und die URL zur Instanz (hier http://10.1.1.133/slave1/). Bitte achten Sie auch darauf, dass es Apache nicht egal ist, ob eine URL mit Schrägstrich endet oder nicht:

/etc/apache2/conf.d/multisite_proxy.conf
<Location /slave1>
    Options +FollowSymLinks
    RewriteEngine On
    RewriteRule ^/.+/slave1/(.*) http://10.1.1.133/slave1/$1 [P]
</Location>

Diese Regel sagt Apache, dass alle URLs, die mit /slave1 beginnen via Reverse-Proxy von der URL http://10.1.1.133/slave1 geholt werden sollen.

Wichtig: Vergessen Sie nicht, die Konfiguration zu aktivieren. Das geht auf SLES, Debian und Ubuntu mit:

root@linux# /etc/init.d/apache2 reload

Bei RedHat und CentOS benötigen Sie:

root@linux# /etc/init.d/httpd reload

Wenn Sie alles richtig gemacht haben, muss jetzt ein Zugriff auf die Graphen von PNP4Nagios funktionieren.

2.8. Logwatch

Check_MK enthält das Plugin mk_logwatch, mit dem Sie unter Linux und Windows beliebige Textlogdateien und speziell unter Windows das Eventlog überwachen können. Dieses Plugin stellt eine spezielle Webseite in der GUI zur Verfügung, mit der Sie die gefundenen relevanten Meldungen ansehen und quittieren können:

Bis zur Version 1.2.8 von Check_MK benötigt diese Seite lokalen Zugriff auf die gespeicherten Logmel­dungen. Diese legt das Plugin auf dem Slave ab, von dem aus der entsprechende Server überwacht wird. Im verteilten Monitoring hat der Master aber keinen direkten Zugriff auf diese Dateien. Die Lösung ist die gleiche wie bei PNP4Nagios: Die Logwatchwebseite des Slaveservers wird eingebettet und separat per HTTP vom Slave geholt.

Die dafür benötigte Konfiguration ist exakt die gleiche wie beim Einrichten von Check_MK für PNP4Nagios. Wenn Sie dies bereits eingerichtet haben, wird die Logwatchoberfläche automatisch korrekt funktionieren.

Ab Version 1.4.0i1 von Check_MK verwendet die Logwatchwebseite ausschließlich Livestatus für die Übertragung und benötigt kein HTTP mehr. Das Einrichten von HTTP bzw. der Proxyregel ist dann lediglich noch für Benutzer der  Check_MK Raw Edition für PNP4Nagios nötig.

2.9. NagVis

Das Open-Source-Programm NagVis visualisiert Statusdaten aus dem Monitoring auf selbsterstellten Landkarten, Diagrammen und anderen Skizzen. NagVis ist in Check_MK integriert und kann sofort genutzt werden. Am einfachsten geht der Zugriff über das Seitenleistenelement NagVis Maps. Die Integration von NagVis in Check_MK beschreibt ein eigener Artikel.

NagVis unterstützt ein verteiltes Monitoring via Livestatus in ziemlich genau der gleichen Weise, wie es auch Check_MK macht. Die Anbindungen der einzelnen Sites nennt man Backends (Deutsch: Datenquellen). Die Backends werden von Check_MK automatisch korrekt angelegt, so dass Sie sofort damit loslegen können, NagVis-Karten zu erstellen – auch im verteilten Monitoring.

Wählen Sie bei jedem Objekt, das Sie auf einer Karte platzieren, das richtige Backend aus – also die Check_MK-Instanz, von der aus das Objekt überwacht wird. NagVis kann den Host oder Service nicht automatisch finden, vor allem aus Gründen der Performance. Wenn Sie also Hosts zu einem anderen Slave umziehen, müssen Sie danach Ihre NagVis-Karten entsprechend anpassen.

Einzelheiten zu den Backends finden Sie in der Dokumentation von NagVis.

3. Instabile oder langsame Verbindungen

Die gemeinsame Statusansicht in der Benutzeroberfläche erfordert einen ständig verfügbaren und zuverlässigen Zugriff auf alle angebundenen Instanzen. Eine Schwierigkeit dabei ist, dass eine Ansicht immer erst dann dargestellt werden kann, wenn alle Instanzen geantwortet haben. Der Ablauf ist immer so, dass an alle Instanzen eine Livestatusanfrage gesendet wird (z. B. „Gib mir alle Services, deren Zustand nicht OK ist."). Erst wenn die letzte Instanz geantwortet hat, kann die Ansicht dargestellt werden.

Ärgerlich wird es, wenn eine Instanz gar nicht antwortet. Um kurze Ausfälle zu tolerieren (z. B. durch einen Neustart einer Site oder verlorengegangene TCP-Pakete), wartet die GUI einen gewissen Timeout ab, bevor eine Instanz als deklariert wird und mit den Antworten der übrigen Sites fortgefahren wird. Das führt dann zu einer „hängenden“ GUI. Der Timeout ist per Default auf 10 Sekunden eingestellt.

Wenn das in Ihrem Netzwerk gelegentlich passiert, sollten Sie entweder Statushosts oder (besser) den Livestatusproxy einrichten.

3.1. Statushosts

Die Konfiguration von Statushosts ist der bei der  Check_MK Raw Edition empfohlene Weg, defekte Verbindungen zuverlässig zu erkennen. Die Idee dazu ist einfach: Die Masterinstanz überwacht aktiv die Verbindung zu jedem einzelnen Slave. Immerhin haben wir ein Monitoring­system zur Verfügung! Die GUI kennt dann nicht erreichbare Instanzen und kann diese sofort ausklammern und als werten. Timeouts werden so vermieden.

So richten Sie für eine Verbindung einen Statushost ein:

  1. Nehmen Sie den Host, auf dem die Slaveinstanz läuft, auf dem Master ins Monitoring auf.
  2. Tragen Sie diesen bei der Verbindung zum Slave als Statushost ein:

Eine ausgefallene Verbindung zur Slaveinstanz kann jetzt nur noch für kurze Zeit zu einem Hängen der GUI führen – nämlich solange, bis das Monitoring das erkannt hat. Durch ein Reduzieren des Prüfintervalls des Statushosts vom Default von 60 Sekunden auf z. B. 5 Sekunden können Sie dies minimieren.

Falls Sie einen Statushost eingerichtet haben, gibt es weitere mögliche Zustände für Verbindungen:

Der Rechner, auf dem die Slaveinstanz läuft, ist für das Monitoring gerade nicht erreichbar, weil ein Router dazwischen down ist (Statushost hat den Zustand UNREACH).
Der Statushost, der die Verbindung zum Slavesystem überwacht, wurde noch nicht vom Monitoring geprüft (steht noch auf PEND).
Der Zustand des Statushosts hat einen ungültigen Wert (sollte nie auftreten).

In allen drei Fällen wird die Verbindung zu der Instanz ausgeklammert, wodurch Timeouts vermieden werden.

3.2. Persistente Verbindungen

Mit der Checkbox Use persistent connections können Sie die GUI dazu veranlassen, einmal aufgebaute Livestatusverbindungen zu Slaveinstanzen permanent aufrecht zu erhalten und für weitere Anfragen wieder zu verwenden. Gerade bei Verbindungen mit einer längeren Paketlaufzeit (z. B. interkontinentale) kann das die GUI deutlich reaktiver machen.

Da die GUI von Apache auf mehrere unabhängige Prozesse aufgeteilt wird, ist pro gleichzeitig laufendem Apache-Clientprozess eine Verbindundung notwendig. Fall Sie viele gleichzeitige Benutzer haben, sorgen Sie bitte bei der Konfiguration des Nagioskerns des Slaves für eine ausreichende Anzahl von Livestatusverbindungen. Diese werden in der Datei etc/mk-livestatus/nagios.cfg konfiguriert. Der Default ist 20 (num_client_threads=20).

Per Default ist Apache in Check_MK so konfiguriert, dass er bis zu 128 gleichzeitige Benutzerverbindungen zulässt. Dies wird in der Datei etc/apache/apache.conf in folgendem Abschnitt konfiguriert:

etc/apache/apache.conf
<IfModule prefork.c>
StartServers         1
MinSpareServers      1
MaxSpareServers      5
ServerLimit          128
MaxClients           128
MaxRequestsPerChild  4000
</IfModule>

Das bedeutet, dass unter hoher Last bis zu 128 Apache-Prozesse entstehen können, welche dann auch bis zu 128 Livestatusverbindungen erzeugen und halten können. Sind die num_client_threads nicht entsprechend hoch eingstellt, kommt es zu Fehlern oder sehr langsamen Antwortzeiten in der GUI.

Bei Verbindungen im LAN oder in schnellen WAN-Netzen empfehlen wir, die persistenten Verbindungen nicht zu verwenden.

3.3. Der Livestatusproxy

.

Die  Check_MK Enterprise Edition verfügt mit dem Livestatusproxy über einen ausgeklügelten Mechanismus, um tote Verbindungen zu erkennen. Außerdem optimiert er die Performance vor allem bei Verbindungen mit hohen Round-Trip-Zeiten. Vorteile des Livestatusproxys sind:

  • Sehr schnelle proaktive Erkennung von nicht antwortenden Instanzen
  • Lokales Cachen von Anfragen, die statische Daten liefern
  • Stehende TCP-Verbindungen, dadurch weniger Roundtrips notwendig und somit viel schnellere Antworten von weit entfernten Instanzen (z. B. USA ⇄ China)
  • Genaue Kontrolle der maximal nötigen Livestatusverbindungen
  • Ermöglicht Hardware/Softwareinventur in verteilten Umgebungen

Aufsetzen

Das Aufsetzen des Livestatusproxies ist sehr einfach. In der CEE ist dieser per Default aktiviert, wie Sie beim Starten einer Site sehen können:

OMD[master]:~$ omd start
Starting mkeventd...OK
Starting Livestatus Proxy-Daemon...OK
Starting rrdcached...OK
Starting Check_MK Micro Core...OK
Starting dedicated Apache for site slave1...OK
Starting xinetd...OK
Initializing Crontab...OK

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

Die Angaben zu Host und Port sind wie gehabt. Auf dem Slave 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 (dem Slave) 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 Proto­kollebene. Dabei sendet der Proxy regelmäßig eine einfache Livestatusanfrage, welche vom Slave 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 Monitoringkern nicht mehr antwortet.

Bleibt die Antwort aus, so werden alle Verbindungen als tot deklariert und nach einer Cooldownzeit (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 vom Slave 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.

Fehlerdiagnose

Der Livestatusproxy hat eine eigene Logdatei, die Sie unter var/log/liveproxyd.log finden. Bei einem korrekt eingerichteten Slave mit fünf Kanälen (Standard), sieht das etwa so aus:

var/log/liveproxyd.log
2016-09-19 14:08:53.310197 ----------------------------------------------------------
2016-09-19 14:08:53.310206 Livestatus Proxy-Daemon starting...
2016-09-19 14:08:53.310412 Configured 1 sites
2016-09-19 14:08:53.310469 Removing left-over unix socket /omd/sites/master/tmp/run/liveproxy/slave1
2016-09-19 14:08:53.310684 Channel slave1/5 successfully connected
2016-09-19 14:08:53.310874 Channel slave1/6 successfully connected
2016-09-19 14:08:53.310944 Channel slave1/7 successfully connected
2016-09-19 14:08:53.311009 Channel slave1/8 successfully connected
2016-09-19 14:08:53.311071 Channel slave1/9 successfully connected

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

var/log/liveproxyd.state
Current state:
[slave1]
  State:                   ready
  Last Reset:              2016-09-19 14:08:53 (125 secs ago)
  Site's last reload:      2016-09-19 14:08:45 (134 secs ago)
  Last failed connect:     1970-01-01 01:00:00 (1474287059 secs ago)
  Cached responses:        1
  Last inventory update:   1970-01-01 01:00:00 (1474287059 secs ago)
  PID of inventory update: None
  Channels:
      5 - ready             -  client: none - since: 2016-09-19 14:10:38 ( 20 secs ago)
      6 - ready             -  client: none - since: 2016-09-19 14:10:43 ( 15 secs ago)
      7 - ready             -  client: none - since: 2016-09-19 14:10:48 ( 10 secs ago)
      8 - ready             -  client: none - since: 2016-09-19 14:10:53 (  5 secs ago)
      9 - ready             -  client: none - since: 2016-09-19 14:10:33 ( 25 secs ago)
  Clients:
  Heartbeat:
    heartbeats received: 24
    next in 0.2s

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

var/log/liveproxyd.state
----------------------------------------------
Current state:
[slave1]
  State:                   starting
  Last Reset:              2016-09-19 14:12:54 ( 10 secs ago)
  Site's last reload:      2016-09-19 14:12:54 ( 10 secs ago)
  Last failed connect:     2016-09-19 14:13:02 (  2 secs ago)
  Cached responses:        0
  Last inventory update:   1970-01-01 01:00:00 (1474287184 secs ago)
  PID of inventory update: None
  Channels:
  Clients:
  Heartbeat:
    heartbeats received: 0
    next in -5.2s

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 Site sofort mit einem Fehler beantwortet.

4. Livedump und CMCDump

4.1. Motivation

Das bisher beschriebene Konzept für ein verteiltes Monitoring mit Check_MK ist in den meisten Fällen eine gute und einfache Lösung. Es erfordert allerdings Netzwerkzugriff vom Master auf die Slaves. Es gibt Situtationen, in denen das entweder nicht möglich oder nicht gewünscht ist, z. B. weil

  • die Slaves in den Netzen Ihrer Kunden stehen, auf die Sie keinen Zugriff haben,
  • die Slaves in einem Sicherheitsbereich stehen, auf den Zugriff strikt verboten ist oder
  • die Slaves keine permanente Netzwerkverbindung und keine festen IP-Adressen haben.

Das verteilte Monitoring mit Livedump bzw. CMCDump geht einen ganz anderen Weg. Zunächst einmal sind die Slaves so aufgesetzt, dass sie völlig unabhängig vom Master arbeiten und denzentral adminis­triert werden. Auf ein verteiltes WATO wird verzichtet.

Dann werden im Master alle Hosts und Services der Slaves als Kopie angelegt. Dazu kann Livedump/CMC­Dump einen Abzug der Konfiguration der Slaves erstellen, der beim Master eingespielt wird.

Während des Monitorings wird nun auf jedem Slave einmal pro definiertem Intervall (z. B. jede Minute) ein Abzug des aktuellen Status in eine Datei geschrieben. Diese wird auf einem beliebigen Weg auf den Master übertragen und dort als Statusupdate eingespielt. Für die Übertragung ist kein bestimmtes Protokoll vorgesehen oder vorbestimmt. Alle automatisierbaren Übertragungsprotokolle kommen in Frage. Es muss nicht unbedingt scp sein – auch eine Übertragung per Email ist denkbar!

Ein solches Setup hat gegenüber dem „normalen“ verteilten Monitoring folgende Unterschiede:

  • Die Aktualisierung der Zustände und Messdaten im Master geschieht verzögert.
  • Eine Berechnung der Verfügbarkeit wird auf dem Master, im Vergleich mit dem Slave, geringfügig abweichende Werte ergeben.
  • Zustandswechsel, die schneller geschehen als das Aktualisierungsintervall, sind für den Master unsichtbar.
  • Ist ein Slave „tot“, so veralten die Zustände auf dem Master, die Services werden „stale“, sind aber immer noch sichtbar. Messdaten und Verfügbarkeitsdaten gehen für diesen Zeitraum verloren (auf dem Slave sind sie noch vorhanden).
  • Kommandos wie Downtimes und Acknowledgements auf dem Master können nicht auf den Slave übertragen werden.
  • Zu keiner Zeit erfolgt ein Zugriff vom Master auf die Slaves.
  • Ein Zugriff auf Logdateidetails von Logwatch ist nicht möglich.
  • Die Event Console wird von Livedump/CMCDump nicht unterstützt.

Da kurze Zustandswechsel bedingt durch das gewählte Intervall für den Master eventuell nicht sichtbar sind, ist eine Alarmierung durch den Master nicht ideal. Wird der Master jedoch als reine Anzeigeinstanz verwendet – z. B. für einen zentralen Überblick über alle Kunden – hat die Methode durchaus ihre Vorteile.

Livedump/CMCDump kann übrigens ohne Probleme gleichzeitig mit dem verteilten Monitoring über Livestatus verwendet werden. Manche Instanzen sind dann einfach direkt über Livestatus angebunden – andere verwenden Livedump. Dabei kann der Livedump auch in einen der Livestatusslaves eingespielt werden.

4.2. Aufsetzen von Livedump

Wenn Sie die  Check_MK Raw Edition einsetzen (oder die CEE mit Nagios als Kern), dann verwenden Sie das Werkzeug livedump. Der Name leitet sich ab von Livestatus und Status-Dump. Ab Version 1.2.8p12 von Check_MK befindet sich livedump direkt im Suchpfad und ist daher als Befehl verfügbar. In früheren Versionen finden Sie es unter ~/share/doc/check_mk/treasures/livedump/livedump.

Wir gehen im Folgenden davon aus, dass

  • die Slaveinstanz bereits voll eingerichtet ist und fleißig Hosts und Services überwacht,
  • die Masterinstanz gestartet ist und läuft und
  • auf dem Master mindestens ein Host lokal überwacht wird (z. B. weil der Master sich selbst überwacht).

Übertragen der Konfiguration

Als Erstes Erzeugen Sie auf dem Slave einen Abzug der Konfiguration seiner Hosts und Services im Nagios-Konfigformat. Leiten Sie dazu die Ausgabe von livedump -TC in eine Datei um:

OMD[slave1]:~$ livedump -TC > config.cfg

Der Anfag der Datei sieht in etwa wie folgt aus:

nagios.cfg
define host {
    name                    livedump-host
    use                     check_mk_default
    register                0
    active_checks_enabled   0
    passive_checks_enabled  1

}

define service {
    name                    livedump-service
    register                0
    active_checks_enabled   0
    passive_checks_enabled  1
    check_period            0x0

}

Übertragen Sie die Datei zum Master (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-slave1.cfg. Wenn ein SSH-Zugang vom Slave auf den Master möglich ist, geht das z. B. so:

OMD[slave1]:~$ scp config.cfg master@mymaster.mydomain:etc/nagios/conf.d/config-slave1.cfg
master@mymaster.mydomain's password:
config.cfg                                             100% 8071     7.9KB/s   00:00

Loggen Sie sich jetzt auf dem Master ein und aktivieren Sie die Änderungen:

OMD[master]:~$ cmk -R
Generating configuration for core (type nagios)...OK
Validating Nagios configuration...OK
Precompiling host checks...OK
Restarting monitoring core...OK

Nun sollten alle Hosts und Services des Slaves in der Masterintanz auftauchen – und zwar im Zustand PEND, in dem sie bis auf Weiteres auch bleiben:

Hinweise:

  • Durch die Option -T bei livedump erzeugt Livedump Template-Definitionen, auf die sich die Konfiguration bezieht. Ohne diese kann Nagios nicht gestartet werden. Sie dürfen jedoch nur einmal vorhanden sein. Falls Sie auch von einem zweiten Slave eine Konfiguration übertragen, so dürfen Sie die Option -T dort nicht verwenden!
  • Der Dump der Konfiguration ist auch auf einem CMC-Kern möglich, das Einspielen benötigt Nagios. Wenn auf Ihrem Master der CMC läuft, dann verwenden Sie CMCDump.
  • Das Abziehen und Übertragen der Konfiguration müssen Sie nach jeder Änderung von Hosts oder Services auf dem Slave wiederholen.

Übertragung des Status

Nachdem die Hosts im Master sichtbar sind, geht es jetzt an die (regelmäßige) Übertragung des Monitoringstatus des Slaves. Wieder erzeugen Sie mit livedump eine Datei, allerdings diesmal ohne weitere Optionen:

OMD[slave1]:~$ livedump > state

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

state
host_name=myserver666
check_type=1
check_options=0
reschedule_check
latency=0.13
start_time=1475521257.2
finish_time=1475521257.2
return_code=0
output=OK - 10.1.5.44: rta 0.005ms, lost 0%|rta=0.005ms;200.000;500.000;0; pl=0%;80;100;; rtmax=0.019ms;;;; rtmin=0.001ms;;;;

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

OMD[slave1]:~$ scp state master@mymaster.mydomain:tmp/nagios/checkresults/caabbcc
master@mymaster.mydomain's password:
state                                                  100%   12KB  12.5KB/s   00:00

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

OMD[master]:~$ touch tmp/nagios/checkresults/caabbcc.ok

Der Zustand der Hosts/Services des Slaves wird jetzt auf dem Master sofort aktualisiert:

Das Übertragen des Status muss ab jetzt natürlich regelmäßig gemacht werden. Livedump unterstützt Sie dabei leider nicht und Sie müssen das selbst skripten. In ~/share/check_mk/doc/treasures/livedump finden Sie das Skript livedump-ssh-recv, welches Sie einsetzen können, um Livedumpupdates (auch solche von der Konfiguration) per SSH auf dem Master zu empfangen. Details finden Sie 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 Hostgruppe mygroup:

OMD[slave]:~$ livedump -H "Filter: host_groups > mygroup" > state

Weitere Hinweise zu Livedump – insbesondere wie Sie die Datei per verschlüsselter Email übertragen können, finden Sie in der Datei README im Verzeichnis ~/share/doc/check_mk/treasures/livedump.

4.3. Aufsetzen von CMCDump

Was Livedump für Nagios ist, ist CMCDump für den Check_MK Micro Core – und damit das Tool der Wahl für die  Check_MK Enterprise Edition. Im Gegensatz zu Livedump kann CMCDump den vollständigen Status von Hosts und Services replizieren (Nagios bietet hier nicht die notwendigen Schnittstellen).

Zum Vergleich: Bei Livedump werden folgende Daten übertragen:

  • Der aktuelle Zustand, also PEND, OK, WARN, CRIT, UNKNOWN, UP, DOWN oder UNREACH
  • Die Ausgabe des Checkplugins
  • Die Messdaten

Zusätzlich synchronisiert CMCDump auch noch

  • die lange Ausgabe des Plugins,
  • ob das Objekte gerade unstetig ist,
  • Zeitpunkt der letzten Checkausführung und des letzten Statuswechsels,
  • Dauer der Checkausführung,
  • Latenz der Checkausführung,
  • die Nummer des aktuellen Checkversuchs und ob der aktuelle Zustand hart oder weich ist,
  • Quittierung, falls vorhanden und
  • ob das Objekt gerade in einer geplanten Wartungszeit ist.

Das Abbild des Monitorings ist hier also viel genauer. Der CMC simuliert beim Einspielen des Status nicht einfach eine Checkausführung, sondern überträgt mittels einer dafür bestimmten Schnittstelle einen korrekten Status. Das bedeutet unter anderem, dass Sie in der Zentrale jederzeit sehen können, ob Probleme quittiert oder Wartungszeiten eingetragen wurden.

Das Aufsetzen ist fast identisch wie bei Livedump, allerdings etwas einfacher, da Sie sich nicht um eventuelle doppelte Templates und dergleichen kümmern müssen.

Der Abzug der Konfiguration geschieht mit cmcdump -C. Legen Sie diese Datei auf dem Master unterhalb von etc/check_mk/conf.d/. Die Endung muss .mk heißen:

OMD[slave1]:~$ cmcdump -C > config.mk
OMD[slave1]:~$ scp config.mk master@mymaster.mydomain:etc/check_mk/conf.d/slave1.mk

Aktivieren Sie auf dem Master die Konfiguration:

OMD[master]:~$ cmk -O

Wie bei Livedump erscheinen jetzt die Hosts und Services auf dem Master im Zustand PEND. Allerdings sehen Sie gleich am Symbol , dass es sich um Schattenobjekte handelt. So können Sie diese von direkt auf dem Master oder einer „normalen“ Slaveinstanze überwachten Objekte unterscheiden:

Das regelmäßige Erzeugen des Status geschieht mit cmcdump ohne weitere Argumente:

OMD[slave1]:~$ cmcdump > state
OMD[slave1]:~$ scp state master@mymaster.mydomain:tmp/state_slave1

Zum Einspielen des Status auf dem Master muss der Inhalt der Datei mithilfe des Tools unixcat in das UNIX-Socket tmp/run/live geschrieben werden:

OMD[master]:~$ unixcat tmp/run/live < tmp/state_slave1

Falls Sie per SSH einen passwortlosen Zugang vom Slave zum Master haben, können Sie alle drei Befehle zu einem einzigen zusammenfassen – wobei nicht mal eine temporäre Datei entsteht:

OMD[slave1]:~$ cmcdump | ssh master@mymaster.mydomain "unixcat tmp/run/live"

Es ist wirklich so einfach! Aber wie schon erwähnt, ist ssh/scp nicht die einzige Methode, um Dateien zu übertragen und genausogut können Sie Konfiguration oder Status per Email oder einem beliebigen anderen Protokoll übertragen.

5. Alarmierung in verteilten Umgebungen

5.1. Zentral oder dezentral

In einer verteilten Umgebung stellt sich die Frage, von welcher Instanz aus Alarme (z. B. Emails) verschickt werden sollen: von den einzelnen Slaves aus oder vom Master. Für beide gibt es Argumente.

Argumente für den Versand von den Slaves aus:

  • Einfacher einzurichten.
  • Alarmierung vor Ort geht auch dann, wenn die Verbindung zum Master nicht verfügbar ist.
  • Geht auch mit der  Check_MK Raw Edition.

Argumente für den Versand vom Master aus:

  • Alarme können an einer zentralen Stelle weiterbehandelt werden (z. B. für Weiterleitung in Ticketsystem).
  • Slaveinstanzen benötigen kein Setup für Email oder SMSl
  • Bei Versand von SMS über Hardware ist diese nur einmal notwendig: auf dem Master.

5.2. Dezentrale Alarmierung

Für eine dezentrale Alarmierung sind keine besonderen Schritte notwendig, denn dies ist die Standard­einstellung. Jeder Alarm, der auf einer Slaveinstanz entsteht, durchläuft dort die Kette der Alarmierungs­regeln. Falls Sie verteiltes WATO einsetzen, sind diese Regeln auf allen Instanzen gleich. Aus den Regeln resultierende Alarme werden wie üblich zugestellt, indem lokal die entsprechenden Alarmierungsskripte aufgerufen werden.

Sie müssen lediglich sicherstellen, dass die entsprechenden Dienste auf den Instanzen korrekt aufgesetzt sind, also z. B. für Email ein Smarthost eingetragen ist – also die gleichen Schritte wie beim Einrichten einer einzelnen Check_MK-Instanz.

5.3. Zentrale Alarmierung

Grundlegendes

Die  Check_MK Enterprise Edition bietet einen eingebauten Mechnismus für ein zentralisiertes Alarmieren, welcher pro Slaveinstanz einzeln aktiviert werden kann. Solche Slaves leiten dann alle Alarme zur weiteren Verarbeitung an den Master weiter. Dabei ist die zentrale Alarmierung 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 Alarmierungsserver nicht mal der „Master“ sein. Diese Aufgabe kann jede Check_MK-Instanz übernehmen.

Ist eine Slaveinstanz auf Weiterleitung eingestellt, so werden alle Alarme direkt wie Sie vom Kern kommen – quasi in Rohform – an den Master weitergereicht. Erst dort werden die Alarmierungsregeln ausgewertet, welche entscheiden, wer und wie überhaupt benachrichtigt werden soll. Die dazu notwendigen Alarmierungsskripte werden auf dem Master aufgerufen.

Aktivieren des Alarmspoolers

Der erste Schritt für das Einrichten der zentralen Alarmierung ist das Aktivieren des Alarmspoolers (mknotifyd) auf allen beteiligten Instanzen. Dies ist ein Hilfsprozess, der sowohl auf dem Master, als auch auf den Slaves benötigt wird. In neueren Check_MK-Versionen ist der Alarmspooler automatisch aktiv. Bitte kontrollieren Sie dies mit omd config und schalten Ihn gegebenenfalls ein. Sie finden den Punkt unter Distributed Monitoring ➳ MKNOTIFYD.

Ein omd status muss den Prozess mknotifyd anzeigen:

OMD[mysite]:~$ omd status
OMD[master]:~$ omd status
mkeventd:       running
liveproxyd:     running
mknotifyd:      running
rrdcached:      running
cmc:            running
apache:         running
crontab:        running
-----------------------
Overall state:  running

Nur wenn der Alarmspooler aktiv ist, finden Sie in WATO in den globalen Einstellungen den Punkt Notifications ➳ Notifcation spooling.

Einrichten der TCP-Verbindungen

Die Alarmspooler von Slave und (Alarmierungs-) Master tauschen sich untereinander per TCP aus. Alarme werden vom Slave zum Master gesendet. Der Master quittiert empfangene Alarme an den Slave, was verhindert, dass Alarme verloren gehen, selbst wenn die TCP-Verbindung abbrechen sollte.

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

  1. TCP-Verbindung wird vom Master zum Slave aufgebaut. Hier ist der Slave der TCP-Server.
  2. TCP-Verbindung wird vom Slave zum Master aufgebaut. Hier ist der Master der TCP-Server.

Somit steht dem Weiterleiten von Alarmen 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 Heartbeatsignal überwacht und bei Bedarf sofort neu aufgebaut – nicht erst im Falle einer Alarmierung.

Da Slave und Master für den Spooler unterschiedliche globale Einstellungen brauchen, müssen Sie für alle Slaves instanzspezifische Einstellungen machen. Die Konfiguration des Masters geschieht über die normalen globalen Einstellungen. Dies liegt daran, dass Check_MK aktuell keine spezifischen Einstellungen für die lokale Instanz (= Masterinstanz) unterstützt. Bitte beachten Sie, dass diese automatisch an alle Slaves vererbt wird, für die Sie keine spezifischen Einstellungen definiert haben.

Betrachten Sie zuerst den Fall, dass der Master die TCP-Verbindungen zu den Slaves aufbauen soll.

Schritt 1: Editieren Sie beim Slave 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 dem Slave die Einstellung Notification Spooling auf den Wert Forward to remote site by notification spooler.

Schritt 3: Auf dem Master – also in den normalen globalen Einstellungen – richten Sie nun zu dem Slave (und später dann auch eventuell zu weiteren Slaves) die Verbindungen ein:

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

Schritt 5: Aktivieren Sie die Änderungen.

Verbindungsaufbau vom Slave aus

Soll die TCP-Verbindung vom Slave aus aufgebaut werden, so ist das Vorgehen identisch, bis auf die Tatsache, dass Sie die oben gezeigten Einstellungen einfach zwischen Master und Slave vertauschen.

Auch eine Mischung ist möglich. In diesem Fall muss der Master so aufgesetzt werden, dass er sowohl auf eingehende Verbindungen lauscht, als Verbindungen zu Slaveinstanzen aufbaut. Für jede Master/Slave-Beziehung darf aber nur einer von beiden die Verbindung aufbauen!

Test und Diagnose

Der Alarmspooler loggt in die Datei var/log/mknotifyd.log. In den Spoolereinstellungen können Sie das Loglevel erhöhen, so dass Sie mehr Meldungen kommen. Bei einem Standardloglevel sollten Sie auf dem Master etwa Folgendes sehen:

var/log/mknotifyd.log
2016-10-04 17:19:28 [5] -----------------------------------------------------------------
2016-10-04 17:19:28 [5] Check_MK Notification Spooler version 1.2.8p12 starting
2016-10-04 17:19:28 [5] Log verbosity: 0
2016-10-04 17:19:28 [5] Daemonized with PID 31081.
2016-10-04 17:19:28 [5] Successfully connected to 10.1.8.44:6555

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

master:var/log/mknotifyd.state (Auszug)
Connection:               10.1.8.44:6555
Type:                     outgoing
State:                    established
Status Message:           Successfully connected to 10.1.8.44:6555
Since:                    1475594368 (2016-10-04 17:19:28, 140 sec ago)
Connect Time:             0.000 sec

Die gleiche Datei gibt es auch auf den Slave. Dort sieht die Verbindung etwa so aus:

slave:var/log/mknotifyd.state (Auszug)
Connection:               10.22.4.12:56546
Type:                     incoming
State:                    established
Since:                    1475594368 (2016-10-04 17:19:28, 330 sec ago)

Zum Testen wählen Sie z. B. einen beliebigen Service, der auf dem Slave überacht wird, und setzen diesen per Kommando Fake check results auf CRIT.

Auf dem Master sollen Sie nun im Logfile der Alarmierung (notify.log) den eingehenen Alarm sehen:

master:var/log/notify.log
2016-10-04 17:27:57 ----------------------------------------------------------------------
2016-10-04 17:27:57 Got spool file 68c30b35 (myserver123;Check_MK) from remote host for local delivery.

Das gleiche Ereignis sieht beim Slave so aus:

slave:var/log/notify.log
2016-10-04 17:27:23 ----------------------------------------------------------------------
2016-10-04 17:27:23 Got raw notification (myserver123;Check_MK) context with 71 variables
2016-10-04 17:27:23 Creating spoolfile: /omd/sites/slave1/var/check_mk/notify/spool/f3c7dea9-0e61-4292-a190-785b4aa46a64

In den globalen Einstellungen können Sie sowohl das normale Alarmierungslog (notify.log) als auch das Log vom Alarmspooler auf ein höheres Loglevel umstellen.

Überwachung des Spoolings

Nachdem Sie alles wie beschrieben aufgesetzt haben, werden Sie feststellen, dass sowohl auf dem Master, als auch auf den Slaves jeweils ein neuer Service gefunden wird, den Sie unbedingt in die Überwachung aufnehmen sollten. Dieser überwacht den Alarmspooler und dessen TCP-Verbindungen. Dabei wird jede Verbindung zweimal überwacht: einmal durch den Master und einmal durch den Slave:

6. Dateien und Verzeichnisse

6.1. Konfigurationsdateien

Pfad Bedeutung
etc/check_mk/multisite.d/sites.mk Hier speichert WATO die Konfiguration der Verbindungen zu den einzelnen Instanzen. Sollte aufgrund von Fehlkonfiguration die Oberfläche so „hängen“, dass sie nicht mehr bedienbar ist, können Sie die störenden Einträge direkt in dieser Datei editieren. Falls der Livestatusproxy zum Einsatz kommt, ist anschließend jedoch ein Editieren und Speichern mindestens einer Verbindung über WATO notwendig, da erst hierbei für diesen Daemon eine passende Konfiguration erzeugt wird.
etc/check_mk/liveproxyd.mk Konfiguration für den Livestatusproxy. Diese Datei wird von WATO bei jeder Änderung an der Konfiguration des verteilten Monitorings neu generiert.
etc/check_mk/mknotifyd.d/wato/global.mk Konfiguration für den Alarmspooler. Diese Datei wird von WATO beim Speichern der globalen Einstellungen erzeugt.
etc/check_mk/conf.d/distributed_wato.mk Wird auf den Slaves vom verteilten WATO erzeugt und sorgt dafür, dass der Slave nur seine eigenen Hosts überwacht.
etc/nagios/conf.d/ Ablageort für selbst erstellte Nagios-Konfigurationsdateien mit Hosts und Services. Dies wird beim Einsatz von Livedump auf dem Master benötigt.
etc/mk-livestatus/nagios.cfg Konfiguration von Livestatus bei Verwendung von Nagios als Kern. Hier können Sie die maximale gleichzeitige Anzahl von Verbindungen konfigurieren.
etc/check_mk/conf.d/ Konfiguration von Hosts und Regeln für Check_MK. Legen Sie hier Konfigurations­dateien ab, die per CMCDump erzeugt wurden. Nur das Unterverzeichnis wato/ wird per WATO verwaltet und ist dort sichtbar.
var/check_mk/autochecks/ Von der Serviceerkennung gefundene Services. Dieses werden immer lokal auf dem Slave gespeichert.
var/check_mk/rrds/ Ablage der Round-Robin-Datenbanken für die Archivierung der Messwerte beim Einsatz des Check_MK-RRD-Formats (Default bei  Check_MK Enterprise Edition).
var/pnp4nagios/perfdata/ Ablage der Round-Robin-Datenbanken bei PNP4Nagios-Format ( Check_MK Raw Edition).
var/log/liveproxyd.log Logdatei des Livestatusproxies.
var/log/liveproxyd.state Aktueller Zustand des Livestatusproxies in lesbarer Form. Diese Datei wird alle fünf Sekunden aktualisiert.
var/log/notify.log Logdatei des Check_MK-Alarmierungssystems.
var/log/mknotifyd.log Logdatei des Alarmspoolers.
var/log/mknotifyd.state Aktueller Zustand des Alarmspoolers in lesbarer Form. Diese Datei wird alle 20 Sekunden aktualisiert.