Datenquellenprogramme


1. Einleitung

Check_MK erreicht seine Agenten üblicherweise über eine einfache TCP-Verbindung auf Port 6556. Das „Protokoll“ ist trivial: Sobald der Server die Verbindung öffnet, sendet der Agent seine Daten und schließt den Port wieder. Die übertragenen Daten sind lesbarer ASCII-Text. Letztendlich geschieht hier nichts anderes, als dass eine Textdatei vom Agenten zum Server übertragen wird.

Dieses radikal einfache Prinzip ermöglicht die verrücktesten Abwandlungen, mit denen Sie auch sehr ausgefallene Anforderungen erfüllen können. Wie z. B. solche, die sich aus speziellen Architekturen für Sicherheit oder Netzwerk ergeben. Eine Spielart davon – die Übertragung der Daten über SSH – wird im Artikel über den Linux-Agenten beschrieben. Hier sind einige weitere Beispiele, wie man die Daten der Agenten zum Check_MK-Server bekommen kann:

  • per Email
  • per HTTP-Zugriff vom Server aus
  • per HTTP-Upload vom Agenten aus
  • per Zugriff auf eine Datei, die per rsync zum Server kopiert wurde
  • per Skript, welches die Daten per HTTP von einem Webservice abholt

Die universelle Methode, um solche Transportwege an Check_MK anzudocken, sind die Datasource programs (Datenquellenprogramme). Die Idee ist sehr einfach: Sie geben Check_MK die Kommandozeile eines Befehls. Anstelle des Connects auf Port 6556 führt Check_MK diesen Befehl aus. Dieser produziert die Agentendaten auf der Standardausgabe, welche dann von Check_MK genauso verarbeitet werden, als kämen sie von einem „normalen“ Agenten.

2. Schreiben von Datenquellenprogrammen

2.1. Das einfachst mögliche Programm

Das Schreiben und Einbinden eines eigenen Datenquellenprogramms ist nicht schwer. Sie können jede von Linux unterstützte Skript- und Programmiersprache verwenden. Legen Sie das Programm am besten im Verzeichnis local/bin an, dann wird es immer automatisch ohne Pfadangabe gefunden.

Folgendes erstes minimales Beispiel heißt myds und erzeugt einfache fiktive Monitoringdaten. Diese enthalten als einzige Sektion <<<df>>> mit der Information zu einem einzigen Dateisystem der Größe 100kB und dem Namen My_Disk. Das Ganze ist ein Shellskript mit drei Zeilen:

local/bin/myds
#!/bin/sh
echo '<<<df>>>'
echo 'My_Disk  foobar  100 70 30  70% /my_disk'

Vergessen Sie nicht, Ihr Programm ausführbar zu machen:

OMD[mysite]:~$ chmod +x local/bin/myds

Legen Sie nun in WATO zum Test einen Host an --z. B. myserver125. Dieser benötigt keine IP-Adresse. Um zu verhindern, dass Check_MK den Namen myserver125 per DNS aufzulösen versucht, tragen Sie diesen Namen als explizite „IP-Adresse“ ein.

Legen Sie dann eine Regel im Regelsatz Datasource Programs ➳ Individual program call instead of agent access an, welche für diesen Host gilt und tragen Sie myds als aufzurufendes Programm ein:

Wenn Sie jetzt in WATO zur Servicekonfiguration des Hosts gehen, sollten Sie genau einen Service sehen, der für die Überwachung bereitsteht:

Nehmen Sie diesen in die Überwachung auf, aktivieren Sie die Änderungen und Ihr erstes Datenquellenprogramm läuft. Sobald Sie jetzt testweise die Daten ändern, die das Programm auswirft, wird das der nächste Check des Dateisystems My_Disk sofort anzeigen.

2.2. Fehlerdiagnose

Wenn etwas nicht funktioniert, können Sie auf der Kommandozeile mit cmk -D die Konfiguration des Hosts überprüfen (ob Ihre Regel greift):

OMD[mysite]:~$ cmk -D myserver125

