Checkmk
to checkmk.com

In diesem Artikel sind die Screenshots und die beschriebene GUI-Navigation noch nicht auf dem Stand der Checkmk-Version 2.0.0. An den beschriebenen Funktionen selbst hat sich jedoch nichts Grundlegendes geändert und die meisten Funktionen lassen sich mit der Suche im Monitor- oder Setup-Menü der Checkmk 2.0.0 Benutzeroberfläche schnell finden. Wir werden diesen Artikel so bald wie möglich aktualisieren.

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

Checkmk unterstützt mehrere Verfahren für den Aufbau eines verteilten Monitorings. Manche davon beherrscht Checkmk, 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 Checkmk-eigenen Verfahren keine Vorteile und sind noch dazu umständlicher einzurichten. Wir empfehlen sie daher nicht.

Das von Checkmk 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 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" Monitoringsystem 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:

distributed monitoring

Das Besondere an dieser Methode ist, dass der Monitoringstatus 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 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 der Zentralinstanz und Remote-Instanz. Dadurch können hundert und mehr Standorte angebunden werden.

  • Zuverlässigkeit: Fällt die Netzwerkverbindung zu einer Remote-Instanz 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 Remote-Instanzen 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 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 spricht dabei von „verteiltem WATO“ (distributed WATO). Dabei werden alle Hosts und Services, Benutzer und Rechte, Zeitperioden, Alarme u.s.w. auf der Zentralinstanz per WATO 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.

2.2. Verteiltes Monitoring aufsetzen

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

  1. Zentralinstanz zunächst ganz normal wie eine Einzelinstanz aufsetzen

  2. Remote-Instanzen aufsetzen und Livestatus per Netzwerk freigeben

  3. Auf der Zentralinstanz die Remote-Instanzen per WATO-Modul icon sites Distributed monitoring einbinden

  4. Bei Hosts und Ordnern festlegen, von welcher Instanz aus diese überwacht werden sollen

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

Zentralinstanz aufsetzen

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.

Remote-Instanzen aufsetzen und Livestatus per Netzwerk freigeben

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:

  • Verwenden Sie für die Remote-Instanzen IDs, die in Ihrem verteilten Monitoring eindeutig sind.

  • Die Checkmk-Version (z.B. 2.0.0) der Remote- und Zentralinstanz ist dieselbe – ein Mischbetrieb wird nicht unterstützt. Die Patchlevel (z.B. p11) können zwar in den meisten Fällen unterschiedlich sein. In seltenen Fällen sind aber auch diese untereinander inkompatibel, so dass Sie den exakten Versionsstand (z.B. 2.0.0p11) auf allen Seiten einhalten müssen, damit eine fehlerfreie Zusammenarbeit der Instanzen möglich ist. Beachten Sie daher immer die inkompatiblen Änderungen zu jeder Patchversion in den Werks.

  • Da Checkmk mehrere Instanzen auf einem Server unterstützt, kann die Remote-Instanz auch auf dem gleichen Server laufen.

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

root@linux# omd create remote1
Adding /opt/omd/sites/remote1/tmp to /etc/fstab.
Creating temporary filesystem /omd/sites/remote1/tmp...OK
Updating core configuration...
Generating configuration for core (type cmc)...Creating helper config...OK
OK
Restarting Apache...OK
Created new site remote1 with version 1.6.0.

  The site can be started with omd start remote1.
  The default web UI is available at http://myServer/remote1/

  The admin user for the web applications is cmkadmin with password: lEnM8dUV
  For command line administration of the site, log in with 'omd su remote1'.
  After logging in, you can change the password for cmkadmin with 'htpasswd etc/htpasswd cmkadmin'.

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 Instanz per omd config:

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

Wählen Sie jetzt Distributed Monitoring:

livestatus tcp 1

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:

livestatus tcp 3

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

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

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

Remote-Instanzen in die Zentralinstanz einbinden

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

distributed monitoring 1

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

dm basic settings

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.

