1. Einleitung
Mit über 2000 mitgelieferten Check-Plugins und vielfältigen Methoden für die Überwachung von Dateien und Ordnerinhalten, die Auswertung von Log-Meldungen sowie die Überwachung wiederkehrender Aufgaben hat Checkmk für eine Fülle von Monitoring-Aufgaben die passende Out-of-the-Box-Lösung. Und wo es die nicht gibt, hilft die Community gerne mit in der Checkmk Exchange bereitgestellten Eigenentwicklungen.
Dennoch kommt es immer wieder vor, dass eine Hardware zu neu ist, eine Software zu exotisch oder eine firmeninterne Eigenentwicklung zu individuell, als dass schon jemand Bedarf für die Integration in Checkmk gesehen hätte. Sind Sie an diesem Punkt angelangt, ist es an der Zeit, sich mit der Programmierung eigener Erweiterungen zu befassen.
Dieser Artikel zeigt eine Übersicht der zur Verfügung stehenden Möglichkeiten.
Und die sind vielfältig: In manchen Fällen genügt es beispielsweise, ein Backup-Skript um wenige Zeilen zu erweitern, um Erfolg oder Misserfolg in einer gut in Checkmk darstellbaren Form auszugeben – damit ist die „Eigenentwicklung“ mitunter in wenigen Minuten abgeschlossen. In anderen Fällen werden Sie darauf angewiesen sein, mit umfangreichen Graphen Lastsituationen zu visualisieren – dann lohnt es sich auch, einige Stunden mehr zu investieren.
2. Erweiterungsmöglichkeiten mit eigenen Programmen
Die folgenden Abschnitte zeigen, welche Verfahren in Checkmk möglich sind, eigene Erweiterungen zu integrieren, und wo dabei jeweils die Datenerhebung und die Auswertung erfolgt.
2.1. Lokale Checks
Die wahrscheinlich einfachste Art und Weise, Checkmk zu erweitern, sind lokale Checks. Ein Programm, welches vom Agentenskript des überwachten Hosts ausgeführt wird, gibt in einer Zeile Namen, Zustand und weitere Informationen aus. Für lokale Checks unterstützt Checkmk die automatische Service-Erkennung. Die Programmierung ist in beliebigen Sprachen möglich, ohne eine API erlernen zu müssen.
Ausführung: Vollständig auf dem überwachten Host. Sie müssen selbst sicherstellen, dass gegebenenfalls auf allen Hosts, die einen lokalen Check erhalten, der passende Interpreter verfügbar ist.
Schwellwerte: Ein Paar von unteren und von oberen Schwellwerten (für die Übergänge nach WARN respektive CRIT) kann von der Checkmk-Instanz verwaltet werden.
Metriken: Mehrere Metriken pro Service sind möglich. Einheiten können nicht explizit verwaltet werden, diese werden automatisch zugewiesen oder weggelassen.
2.2. Native agentenbasierte Check-Plugins
Die agentenbasierten Check-Plugins werten vom Checkmk-Agenten gelieferte Daten aus. Ein Agentenplugin sammelt Rohdaten und filtert diese vor, führt aber keine Bewertung der erhobenen Daten durch. Diese Datensammlung kann in beliebigen Programmiersprachen erfolgen. Sehr verbreitet ist die Ausgabe als JSON-Datei oder im CSV-Format. Sie werden aber auch viele Agentenplugins sehen, die nur rohe Linux-Systembefehle aufrufen.
Auf dem Checkmk-Server findet dann die Auswertung durch ein in Python geschriebenes Check-Plugin statt, welches APIs von Checkmk nutzt. Die Ermittlung des Zustands kann dabei sehr flexibel erfolgen. So ist die Verwendung unterer und oberer Schwellwerte möglich. Zudem können mehrere Services erzeugt und der Status eines Services durch mehrere Überprüfungen bestimmt werden. Des Weiteren ist die Ermittlung von Trends und Einbeziehung älterer Werte möglich. Native Check-Plugins unterstützen die automatische Erstellung von Labels und die HW/SW-Inventur.
Ausführung: Agentenplugin zur Datensammlung in beliebiger Programmiersprache auf dem überwachten Host, weitere Auswertung durch Check-Plugin auf dem Checkmk-Server unter Verwendung der Check-API.
Schwellwerte: Beliebige Kombination von Schwellwerten für jeden Service.
Metriken: Beliebig viele Metriken pro Service mit Einheiten.
2.3. Spezialagenten
Eine Erweiterung der agentenbasierten Check-Plugins sind Spezialagenten: Hier sammelt kein Agentenplugin die Rohdaten ein, sondern ein Programm, das auf dem Checkmk-Server läuft und Daten aus einer anderen Quelle abfragt und in das Agentenformat von Checkmk umwandelt. Spezialagenten kommen beispielsweise zum Einsatz, wenn ein zu überwachendes Gerät fürs Monitoring relevante Daten als JSON oder XML über eine REST-API bereitstellt. Beispiele für den Einsatz von bei Checkmk mitgelieferten Spezialagenten finden Sie in der Überwachung von AWS, Azure oder VMware.
Bei der Programmierung greifen Sie auf zwei APIs zu: Für die Konfiguration von Ports oder ähnlichem stellt Checkmk eine API bereit, die erlaubt, solche Einstellungen im Setup zu bestimmen. Für die Datenabfrage selbst verwenden Sie die REST-API der externen Quelle. Die Auswertung auf dem Checkmk-Server erfolgt so, wie im vorherigen Abschnitt zu nativen Check-Plugins beschrieben.
Ausführung: Programm/Skript zur Datensammlung und weiteren Auswertung auf dem Checkmk-Server.
Schwellwerte: Beliebige Kombination von Schwellwerten für jeden Service.
Metriken: Beliebig viele Metriken pro Service mit Einheiten.
2.4. Native SNMP-basierte Check-Plugins
Eine Variante der agentenbasierten Check-Plugins sind die Check-Plugins für SNMP. Der Unterschied besteht hier darin, dass keine Agentensektion angefordert und ausgewertet wird, sondern bestimmte SNMP-OIDs, die explizit vom SNMP-Agenten angefordert werden.
Ausführung: Datensammlung und weitere Auswertung durch Check-Plugin auf dem Checkmk-Server unter Verwendung der Check-API.
Schwellwerte: Beliebige Kombination von Schwellwerten für jeden Service.
Metriken: Beliebig viele Metriken pro Service mit Einheiten.
Da das SNMP-Protokoll inhärent sehr ineffizient ist, raten wir, SNMP nur dann zu verwenden, wenn kein anderer Zugriff auf die Monitoring-Daten möglich ist. Stellt ein Gerät beispielsweise dieselben Daten auch über eine REST-API zur Verfügung, sollten Sie dafür einen Spezialagenten bauen.
2.5. Legacy-Nagios-Check-Plugins
An zwei Stellen in Checkmk finden Sie Nagios-Check-Plugins: Als aktive Checks, um vom Checkmk-Server aus die Erreichbarkeit bestimmter Services zu prüfen. Und als MRPE-Erweiterung der Windows- oder Linux-Agenten, um solche Services von einem Host aus prüfen zu lassen - falls sie vom Checkmk-Server nicht erreichbar sind.
Die Programmierung ist in beliebigen Sprachen möglich.
Ausführung: Vollständig auf dem überwachten Host (via MRPE) oder vollständig auf dem Checkmk-Server (aktiver Check).
Schwellwerte: Schwellwerte nur bei Verwendung als aktiver Check.
Metriken: Metriken nur bei Verwendung als aktiver Check.
Wegen diverser Nachteile wie umständlicher Fehlersuche empfehlen wir die Neuimplementierung nur, wenn vollumfängliche Kompatibilität zu Nagios erforderlich ist. Verwenden Sie in allen anderen Fällen native Check-Plugins oder – bei einfachen Überprüfungen – lokale Checks. Eine ausführliche Dokumentation der Ausgabeformate finden Sie auf Monitoring-Plugins.org.
3. Ergänzende Artikel
3.1. Das Spool-Verzeichnis
Checkmk stellt noch einen weiteren Mechanismus bereit, wie Agentendaten erzeugt werden können: Lassen Sie ein Programm direkt eine Textdatei im Checkmk-Agentenformat schreiben. Im Spool-Verzeichnis abgelegt überträgt der Checkmk-Agent den Inhalt dieser Datei mit der restlichen Agentenausgabe.
Mit dem Spool-Verzeichnis können Sie beispielsweise Backup-Skripte direkt bei Beendigung Status und Statistik für einen lokalen Check oder ein Check-Plugin schreiben lassen. Dies erspart Umwege über die Auswertung von Log-Dateien.
Bei der Entwicklung eigener Check-Plugins helfen Spool-Dateien, bestimmte Ausgaben Ihres Agentenplugins zu simulieren.
3.2. Der Piggyback-Mechanismus
Der Piggyback-Mechanismus kommt dann zum Einsatz, wenn ein Host etwas über einen anderen weiß. Eine speziell formatierte Agentensektion wird dann beim Auswerten der Agentenausgabe dem betreffenden Host zugeordnet.
Bei virtuellen Maschinen wird der Piggyback-Mechanismus genutzt, um von der Virtualisierungssoftware erhobene Daten mit den Daten aus dem Monitoring von innerhalb der virtuellen Maschine zusammenzuführen.
3.3. Checkmk-Erweiterungspakete (MKPs)
Wenn Sie eigene Erweiterungen programmiert haben und diese versionieren und schließlich weitergeben wollen, haben Sie die Möglichkeit, zusammengehörige Dateien in Checkmk-Erweiterungspaketen (MKPs) zu bündeln. Dieses Paketformat müssen Sie auch nutzen, wenn Sie diese Erweiterungen in der Checkmk Exchange anbieten wollen.
3.4. Die Bakery-API
In vielen Fällen werden Sie Agentenplugins mit zusätzlicher Konfiguration versehen wollen. Oder Sie möchten in Abhängigkeit von im Setup von Checkmk vorgenommenen Einstellungen bestimmte Installations-Scriptlets ausführen lassen.
Wenn Sie für die Verteilung von Agentenpaketen die Agentenbäckerei verwenden, steht Ihnen mit der Bakery-API eine Programmierschnittstelle zur Verfügung, mit der in Checkmk vorgenommene Einstellungen einfach den Weg auf überwachte Hosts finden.
4. Zu Checkmk beitragen
Wenn Sie selbst Erweiterungen programmieren, raten wir zunächst dazu, diese in die Checkmk Exchange einzureichen. Hier bleiben Sie Eigentümer und Ansprechpartner und Sie können unkompliziert neue Versionen bereitstellen. Da die Anforderungen an die Code-Qualität für die Exchange nicht so hoch sind wie für mit Checkmk ausgelieferte Check-Plugins, können Sie via Exchange neue Ideen unkompliziert mit einem breiten Publikum ausprobieren.
Sollten Sie irgendwann zum Entschluss kommen, dass Ihr Check-Plugin fester Bestandteil von Checkmk werden soll, lesen Sie zunächst Contributing to Checkmk.