myserver125
Addresses:              myserver125
Tags:                   /wato/, cmk-agent, ip-v4, ip-v4-only, lan, prod, site:beta, tcp, wato
Host groups:
Contact groups:         all
Type of agent:          Datasource program: myds

Mit einem cmk -d können Sie den Abruf der Agentendaten – und damit das Ausführen Ihres Programms – auslösen:

OMD[mysite]:~$ cmk -d myserver125
<<<df>>>
My_Disk  foobar  100 70 30  70% /my_disk

Ein doppeltes -v sollte eine Meldung erzeugen, dass Ihr Programm aufgerufen wird:

OMD[mysite]:~$ cmk -vvd myserver125
Calling external program myds
<<<df>>>
My_Disk  foobar  100 70 30  70% /my_disk

2.3. Übergeben des Hostnamens

Das Programm aus dem ersten Beispiel funktioniert zwar, ist aber nicht sehr praxistauglich, denn es gibt immer die gleichen Daten aus, egal für welchen Host es aufgerufen wird.

Ein echtes Programm, dass z. B. per HTTP von irgendwoher Daten holt, benötigt dazu zumindest den Namen des Hosts, für den Daten geholt werden sollen. Sie können diesen in der Kommandozeile mit dem Platzhalter $HOSTNAME$ übergeben lassen:

In diesem Beispiel bekommt das Programm myds den Hostnamen als erstes Argument geliefert. Folgendes Beispielprogramm gibt diesen zum Testen in Form eines „Localchecks“ aus. Es greift per $1 auf das erste Argument zu und speichert es zum Zwecke der Übersicht in der Variable $HOST_NAME. Diese wird dann in die Pluginausgabe des Localchecks eingesetzt:

local/bin/myds
#!/bin/sh
HOST_NAME=$1

echo "<<<local>>>"
echo "0 Hostname - My name is $HOST_NAME"

Die Serviceerkennung wird jetzt einen neuen Service vom Typ local finden, in dessen Ausgabe der Hostname zu sehen ist:

Der Schritt zu einem echten Datenquellenprogramm, das z. B. Daten per HTTP mit dem Befehl curl holt, ist jetzt nicht mehr weit. Folgende Platzhalter sind in der Befehlszeile der Datenquellenprogramme erlaubt:

$HOSTNAME$ Der Hostname, wie er in WATO konfiguriert ist.
$$HOSTADDRESS$ Diejenige IP-Adresse des Hosts, über die er überwacht wird
$_HOSTTAGS$ Die Liste aller Hostmerkmale durch Leerzeichen getrennt. Setzen Sie dieses Argument auf jeden Fall in Anführungszeichen, um es vor einem Aufteilen durch die Shell zu schützen.

Falls Sie den Host dual per IPv4 und IPv6 überwachen, sind unter Umständen noch folgende Makros für Sie interessant:

$$_HOSTADDRESS_4$ Die IPv4-Adresse des Hosts
$$_HOSTADDRESS_6$ Die IPv6-Adresse des Hosts
$_HOSTADDRESS_FAMILY$ Die Ziffer 4, wenn die zur Überwachung genutzte Adresse die IPv4-Adresse ist, ansonsten 6.

2.4. Fehlerbehandlung

Egal welchen Beruf Sie in der IT ausüben – den meisten Teil Ihrer Zeit werden Sie sich mit Fehlern und Problemen befassen. Und auch Datenquellenprogramme bleiben davon nicht verschont. Vor allem bei Programmen, die per Netzwerk Daten beschaffen, ist ein Fehler keineswegs unrealistisch.

Damit Ihr Programm Check_MK so einen Fehler sauber mitteilen kann, gilt Folgendes:

  1. Jeder Exitcode außer 0 wird als Fehler gewertet.
  2. Fehlermeldungen werden auf dem Standardfehlerkanal (stderr) erwartet.