dm livestatus settings

Bei den Livestatus settings 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. 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 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 icon help Onlinehilfe oder dem Artikel zu HTTPS mit Checkmk.

dm distributed wato

Die Verwendung von Distributed WATO ist, wie eingangs besprochen, optional. Aktivieren Sie diese, 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 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 Remote-Instanz HTTPS unterstützt. Dies muss auf Linux-Ebene auf 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:

dm before login

Der Monitoringstatus der (noch leeren) Remote-Instanz ist jetzt schon korrekt eingebunden. Für das verteilte WATO benötigen Sie noch einen Login auf das WATO der Instanz. Dabei tauscht die Zentralinstanz per HTTP mit der Remote-Instanz ein zufällig erzeugtes Passwort aus, über das dann in Zukunft alle weitere Kommunikation abläuft. Der Zugang cmkadmin auf der Instanz wird dann nicht mehr verwendet.

Verwenden Sie zum Login die Zugangsdaten cmkadmin und dem entsprechenden Passwort auf der Remote-Instanz:

dm login

Ein erfolgreicher Login wird so quittiert:

dm logged in

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

  1. Die Remote-Instanz ist gerade gestoppt.

  2. Die Multisite-URL of remote site ist nicht korrekt eingestellt.

  3. Die Remote-Instanz ist unter dem in der URL eingestellten Hostnamen von der Zentralinstanz aus nicht erreichbar.

  4. Zentralinstanz und Remote-Instanz haben (zu) unterschiedliche Checkmk-Versionen.

  5. Benutzer und/oder Passwort sind falsch.

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 Changes aus. Dieser bringt Sie wie immer zur Übersicht der noch nicht aktivierten Änderungen. Gleichzeitig zeigt er Ihnen einen Status der Livestatusverbindungen sowie des WATO-Synchronisationszustands der einzelnen Instanzen:

dm pending changes

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

Folgende Symbole zeigen Ihnen den Replikationsstatus von WATO:

icon need restart

Diese Instanz hat ausstehende Änderungen. Die Konfiguration stimmt mit der Zentralinstanz überein, aber es sind nicht alle Änderungen aktiviert. Mit dem Knopf Restart können Sie diese gezielt für diese Instanz aktivieren.

icon need replicate

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:

button sitestatus online

Die Instanz ist per Livestatus erreichbar.

button sitestatus dead

Die Instanz ist gerade nicht erreichbar. Livestatus-Anfragen laufen in einen Timeout. Dies verögert den Seitenaufbau. Statusdaten dieser Instanz sind in der GUI nicht sichtbar.

button sitestatus down

Die Instanz ist gerade nicht erreichbar, aber das ist aufgrund der Einrichtung eines Statushosts oder durch den Livestatus-Proxy bekannt (siehe unten). Die Nichterreichbarkeit führt nicht zu Timeouts. Statusdaten dieser Instanz sind in der GUI nicht sichtbar.

button sitestatus disabled

Die Livestatusverbindung zu dieser Instanz ist vorübergehend durch den Administrator (der Zentralinstanz) deaktiviert worden. Die Einstellung entspricht der Checkbox Temporarily disable this connection in der Einstellung dieser Verbindung.

Ein Klick auf button activate changes 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 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.

Bei Hosts und Ordnern festlegen, von welcher Instanz aus diese überwacht 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 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:

folder monitored on

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 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 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. Livestatus verschlüsselt anbinden

Ab 1.6.0 können Livestatusverbindungen zwischen der Zentralinstanz und einer Remote-Instanz verschlüsselt werden. Bei neu erzeugten Instanzen müssen nichts weiter tun. Checkmk kümmert sich automatisch um nötigen Schritte. Sobald Sie dann mittels omd config Livestatus aktivieren, ist die Verschlüsselung durch TLS automatisch aktiviert:

distributed monitoring tls

Die Konfiguration des verteilten Monitoring bleibt daher so einfach, wie bisher. Bei neuen Verbindungen zu anderen Instanzen ist dann die Option Encryption automatisch aktiviert.

