1. Einleitung
In Checkmk haben Sie viele Möglichkeiten, Ihre Infrastruktur zu überwachen. Die Überwachung durch einen Agenten oder SNMP sind dabei nur zwei von mehreren Methoden. Beiden ist gemein, dass sie einem nur Zustände mitteilen, wie sie der Host von innen heraus sieht. Sie werden aber sicher einige Dienste kennen, die man nur von außen sinnvoll überwachen kann. Ob der Webserver läuft, lässt sich noch von innen heraus beantworten. Wie jedoch die Erreichbarkeit und die Antwortzeiten bei dem eigentlichen Benutzer aussehen, lässt sich auf diese Weise nicht herausfinden.
Checkmk bietet für diese Fälle die aktiven Checks (active checks) an. Über diese können Sie Netzwerkdienste direkt und bequem von außen überwachen und die Daten auf ihrem Host anzeigen lassen. Aktive Checks sind also kleine Programme oder Skripte, die eine Verbindung zu einem Dienst im Netzwerk oder Internet aufbauen und dem Benutzer dann die Monitoring-Daten zur Verfügung stellen. Viele der Skripte und Programme, die Sie in Checkmk finden, stammen ursprünglich von monitoring-plugins.org. Da Checkmk aber generell kompatibel zu Nagios ist, können Sie alle Plugins nutzen, die auch unter Nagios funktionieren.
Wenn Sie solche Plugins integrieren, behalten Sie den Hauptzweck der aktiven Checks im Auge: Sie sollen im Sinne eines End-to-End-Monitorings die Erreichbarkeit, Antwortzeit oder den Antwortstatus eines über das Netzwerk erreichbaren Dienstes auf dem überwachten Host prüfen. Für viele andere Überwachungsaufgaben bietet Checkmk effizientere Checks. Eine Übersicht finden Sie im Artikel Erweiterungen für Checkmk entwickeln.
Die wichtigsten dieser Programme und Skripte sind in Checkmk direkt in der Weboberfläche verfügbar. Hier eine kleine Auswahl:
2. Aktive Checks einrichten
2.1. Reguläre aktive Checks einrichten
Im Setup können Sie — wie bereits weiter oben erwähnt — die wichtigsten und am häufigsten genutzten Checks direkt in der Weboberfläche einrichten. Wählen Sie dafür den Menüpunkt Setup > Services > HTTP, TCP, Email. Hier finden Sie die Regelsätze, mit denen Sie diese Checks einrichten können:
Die meisten Optionen in den Regelsätzen sind selbsterklärend. Falls doch einmal etwas unklar sein sollte, können Sie auch hier für viele Optionen auf die Inline-Hilfe zurückgreifen.
2.2. Aktive Checks einem Host zuweisen
Bei manchen Regeln ist es in den Optionen notwendig, eine IP-Adresse oder einen Host-Namen anzugeben. An vielen Stellen ist möglich diese Option leer zu lassen, so dass der Host-Name oder dessen IP genommen wird. Auf diese Weise können Sie sehr leicht mit nur einer Regel eine ganze Gruppe an Hosts mit einem aktiven Check versorgen. Achten Sie daher immer darauf (auch mit Hilfe der bereits erwähnten Inline-Hilfe), ob diese Möglichkeit in dem konkreten Regelsatz zur Verfügung steht. Sie sparen sich damit unter Umständen eine Menge Konfigurationsarbeit.
Check HTTP web service ist ein häufig benötigter Check zur Überwachung vieler Parameter von Webservern, wie Zertifikatsgültigkeit, Antwortzeit, Response Code oder der Suche nach Zeichenketten in ausgelieferten Webseiten. Sie finden ihn unter Networking > Check HTTP web service. Nehmen wir an, Sie möchten die Gültigkeit der Zertifikate sämtlicher Webserver in Ihrer Infrastruktur überwachen, Antwortzeiten von unter einer Sekunde und einen Statuscode 200 sicherstellen, dafür aber nicht Dutzende oder gar Hunderte Regeln anlegen:
 |
