Lokale Checks

Check_MK Manual
Letzte Aktualisierung: 24. Oktober 2017

Suche im Handbuch

1. Warum eigene Checks?

Check_MK überwacht durch die große Anzahl an mitgelieferten Checkplugins bereits sehr viele relevante Daten. Dennoch ist jede IT-Umgebung einzigartig, so dass sich oft sehr individuelle Anforderungen ergeben. Mit den local-Checks sind Sie in der Lage, schnell und einfach eigene Services zu erstellen, um diesen Anforderungen gerecht zu werden.

Diese local-Checkplugins unterscheiden sich dabei in einem wesentlichen Punkt von anderen Checks: Die Berechnung des Status erfolgt direkt auf dem Host, auf dem die Daten auch abgerufen werden. Dadurch entfällt die komplexe Erstellung von Checks in Python und Sie sind bei der Wahl der Skriptsprache völlig frei.

2. Einfache Checks selbst schreiben

2.1. Syntax der Ausgabe

Die können einen lokalen Check in jeder beliebigen Programmiersprache schreiben, die der Zielhost unterstützt. Das Skript muss so konstruiert sein, dass es pro Check eine Statuszeile ausgibt, die aus vier Teilen besteht. Hier ist ein Beispiel:

0      myservice   myvalue=73;80;90  My output text who may contain spaces

Die vier Teile sind durch Leerzeichen getrennt und haben folgende Bedeutung:

1. Status Der Status des Services wird als Ziffer angegeben: 0 für OK, 1 für WARN, 2 für CRIT und 3 für UNKNOWN.
2. Servicename Der Servicename, wie er in Check_MK angezeigt wird. Er darf keine Leerzeichen enthalten.
3. Metriken Performancewerte zu den Daten. Sie finden weiter unten näheres zu dem Aufbau. Alternativ können Sie Minuszeichen setzen, wenn der Check keine Metriken ausgibt.
4. Statusdetail Details zu den Status, wie sie in Check_MK angezeigt werden. Dieser Teil kann auch Leerzeichen enthalten.

Zwischen den einzelnen Teilen der Ausgabe und dem ersten Text des Statusdetails muss immer ein Leerzeichen stehen. Alles danach wird dann zum Statusdetail gezählt, weswegen dort auch Leerzeichen erlaubt sind.

Wenn Sie wegen einer möglichen Ausgabe unsicher sind, können Sie diese einfach testen, indem Sie ein kleines Skript mit dem Kommando echo schreiben. Fügen Sie hier Ihre Ausgabe ein, die Sie testen möchten:

mylocalcheck
#!/bin/sh
echo "0 myservice - OK: This is my custom output"

Für Windows-Hosts sieht so ein Testskript sehr ähnlich aus:

mylocalcheck.bat
@echo off
echo 0 myservice - OK: This is my custom output

Sie können übrigens beliebig viele Ausgaben in einem Skript erzeugen. Für jede ausgegebene Zeile wird dann ein eigener Service erstellt. Wie Sie prüfen, ob das local-Skript vom Agenten richtig aufgerufen wird, sehen Sie in der Fehleranalyse.

2.2. Skript verteilen

Nachdem das Skript geschrieben ist, können Sie es an die entsprechenden Hosts verteilen. Der Pfad unterscheidet sich je nach Betriebssystem. Eine Liste der Pfade ist weiter unten zu finden.

Vergessen Sie nicht, das Skript auf unixoiden Systemen ausführbar zu machen. Der Pfad in dem Beispiel bezieht sich auf Linux:

root@linux# chmod +x /usr/lib/check_mk_agent/local/mylocalcheck

Wenn Sie die Agent Bakery nutzen, können Sie das Skript auch regelbasiert verteilen. Mehr zu der Regelerstellung erfahren Sie in dem Kapitel Verteilung über Agent Bakery.

2.3. Services hinzufügen

Bei jedem Aufruf des Check_MK-Agenten wird auch der local-Check ausgeführt und an die Ausgabe des Agenten angehängt. Die Serviceerkennung funktioniert also wie bei anderen Services auch automatisch:

Nachdem Sie die Änderungen aktiviert haben, ist die Einrichtung eines selbsterstellten Services mit Hilfe eines local-Checks bereits abgeschlossen. Falls es bei der Serviceerkennung zu Problemen kommen sollte, kann Ihnen die Fehleranalyse weiter unten helfen.

3. Erweiterte Funktionen

3.1. Metriken verwenden

Sie können in einem einfachen local-Skript auch Metriken übergeben. Die Syntax für diese Daten ist:

metricname=value;warn;crit;min;max
count=73;80;90;0;100

Die Werte werden mit einem Semikolon getrennt. Wird ein Wert nicht benötigt, so wird das Feld leer gelassen:

count=42;;90

Beachten Sie, dass die Werte für min und max in der  Check_MK Enterprise Edition nur aus Kompatibilitätsgründen gesetzt werden können, aber keine Auswirkungen haben. Die Begrenzung des Graphen auf einen bestimmten Wertebereich hat in dieser Version keine Auswirkungen.