Nachdem Sie die Remote-Instanz hinzugefügt haben, werden Sie zwei Dinge bemerken: Zum einen die Verbindung durch das neue Icon icon encrypted als verschlüsselt markiert. Und zum anderen wird Checkmk Ihnen anzeigen, dass der CA der Remote-Instanz nicht vertraut wird. Mit einem Klick auf icon encrypted gelangen Sie in die Details der benutzten Zertifikate. Mit einem Klick auf icon trust können Sie die CA bequem über die Weboberfläche hinzufügen. Danach werden beide Zertifikate als vertrauenswürdig gelistet:

distributed monitoring cert

Details zu den eingesetzten Technologien

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:

  • Beide Zertifikate liegen in dem PEM-Format vor. Das signierte Zertifikate der Instanz enthält außerdem die komplette Zertifikatskette.

  • Die Schlüssel verwenden 2048-bit RSA und das Zertifikat wird mit SHA512 signiert.

  • Das Zertifikat der Instanz ist 999 Jahre gültig.

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)!

Eigene Zertifikate nutzen

In größeren Umgebungen möchten Sie vielleicht sowieso eigene Zertifikate benutzen. Um die mitgelieferten zu ersetzen, tauschen Sie lediglich das Instanz-Zertifikat durch Ihr eigenes aus und stellen sicher, dass der CA, welche das neue Zertifikat signiert hat, auch vertraut wird.

Migrieren von älteren Versionen

Die Option LIVESTATUS_TCP_TLS wird bei einem Update von einer älteren Version auf 1.6.0 aus Kompatibilitätsgründen nicht automatisch aktiviert, da danach die Verbindung nur noch verschlüsselt möglich ist. Um nach dem Update das neue Feature in Ihren Monitoring-Instanzen zu nutzen, stoppen Sie die jeweilige Instanz und aktivieren Sie die erwähnte Option:

OMD[mysite]:~$ omd config set LIVESTATUS_TCP_TLS on

Da die Zertifikate bei dem Update automatisch erzeugt wurden, wird die Instanz danach sofort das neue Verschlüsselungs-Feature nutzen. Damit Sie also von der Zentralinstanz weiterhin auf die Remote-Instanz zugreifen können, aktivieren Sie im zweiten Schritt unter WATO > Distributed Monitoring in den Eigenschaften der Instanzverbindung die Option Encryption:

distributed monitoring encryption

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

2.4. 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, Alert Handler und alles andere. Das ist sehr wichtig, denn es ist überhaupt nicht gesagt, dass die Zentralinstanz 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:

dm all hosts

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

dm service details

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:

dm filter site

Sitestatus-Element

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

snapin site status

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.

Master control Snapin

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

dm master control

Checkmk Clusterhosts

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 Cachedateien zugegriffen wird, welche beim Überwachen der Nodes entstehen. Diese liegen lokal auf der jeweiligen Instanz.

Huckepackdaten (z.B. ESXi)

Manche Check-Plugins 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 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-Hostsysteme direkt abfragen. Details dazu finden Sie in der Dokumentation zur ESXi-Überwachung.

Hardware-/Softwareinventur

Die Checkmk-Inventurisierung 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 Performancegründen immer lokal auf dieses Verzeichnis zu.

In den CEE Checkmk Enterprise Editions geschieht die Synchronisation automatisch auf allen Instanz, bei denen Sie den Livestatus-Proxy zur Verbindung einsetzen.

Falls Sie mit der CRE Checkmk Raw Edition in einem verteilten System Inventarisierung verwenden, müssen Sie das Verzeichnis mit eigenen Mitteln regelmäßig zur Zentralinstanz 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 Instanz 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 button sidebar settings 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.