Warum existiert mit Check certificates ein weiterer aktiver Check für Zertifikate? Der vorgestellte Check Check HTTP web service führt immer einen vollständigen HTTP-Request durch, was seinen Einsatz auf Webserver beschränkt. Im Gegenzug ist seine Ausführung sehr effizient, er kann mit nur einem einzigen HTTP-Request eine Reihe von Prüfungen durchführen. Dagegen prüft Check certificates nur den TLS-Verbindungsaufbau und dabei die Zertifikate. Dieser Check kann folglich auch auf anderen mit TLS abgesicherten Diensten wie IMAP/S angewandt werden. Zudem kann er Zertifikate weit detaillierter untersuchen, beispielsweise auf bestimmte per Server Name Indication (SNI) hinterlegte Host-Namen. |
Um den eben konfigurierten Check mit einer einzigen Regel auf alle passenden Hosts anzuwenden, machen Sie sich zunächst Gedanken, wie Sie die Conditions am besten befüllen.
In dem nachfolgenden Beispiel nutzen wir dafür die Funktion der Labels und setzen auf alle unsere Webserver das Label webprotocol:https.
Mit solch einem Label können Sie eine Regel anlegen und die Conditions auf eben dieses Label setzen:
Nachdem Sie die eben erstellte Regel aktiviert haben, suchen Sie im Monitor-Menü nach dem soeben gesetzten Service-Namen Basic webserver health.
Im nachfolgenden Beispiel sehen Sie die Hosts bei denen das Label entsprechend gesetzt wurde.
Wichtig: Beachten Sie, dass bei den aktiven Checks nicht nur die erste Regel ausgewertet wird, auf welche die Bedingungen zutreffen, sondern vielmehr alle, für die die Bedingungen zu einem Host zutreffen. Nur so ist es möglich, mehrere aktive Services auf einem Host anzulegen.
2.3. Andere zu Nagios kompatible Plugins einbinden
In Checkmk stehen Ihnen natürlich nicht nur die aktiven Checks zur Verfügung, die Sie in der Weboberfläche als Regelsätze vorfinden. Über diese Check-Plugins hinaus, finden Sie noch viele weitere in Ihrer Instanz. Um die Übersicht zu wahren, werden in der folgenden Ausgabe nur ausgewählte Zeilen angezeigt:
OMD[mysite]:~$ ll ~/lib/nagios/plugins/
total 2466
-rwxr-xr-x 1 root root 56856 Feb 3 00:45 check_dig
-rwxr-xr-x 1 root root 6396 Feb 3 00:45 check_flexlm
-rwxr-xr-x 1 root root 6922 Feb 3 00:45 check_ircd
-rwxr-xr-x 1 root root 60984 Feb 3 00:45 check_ntp_peer
-rwxr-xr-x 1 root root 78136 Feb 3 00:45 check_snmpJedes dieser Check-Plugins bietet auch eine Hilfe-Option an (-h), über die Sie mehr zur Nutzung des jeweiligen Plugins erfahren können,
ohne die monitoring-plugins.org Website bemühen zu müssen.
Checkmk bietet dafür unter Setup > Services > Other services den speziellen Regelsatz Integrate Nagios plugins an, um diese Plugins bequem nutzen zu können. Die beiden wichtigsten Optionen sind hier die Angabe einer Service-Beschreibung und die Kommandozeile. Letztere kann so geschrieben werden, als würden Sie sich bereits im richtigen Verzeichnis befinden:
Beachten Sie, dass Ihnen hier auch die oben gezeigten Makros, wie $HOSTNAME$ oder $HOSTADDRESS$ zur Verfügung stehen.
Eine Liste von allen verfügbaren Makros finden Sie wie immer in der Inline-Hilfe.
Nachdem Sie die Änderungen aktiviert haben, können Sie den neuen Service auf dem zugeordneten Host sehen:
Eigene Plugins verwenden
In manchen Fällen haben Sie bereits eigene Plugins geschrieben und möchten diese nun in Checkmk verwenden.
In diesem Fall ist das Vorgehen weitgehend identisch.
Voraussetzung ist lediglich, dass das Plugin kompatibel zu Nagios ist.
Dazu gehört eine einzeilige Ausgabe mit den Details des Status und ein Exit-Code, welcher den Status beschreibt.
Dieser muss 0 für OK, 1 für WARN, 2 für CRIT oder 3 für UNKNOWN sein.
Ein kurzes Beispiel, um die sehr einfache Syntax zu veranschaulichen, zeigt das folgende Skript, dass Sie z.B. im Unterverzeichnis ~/tmp des Instanzverzeichnisses erstellen können:
#!/bin/bash
echo "I am a self written check and I feel well."
exit 0Legen Sie das Plugin in dem lokalen Pfad ihrer Instanz ab und machen Sie es in einem Rutsch ausführbar:
OMD[mysite]:~$ install -m755 ~/tmp/myscript.sh ~/local/lib/nagios/plugins/Das weitere Vorgehen ist dann identisch zu anderen Plugins, die über den Regelsatz Integrate Nagios plugins angelegt werden, so dass Sie am Ende den neuen Service sehen können:
3. Besonderheiten bei aktiven Checks
Services, welche durch aktive Checks erstellt wurden, verhalten sich in mancher Hinsicht anders, als andere Services. So wird der Service eines aktiven Checks…
… auch dann weiter geprüft, wenn ein Host DOWN ist.
… unabhängig von anderen (passiven) Services ausgeführt. Das ermöglicht auch das Setzen eines eigenen Intervalls.
… immer vom Checkmk-Server ausgeführt. Ausnahmen sind hier MRPEs, welche direkt auf einem Host ausgeführt werden.
… nicht über die Service-Erkennung aufgenommen, sondern automatisch erzeugt.
4. Aktive Checks auf einem Host ausführen (MRPE)
Angenommen, Sie überwachen von Ihrer Checkmk-Instanz einen Host A (bspw. einen Webserver), der wiederum auf Dienste von Host B (bspw. eine Datenbank) zurückgreift. Eine Überwachung der Services auf Host B direkt von der Checkmk-Instanz aus wird sehr wahrscheinlich durch andere Paketlaufzeiten etc. verfälscht werden und daher keine Aussage darüber treffen, wie sich die Erreichbarkeit in der Praxis von Host A verhält. Hier ist es praktisch, ein Nagios-Plugin vom Agenten des überwachten Hosts (hier A) ausführen zu lassen, welches direkt die Dienste auf Host B überprüft.
Hierfür stellen wir MK’s Remote Plugin Executor (kurz: MRPE) zur Verfügung. Je nachdem, ob Sie ein solches Plugin auf einem Unix-artigen System oder auf einem Windows System ausführen wollen, legen Sie es an unterschiedlichen Stellen im Installationsverzeichnis des jeweiligen Agenten ab. Zusätzlich benötigen Sie noch eine Konfigurationsdatei, welche bestimmt, in welcher Art und Weise das Plugin ausgeführt werden soll und wie die konkrete Kommandozeile für den Aufruf aussieht.
5. Dateien und Verzeichnisse
| Pfad | Bedeutung |
|---|---|
|
Hier finden Sie alle Plugins, welche mit Checkmk mitgeliefert werden. Es wird dabei keine Unterscheidung zwischen Plugins gemacht, welche von monitoring-plugins.org und welche speziell für Checkmk geschrieben wurden. |
|
Eigene Plugins legen Sie hier ab. Sie werden dann dynamisch eingelesen und überstehen auch ein Update der Checkmk-Instanz. |