Falls ein Datenquellenprogramm scheitert,

  • verwirft Check_MK die kompletten Nutzdaten der Ausgabe,
  • setzt den Check_MK-Service auf CRIT und zeigt dort die Daten von stderr als Fehler an,
  • bleiben die eigentlichen Services auf dem alten Stand (und werden mit der Zeit veralten).

Sie können das Beispiel von oben so modifizieren, dass es einen Fehler simuliert. Mit der Umleitung >&2 wird der Text auf stderr gelenkt. Und exit 1 setzt den Exitstatus des Programms auf 1:

local/bin/myds
#!/bin/sh
HOST_NAME=$1

echo "<<<local>>>"
echo "0 Hostname - My name is $HOST_NAME"

echo "This didn't work out" >&2
exit 1

Im Check_MK-Service sieht dies dann so aus:

Falls Sie Ihr Programm als Shellskript schreiben, können Sie gleich am Anfang die Option set -e verwenden:

local/bin/myds
#!/bin/sh
set -e

Sobald ein Befehl fehlschlägt (Exitcode ungleich 0), bricht die Shell sofort ab und beendet das Skript mit dem Exitcode 1. Damit haben Sie eine generische Fehlerbehandlung und müssen nicht bei jedem einzelnen Befehl auf Erfolg prüfen.

3. Spezialagenten

Einige häufig benötigte Datenquellenprogramme werden von Check_MK mitgeliefert. Diese erzeugen Agentenausgaben nicht durch den Abruf eines normalen Check_MK-Agenten auf irgendwelchen krummen Wegen, sondern sind für die Abfrage von bestimmter Hardware oder Software konzipiert.

Weil diese Programme teilweise recht komplexe Parameter benötigen, haben wir dafür spezielle WATO-Regelsätze definiert, mit denen Sie diese direkt konfigurieren können. Alle diese Regeln finden Sie unter Host- & Serviceparamters ➳ Datasource programs:

Diese Programme heißen auch „Spezialagenten“, weil sie eben ein spezieller Ersatz für den normalen Check_MK-Agenten sind. Nehmen Sie als Beispiel die Überwachung von NetApp-Filern. Diese lassen die Installation eines Check_MK-Agenten nicht zu. Die SNMP-Schnittstelle ist langsam, fehlerhaft und unvollständig. Aber es gibt eine spezielle HTTP-Schnittstelle, welche Zugriff auf alle Überwachungsdaten liefert.

Der Spezialagent agent_netapp greift über diese Schnittstelle zu und wird über den Regelsatz Check NetApp via WebAPI als Datenquellenprogramm eingerichtet. Wichtig ist, dass Sie den Host im WATO auf der Einstellung Check_MK Agent (Server) belassen.

Im Inhalt der Regel können Sie dann die Daten eingeben, die der Spezialagent braucht. Fast immer sind das irgendwelche Zugangsdaten. Beim NetApp-Agenten gibt es noch eine zusätzliche Checkbox für das Erfassen von Messdaten (die hier recht umfangreich werden können):

Es gibt seltene Situationen, in denen Sie sowohl einen Spezialagenten als auch den normalen Agenten abfragen möchten. Ein Beispiel dafür ist die Überwachung von VMWare ESXi über das vCenter. Letzteres ist auf einer (meist virtuellen) Windows-Maschine installiert, auf welcher sinnvollerweise auch ein Check_MK-Agent läuft.

Die Spezialagenten sind unter share/check_mk/agents/special installiert. Wenn Sie eine Modifikation an einem solchen Agenten machen möchten, dann kopieren Sie die Datei mit dem gleichen Namen nach local/share/check_mk/agents/special und ändern Sie sie dort.

4. Dateien und Verzeichnisse

Pfad Bedeutung
local/bin/ Ablage von eigenen Programm oder Skripten, die im Suchpfad sein sollen und ohne Pfadangabe direkt ausgeführt werden können. Ist ein Programm sowohl in bin/ als auch in local/bin/, hat letzteres Vorrang.
share/check_mk/agents/special Hier sind die mitgelieferten Spezialagenten installiert.
local/share/check_mk/agents/special Ablage von von Ihnen modifizierten Spezialagenten.