dm change password

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.5. 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 Checkmk-Version), geschieht dies genau wie beim Einrichten einer neuen Remote-Instanz. Geben Sie Livestatus per TCP frei, tragen Sie die Instanz im Modul icon sites 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 Host-Merkmale anpassen

  2. WATO-Verzeichnisse kopieren

  3. Eigenschaften im Elternordner einmal editieren

1. Hostmerkmale

Es versteht sich von selbst, dass die in der Remote-Instanz verwendeten Host-Merkmale (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.

2. WATO-Verzeichnisse

Als Zweites ziehen die Hosts und Regeln in das zentrale WATO auf der Zentralinstanz um. Das funktioniert nur für Hosts und Regeln, die in Unterordnern liegen (also nicht im „Main directory“). Hosts im Hauptverzeichnis sollten Sie auf der Remote-Instanz 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 Instanz an die gleiche Stelle in die Zentralinstanz 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 Zentrale verwendet werden.

Nach dem Kopieren sollten die Hosts im zentralen WATO 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 Ordner in der versteckten Datei .wato.

3. Einmal editieren und speichern

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 Hostattribute neu berechnet.

2.6. 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 Checkmk 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 button configuration im WATO-Modul icon sites Distributed monitoring:

dm site specific settings

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:

dm site specific settings2

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

2.7. Verteilte Event Console

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

Checkmk bietet 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 funktioniert sowohl mit der CRE Checkmk Raw Edition als auch mit den CEE Checkmk Enterprise Editions.

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 der Remote-Instanz 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.8. PNP4Nagios

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

graphingpnp

Im verteilten Monitoring liegen die Metrikdatenbanken (RRDs) immer lokal auf den Remote-Instanzen. Das ist sehr wichtig, da so eine ständige Übertragung aller Messdaten zur Zentrale 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 Checkmk 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 von der Zentralinstanz abgerufen und an den Benutzer weitergeleitet.

1. Abruf durch den Browser des Benutzers

Die erste Methode ist sehr einfach einzurichten. Konfigurieren Sie bei den entsprechenden Instanz 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/:

dm status host

Checkmk 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 die Remote-Instanz von der Zentralinstanz 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 Checkmk-GUI holt, wird das Checkmk-Sitzungscookie nicht gesendet. Für jede Remote-Instanz muss sich der Benutzer daher einmal neu anmelden. Beim ersten Zugriff auf einen Graphen erscheint dann eine Anmeldemaske.

  • Die Remote-Instanz ist eventuell vom Browser des Benutzers gar nicht erreichbar — sondern nur von der Zentralinstanz 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 die Zentralinstanz

Die beste Lösung für diese Probleme ist, die PNP4Nagios-Daten nicht mehr vom Browser des Nutzers selbst, sondern von der Zentrale holen zu lassen. Dazu legen Sie auf dem Apache-Server der Zentrale eine Proxyregel an. Diese leitet Anfragen an PNP4Nagios per HTTP oder HTTPS auf den richtigen entfernten Server 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 Checkmk in Ihrem Netzwerk eindeutig sind, denn Apache muss anhand der ID der Remote-Instanz entscheiden können, an welchen Server weitergeleitet wird.

Gehen wir von folgendem Beispiel aus:

IDIP-AddresseLivestatusURL von Checkmk

central

10.15.18.223

lokal

10.15.18.223/central/check_mk/

remote1

10.1.1.133

Port 6557

10.1.1.133/remote1/check_mk/

Setzen Sie nun in der Verbindungseinstellung als URL-Präfix lediglich /remote1/ ein:

dm url prefix proxy

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

Im allgemeinen Fall, dass die Remote-Instanz 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:

DistributionPfad

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 Remote-Instanz aus fünf Zeilen. Ersetzen Sie in folgendem Beispiel den Namen der Instanz (hier remote1) und die URL zur Instanz (hier 10.1.1.133/remote1/). 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 /remote1>
    Options +FollowSymLinks
    RewriteEngine On
    RewriteRule ^/.+/remote1/(.*) http://10.1.1.133/remote1/$1 [P]
</Location>

Diese Regel sagt Apache, dass alle URLs, die mit /remote1 beginnen via Reverse-Proxy von der URL 10.1.1.133/remote1 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.9. Logwatch

Checkmk 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:

logwatch

Bis zur Version 1.2.8 von Checkmk benötigt diese Seite lokalen Zugriff auf die gespeicherten Logmeldungen. Diese legt das Plugin auf der Remote-Instanz ab, von dem aus der entsprechende Server überwacht wird. Im verteilten Monitoring hat die Zentrale aber keinen direkten Zugriff auf diese Dateien. Die Lösung ist die gleiche wie bei PNP4Nagios: Die Logwatchwebseite der Remote-Instanz wird eingebettet und separat per HTTP dieser geholt.

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

Ab Version 1.4.0i1] von Checkmk 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 CRE Checkmk Raw Edition für PNP4Nagios nötig.