Prinzipiell sind alle Werte bis auf den Wert value selbst optional und können ausgelassen werden.

Mehrere Metriken

Sie können in einem local-Check auch mehrere Metriken ausgeben lassen. Diese werden hierbei durch eine | (Pipe) getrennt:

count1=42|count2=21;23;27|count3=73

Eine komplette Ausgabe mit mehreren Metriken sieht dann etwa so aus:

root@linux# /usr/lib/check_mk_agent/local/mycustomscript
0 myservice count1=42|count2=21;23;27|count3=73 OK - This is my custom output

Die Graphen werden in Check_MK nun automatisch erzeugt:

3.2. Mehrzeilige Ausgaben

Auch die Option, die Ausgabe über mehrere Zeilen zu verteilen, steht Ihnen zur Verfügung. Da Check_MK unter Linux läuft, können Sie mit der Escape-Sequenz \n arbeiten, um einen Zeilenumbruch zu erzwingen. Auch wenn Sie bedingt durch die Skriptsprache den Backslash selbst maskieren müssen, wird das von Check_MK korrekt interpretiert:

root@linux# /usr/lib/check_mk_agent/local/mycustomscript
2 myservice - CRIT - This is my custom output\\nThis is some detailed information\\nAnd another line with details

In den Details des Services können Sie dann diese zusätzlichen Zeilen sehen:

3.3. Ausgaben cachen

Local-Checks können, wie auch normale Plugins, gecached werden. Das kann notwendig werden, wenn Skripten längere Zeit zur Ausführung benötigen. Sie werden dann nur in einem definierten Intervall ausgeführt und zwischengespeichert. Dieser Cache wird dann der Agentenausgabe angehängt. Unter Linux oder einem anderen unixoiden Betriebssystem kann übrigens auch jedes gecachte Plugin asynchron ausgeführt werden. Legen Sie dazu ein Unterverzeichnis an, dessen Name die Anzahl der Sekunden ist, wie lange die Ausgabe des Local-Checks gecached werden soll. In dem Beispiel wird der local-Check z. B. nur alle 10 Minuten (600 Sekunden) ausgeführt:

root@linux# /usr/lib/check_mk_agent/local/600/mylocalcheck
1 myservice count=4 WARN - Some output of a long time running script

Unter Windows wird ein local-Check genauso behandelt wie ein anderes Plugin auch: Sie geben das cache_age für den local-Check in der check_mk.ini an:

check_mk.ini
[local]
    cache_age mylocalcheck = 3600

Alternativ können Sie das Caching unter Windows auch in der Agent Bakery konfigurieren.

Wichtig: Beachten Sie, dass das Caching nur für Windows, Linux, Solaris, AIX und FreeBSD zur Verfügung steht.

3.4. Status dynamisch berechnen

Wie Sie weiter oben gelesen haben, können Sie bei den Metriken auch die Schwellwerte in den Graphen anzeigen lassen. Diese Schwellwerte könnte man doch auch für eine dynamische Berechnung des Servicestatus benutzen! Check_MK bietet genau diese Möglichkeit, um einen local-Check auszubauen.

Wenn Sie statt einer Zahl den Buchstaben "P" übergeben, wird der Status des Services anhand der übergebenen Schwellwerte berechnet. Eine Ausgabe würde dann so aussehen:

root@linux# /usr/lib/check_mk_agent/local/mycustomscript
P myservice count=40;30;50 Result is computed from two values
P myservice2 - Result is computed with no values

Die Ausgabe in Check_MK unterscheidet sich in ein zwei Punkten von der Ausgabe, wie sie weiter oben zu sehen war:

  • Die einzelnen Metriken werden der Ausgabe, wie sie in den Views zu sehen ist, kommasepariert angehängt. So sehen Sie immer, welcher Status zu einem ein Wert berechnet wurde.
  • Wenn keine Metriken übergeben werden, ist der Status des Services immer OK.

Hier die Ausgabe der oben gezeigten Beispiele in einer Serviceansicht:

Obere und untere Schwellwerte

Manche Daten haben nicht nur obere Grenzwerte, sondern auch untere. Ein Beispiel dafür ist die Luftfeuchtigkeit. Für solche Fälle bietet der local-Check die Möglichkeit, zwei WARN-/CRIT-Werte zu übergeben. Sie werden durch einen Doppelpunkt getrennt und stellen jeweils den unteren und den oberen Schwellwert dar:

valuename=value;warn_lower:warn_upper;crit_lower:crit_upper
humidity=27;40:60;30:70

4. Verteilung über die Agent Bakery

Wenn Sie einen local-Check an mehrere Hosts verteilen möchten oder die Agent Bakery bereits nutzen, können Sie die Skripten auch hierüber verteilen. Legen Sie dazu auf dem Check_MK-Server als Instanzbenutzer unterhalb von ~/local/share/check_mk/agents/ das Verzeichnis custom an. In diesem Verzeichnis wird für jede local-Checks-Gruppe ein Unterverzeichnis erstellt:

OMD[mysite]:~$ cd ~/local/share/check_mk/agents
OMD[mysite]:~/local/share/check_mk/agents$ mkdir -p custom/mycustomgroup/lib/local/

Das lib-Verzeichnis markiert das Skript als Plugin oder local-Check. Das nachfolgende Verzeichnis ordnet die Datei dann eindeutig zu. In dieses Verzeichnis können Sie dann auch den local-Check ablegen.

Wichtig: Unter Linux können Sie ebenfalls die asynchrone Ausführung nutzen, wie Sie sie von den Plugins kennen. Unter Windows werden die Einstellungen wie gehabt in der check_mk.ini hinterlegt.

In WATO wird dann mycustomgroup als Option angezeigt. Erstellen Sie in WATO über Host & Service Parameters ➳ Monitoring Agents ➳ Generic Options ➳ Deploy custom files with agent eine neue Regel und wählen Sie die eben erstellte Gruppe aus:

Check_MK wird nun selbstständig den local-Check im Installationspaket der jeweiligen Betriebssysteme richtig einordnen. Nachdem Sie die Änderungen aktiviert und die Agenten gebacken haben, sind Sie mit der Konfiguration auch schon fertig. Die Agenten müssen nun nur noch neu verteilt werden.

5. Fehleranalyse

5.1. Skript testen

Wenn Sie bei einem selbstgeschriebenen Skript auf Probleme stoßen, können Sie die folgenden potentiellen Fehlerquellen prüfen:

  • Ist das Skript ausführbar und stimmen die Zugriffsberechtigungen? Das ist vor allem relevant, wenn Sie den Agenten oder das Skript nicht als root/System-Benutzer ausführen.
  • Ist die Ausgabe konform zu der vorgegebenen Syntax?
  • Liegt das Skript in dem richtigen Verzeichnis?

5.2. Ausgabe des Agenten testen

Auf dem Zielhost

Wenn das Skript selbst korrekt ist, können Sie den Agenten auf dem Host ausführen. Bei unixoiden Betriebssystemen, wie Linux, BSD und so weiter, bietet sich folgender Befehl an. Mit der Option -A bestimmen Sie die Anzahl der zusätzlichen Zeilen, die nach einem Treffer angezeigt werden sollen. Sie können diese Zahl entsprechend der Anzahl der erwarteten Ausgaben anpassen:

root@linux# check_mk_agent | grep -v grep | grep -A 3 "<<<local>>>"
<<<local>>>
0 myservice count1=42|count2=21;23;27|count3=73 OK - This is my custom output
P myservice2 - Result is computed with no values
P myservice3 humidity=27;40:60;30:70 Result has upper and lower thresholds

Unter Windows können Sie die Ausgabe auf eine Textdatei umleiten, diese dann z. B. mit Notepad ebenfalls nach der local-Sektion durchsuchen und schauen, ob die erwarteten Ausgaben dabei sind. Ersetzen Sie gegebenenfalls den Pfad unten durch Ihren Installationspfad, unter dem Sie Check_MK installiert haben:

C:\Program Files (x86)\check_mk\> check_mk_agent.exe test > out.txt

Auf dem Check_MK-Server

Zuletzt können Sie die Verarbeitung der Skriptausgaben auch auf dem Check_MK-Server testen. Einmal für die Serviceerkennung:

OMD[mysite]:~$ cmk -IIv --debug --checks=local myserver123
Discovering services on myserver123:
myserver123:
    3 local

Und mit einem ähnlichen Befehl auch die Verarbeitung der Serviceausgabe:

OMD[mysite]:~$  cmk -nv --debug --checks=local myserver123
Check_MK version 1.4.0p15
myservice            OK - This is my custom output
myservice2           OK - Result is computed with no values
myservice3           CRIT - Result has upper and lower thresholds, humidity 27.0 < 30.0 (!!)

Wenn es in den local-Checks Fehler gibt, wird Check_MK Sie in der Serviceausgabe darauf hinweisen. Das gilt für fehlerhafte Metriken, falsche, unvollständige Informationen in der Skriptausgabe oder einen ungültigen Status. Diese Fehlermeldungen sollen Ihnen helfen, die Fehler in den Skripten schnell zu identifizieren.

6. Dateien und Verzeichnisse

6.1. Skriptverzeichnisse auf dem Host

Pfad Betriebssystem
/usr/check_mk/lib/local/ AIX
/usr/local/lib/check_mk_agent/local/ FreeBSD
/omd/versions/0.45.20110123/lib/check_mk_agent/local/ HP-UX
/usr/lib/check_mk_agent/local/ Linux, Solaris, OpenBSD und OpenWRT
%PROGRAMFILES(X86)%\check_mk\local Windows

6.2. Cacheverzeichnisse auf dem Host

Pfad Betriebssystem
/tmp/check_mk/cache/ AIX
/var/run/check_mk/cache/ FreeBSD
/var/lib/check_mk_agent/cache/ Linux und Solaris