2.10. NagVis

nagvis

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

NagVis unterstützt ein verteiltes Monitoring via Livestatus in ziemlich genau der gleichen Weise, wie es auch Checkmk macht. Die Anbindungen der einzelnen Instanzen nennt man Backends (Deutsch: Datenquellen). Die Backends werden von Checkmk 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 Checkmk-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 einer anderen Remote-Instanz 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 Livestatus-Anfrage 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 Instanz oder verlorengegangene TCP-Pakete), wartet die GUI einen gewissen Timeout ab, bevor eine Instanz als button sitestatus dead deklariert wird und mit den Antworten der übrigen Instanzen 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 Livestatus-Proxy einrichten.

3.1. Statushosts

CRE Die Konfiguration von Statushosts ist der bei der CRE Checkmk Raw Edition empfohlene Weg, defekte Verbindungen zuverlässig zu erkennen. Die Idee dazu ist einfach: Die Zentrale überwacht aktiv die Verbindung zu jeder einzelnen entfernten Instanz. Immerhin haben wir ein Monitoringsystem zur Verfügung! Die GUI kennt dann nicht erreichbare Instanzen und kann diese sofort ausklammern und als button sitestatus down werten. Timeouts werden so vermieden.

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

  1. Nehmen Sie den Host, auf dem die Remote-Instanz läuft, auf der Zentralinstanz ins Monitoring auf.

  2. Tragen Sie diesen bei der Verbindung zur Remote-Instanz als Statushost ein:

dm status host 2

Eine ausgefallene Verbindung zur Remote-Instanz 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:

button sitestatus unreach

Der Rechner, auf dem die Remote-Instanz läuft, ist für das Monitoring gerade nicht erreichbar, weil ein Router dazwischen down ist (Statushost hat den Zustand UNREACH).

button sitestatus waiting

Der Statushost, der die Verbindung zur Remote-Instanz überwacht, wurde noch nicht vom Monitoring geprüft (steht noch auf PEND).

button sitestatus unknown

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

CRE Mit der Checkbox Use persistent connections können Sie die GUI dazu veranlassen, einmal aufgebaute Livestatusverbindungen zu Remote-Instanzen 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 der Remote-Instanz 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 Checkmk 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 eingestellt, 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 Livestatus-Proxy

CEE Die CEE Checkmk Enterprise Editions verfügen mit dem Livestatus-Proxy ü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 Livestatus-Proxys 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 Livestatus-Proxys ist sehr einfach. In der CEE ist dieser per Default aktiviert, wie Sie beim Starten einer Instanz sehen können:

{c-central} omd start
Starting mkeventd...OK
Starting Livestatus Proxy-Daemon...OK
Starting rrdcached...OK
Starting Check_MK Micro Core...OK
Starting dedicated Apache for site remote1...OK
Starting xinetd...OK
Initializing Crontab...OK

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

dm livestatusproxy

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

Fehlerdiagnose

Der Livestatus-Proxy hat eine eigene Logdatei, 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:

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/central/tmp/run/liveproxy/remote1
2016-09-19 14:08:53.310684 Channel remote1/5 successfully connected
2016-09-19 14:08:53.310874 Channel remote1/6 successfully connected
2016-09-19 14:08:53.310944 Channel remote1/7 successfully connected
2016-09-19 14:08:53.311009 Channel remote1/8 successfully connected
2016-09-19 14:08:53.311071 Channel remote1/9 successfully connected

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

var/log/liveproxyd.state
Current state:
[remote1]
  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:
[remote1]
  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 Instanz sofort mit einem Fehler beantwortet.

4. Livedump und CMCDump

4.1. Motivation

Das bisher beschriebene Konzept für ein verteiltes Monitoring mit Checkmk ist in den meisten Fällen eine gute und einfache Lösung. Es erfordert allerdings Netzwerkzugriff von der Zentralinstanz auf die Remote-Instanzen. Es gibt Situationen, in denen das entweder nicht möglich oder nicht gewünscht ist, z.B. weil

  • die Instanzen in den Netzen Ihrer Kunden stehen, auf die Sie keinen Zugriff haben,

  • die Instanzen in einem Sicherheitsbereich stehen, auf den Zugriff strikt verboten ist oder

  • die Instanzen keine permanente Netzwerkverbindung oder keine feste IP-Adressen haben und Techniken, wie Dynamisches DNS keine Option sind.

Das verteilte Monitoring mit Livedump bzw. CMCDump geht einen ganz anderen Weg. Zunächst einmal sind die Remote-Instanzen so aufgesetzt, dass sie völlig unabhängig von der Zentralinstanz arbeiten und dezentral administriert werden. Auf ein verteiltes WATO wird verzichtet.

Dann werden in der Zentralinstanz alle Hosts und Services der Remote-Instanzen als Kopie angelegt. Dazu kann Livedump/CMCDump einen Abzug der Konfiguration der Remote-Instanzen erstellen, der bei der Zentralinstanz eingespielt wird.

Während des Monitorings wird nun auf jeder Remote-Instanz einmal pro definiertem Intervall (z.B. jede Minute) ein Abzug des aktuellen Status in eine Datei geschrieben. Diese wird auf einem beliebigen Weg auf die Zentrale ü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 E-Mail ist denkbar!

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

  • Die Aktualisierung der Zustände und Messdaten in der Zentrale geschieht verzögert.

  • Eine Berechnung der Verfügbarkeit wird auf der Zentralinstanz, im Vergleich mit der Remote-Instanz, geringfügig abweichende Werte ergeben.

  • Zustandswechsel, die schneller geschehen als das Aktualisierungsintervall, sind für die Zentrale unsichtbar.

  • Ist eine Remote-Instanz „tot“, so veralten die Zustände auf der Zentralinstanz, die Services werden „stale“, sind aber immer noch sichtbar. Messdaten und Verfügbarkeitsdaten gehen für diesen Zeitraum verloren (auf der Remote-Instanz sind sie noch vorhanden).

  • Kommandos wie Downtimes und Acknowledgements auf der Zentralinstanz können nicht auf die Remote-Instanz übertragen werden.

  • Zu keiner Zeit erfolgt ein Zugriff von der Zentralinstanz auf die Remote-Instanz.

  • 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 die Zentralinstanz eventuell nicht sichtbar sind, ist eine Alarmierung durch die Zentrale nicht ideal. Wird die Zentrale 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 eine der entfernten Livestatus-Instanzen eingespielt werden.

4.2. Aufsetzen von Livedump

CRE Wenn Sie die CRE Checkmk 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 Checkmk 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 Remote-Instanz bereits voll eingerichtet ist und fleißig Hosts und Services überwacht, * die Zentralinstanz gestartet ist und läuft und * auf der Zentrale mindestens ein Host lokal überwacht wird (z.B. weil sie sich selbst überwacht).

Übertragen der Konfiguration

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

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

Der Anfang 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 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:

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

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

OMD[central]:~$ 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 der Remote-Instanz in der Zentralinstanz auftauchen — und zwar im Zustand PEND, in dem sie bis auf Weiteres auch bleiben:

dm livedump pending

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 einer zweiten Remote-Instanz 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 Ihrer Zentralinstanz 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 der Remote-Instanz wiederholen.

Übertragung des Status

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

OMD[remote1]:~$ 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 die Zentralinstanz 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[remote1]:~$ scp state central@myserver.mydomain:tmp/nagios/checkresults/caabbcc
server@myserver.mydomain's password:
state                                                  100%   12KB  12.5KB/s   00:00

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:

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

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

dm livedump notpending

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 der Zentralinstanz zu empfangen. Details finden Sie im Skript selbst.

Sie können den Dump von Konfiguration und Status auch durch die Angabe von Livestatusfiltern einschränken, z.B. die Hosts auf die Mitglieder der Hostgruppe mygroup:

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

Weitere Hinweise zu Livedump — insbesondere wie Sie die Datei per verschlüsselter E-Mail ü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 Checkmk Micro Core — und damit das Tool der Wahl für die CEE Checkmk Enterprise Editions. 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 Check-Plugins

  • Die Messdaten

Zusätzlich synchronisiert CMCDump auch noch

  • die lange Ausgabe des Plugins,

  • ob das Objekte gerade icon flapping 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,

  • icon ack Quittierung, falls vorhanden und

  • ob das Objekt gerade in einer icon downtime 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 der Zentralinstanz unterhalb von etc/check_mk/conf.d/. Die Endung muss .mk heißen:

OMD[remote1]:~$ cmcdump -C > config.mk
OMD[remote1]:~$ scp config.mk central@mycentral.mydomain:etc/check_mk/conf.d/remote1.mk

Aktivieren Sie auf der Zentralinstanz die Konfiguration:

OMD[central]:~$ cmk -O

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

dm cmcdump pending

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

OMD[remote1]:~$ cmcdump > state
OMD[remote1]:~$ scp state central@mycentral.mydomain:tmp/state_remote1

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

OMD[central]:~$ unixcat tmp/run/live < tmp/state_remote1

Falls Sie per SSH einen passwortlosen Zugang von der Remote-Instanz zur Zentralinstanz haben, können Sie alle drei Befehle zu einem einzigen zusammenfassen — wobei nicht mal eine temporäre Datei entsteht:

OMD[remote1]:~$ cmcdump | ssh central@mycentral.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 E-Mail 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. E-Mails) verschickt werden sollen: von den einzelnen entfernten Instanzen oder von der Zentralinstanz aus. Für beide gibt es Argumente.

Argumente für den Versand von den Remote-Instanz aus:

  • Einfacher einzurichten.

  • Alarmierung vor Ort geht auch dann, wenn die Verbindung zur Zentrale nicht verfügbar ist.

  • Geht auch mit der CRE Checkmk Raw Edition.

Argumente für den Versand von der Zentralinstanz aus:

  • Alarme können an einer zentralen Stelle weiterbehandelt werden (z.B. für Weiterleitung in Ticketsystem).

  • Remote-Instanzen benötigen kein Setup für E-Mail oder SMS

  • Bei Versand von SMS über Hardware ist diese nur einmal notwendig: auf der Zentrale.

5.2. Dezentrale Alarmierung

Für eine dezentrale Alarmierung sind keine besonderen Schritte notwendig, denn dies ist die Standardeinstellung. Jeder Alarm, der auf einer Remote-Instanz entsteht, durchläuft dort die Kette der Alarmierungsregeln. 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 E-Mail ein Smarthost eingetragen ist — also die gleichen Schritte wie beim Einrichten einer einzelnen Checkmk-Instanz.

5.3. Zentrale Alarmierung

Grundlegendes

CEE Die CEE Checkmk Enterprise Editions bieten einen eingebauten Mechanismus für ein zentralisiertes Alarmieren, welcher pro Remote-Instanz einzeln aktiviert werden kann. Solche Remote-Instanzen leiten dann alle Alarme zur weiteren Verarbeitung an die Zentralinstanz 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 die „Zentralinstanz“ sein. Diese Aufgabe kann jede Checkmk-Instanz übernehmen.

Ist eine entfernte Instanz auf Weiterleitung eingestellt, so werden alle Alarme direkt wie Sie vom Kern kommen — quasi in Rohform — an die Zentralinstanz weitergereicht. Erst dort werden die Alarmierungsregeln ausgewertet, welche entscheiden, wer und wie überhaupt benachrichtigt werden soll. Die dazu notwendigen Alarmierungsskripte werden auf der Zentralinstanz 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 der Zentralinstanz, als auch auf den Remote-Instanzen benötigt wird. In neueren Checkmk-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.

omd config mknotifyd

Ein omd status muss den Prozess mknotifyd anzeigen:

OMD[mysite]:~$ 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 entfernter und zentraler (Alarmierungs-)Instanz tauschen sich untereinander per TCP aus. Alarme werden von der Remote-Instanz zur Zentralinstanz gesendet. Die Zentrale quittiert empfangene Alarme an die Remote-Instanz, 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 von Zentralinstanz zur Remote-Instanz aufgebaut. Hier ist die Remote-Instanz der TCP-Server.

  2. TCP-Verbindung wird von Remote-Instanz zur Zentralinstanz aufgebaut. Hier ist die Zentralinstanz 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 Remote-Instanz und Zentralinstanz für den Spooler unterschiedliche globale Einstellungen brauchen, müssen Sie für alle Remote-Instanzen instanzspezifische Einstellungen machen. Die Konfiguration der Zentrale geschieht über die normalen globalen Einstellungen. Dies liegt daran, dass Checkmk aktuell keine spezifischen Einstellungen für die lokale Instanz (= Zentralinstanz) unterstützt. Bitte 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.

mknotifyd listen

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.

mknotifyd spool

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:

mknotifyd tcp connect

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.

mknotifyd spool async

Schritt 5: Aktivieren Sie die Änderungen.

Verbindungsaufbau von der Remote-Instanz aus

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 er sowohl auf eingehende Verbindungen lauscht, als Verbindungen zu entfernten Instanzen aufbaut. Für jede Beziehung zwischen Zentralinstanz und Remote-Instanz 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 der Zentralinstanz 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:

central: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 der Remote-Instanz. Dort sieht die Verbindung etwa so aus:

remote-1: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 der Remote-Instanz überacht wird, und setzen diesen per Kommando Fake check results auf CRIT.

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

central: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 bei der Remote-Instanz so aus:

remote-1: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/remote1/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 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 Alarmspooler und dessen TCP-Verbindungen. Dabei wird jede Verbindung zweimal überwacht: einmal durch die Zentralinstanz und einmal durch die Remote-Instanz:

mknotifyd checks

6. Dateien und Verzeichnisse

6.1. Konfigurationsdateien

PfadBedeutung

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 Livestatus-Proxy 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 Livestatus-Proxy. 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 Remote-Instanzen vom verteilten WATO erzeugt und sorgt dafür, dass sie nur ihre 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 der Zentralinstanz 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 Checkmk. Legen Sie hier Konfigurationsdateien 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 der Remote-Instanz gespeichert.

var/check_mk/rrds/

Ablage der Round-Robin-Datenbanken für die Archivierung der Messwerte beim Einsatz des Checkmk-RRD-Formats (Default bei den Enterprise Editions).

var/pnp4nagios/perfdata/

Ablage der Round-Robin-Datenbanken bei PNP4Nagios-Format (CRE Checkmk Raw Edition).

var/log/liveproxyd.log

Logdatei des Livestatus-Proxys.

var/log/liveproxyd.state

Aktueller Zustand des Livestatus-Proxys in lesbarer Form. Diese Datei wird alle fünf Sekunden aktualisiert.

var/log/notify.log

Logdatei des Checkmk-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.

Auf dieser Seite