Check Plugin Entwicklung für check_mk Teil 2

UPDATE:  02.02.2014 – Anpassung an aktuellen Stand der Dinge.

So, ausgehend von Teil 1 gehts nun weiter mit der Entwicklung eines check_mk Plugins, am Beispiel eines MySQL check.

Wenn in Teil 1 nun alles geklappt hat, liefert uns der Agent des Servers nun die Sektion mysql_status mit aus. Dies lässt sich einfach mit cmk -d Hostname prüfen. Die Ausgabe sollte nun einen Abschnitt ähnlich diesem:

enthalten. Ist das der Fall, sind wir nun fertig für Schritt zwei. Pfadangaben die nun folgen, gehen von einer  Installation mit OMD aus. Solltest du OMD (Open Monitoring Distribution) noch nicht kennen, schau sie dir unbedingt mal an. Einen einfachen Weg, ein perfekt konfiguriertes Nagios/ Icinga inklusive verschiedener Plugins und Guis aufzusetzen, gibt es nicht. Also los: Wir legen nun unter ~/local/share/check_mk/checks/ das eigentliche check Skript mit dem Namen mysql_status an. Hier ist nun Python nötig.

Ein normaler Agent basierender Check besteht primär aus zwei Funktionen. Zum einen aus einer Inventory Funktion zum anderen aus der Check Funktion. Beginnen wir mit der Inventory Funktion:

Der Name der Funktion sollte immer inventory_check_name entsprechen. Übergeben wird ein Wert: Die sogenannte info . Diese enthält eine Liste bestehen aller Zeilen unserer Agenten Sektion. Praktischerweise sind die Zeilen auch gleich an den Leerzeichen/ Tabs gesplittet. An diesem Beispiel seht ihr was ich meine:

Und damit können wir jetzt arbeiten. Gerade bei der Ausgabe des SHOW STATUS; querys gibt es nun ziemlich viele Werte die uns gar nicht interessieren. Und jeder hat natürlich andere Interessen. Somit sollte es für jeden konfigurierbar sein, welche Werte er überwachen will. Hier kommt nun die Variable mysq_status_inventory ins Spiel. Diese ist am  Anfang des Checkes einmal leer definiert:

Sollen nun bestimmte Variablen Inventurisiert werden, passen wir aber nicht die Liste im Check an, sondern überschreiben diese in der main.mk (Eine Beschreibung für WATO folgt)

Weiter nun in der Inventory Funktion. Nach der Definition legen wir uns zuerst eine leere Liste als Hilfsvariable an. Wir nennen sie inv,  da wir in ihr später alle Übereinstimmungen ablegen.

Wir beginnen nun jeden Wert, der uns vom Agent geliefert wird, zu durchlaufen.

Und für jeden Wert müssen wir natürlich auch schon gleich nachsehen, ob eine Inventur gewünscht wird.  Wenn ja:

In line[0] steht nun der Name der SQL Variable, so wie wir ihn auch in unserer mysq_status_inventory liste vermerkt haben und als Schwellwerte werden die Default Levels übergeben.

Die Default Level Variable ist auch im Kopf des Checks festgelegt. Aber auch diese ändern wir nicht mehr im Check, sondern Überschreiben sie in der main.mk.
Durch iventory.append((item,(params)) können wir nun Item und Parameter in check_mk Form zusammenstellen. Aber erst mal landet es natürlich in der Liste inv. Ist die for Schleife durch info durch, geben wir nun unsere Liste im inv endgültig zurück an check_mk.

bei einem check_mk -I Rechnername werden nun alle unsere Werte gefunden und in die Autochecks aufgenommen. Was bedeutet, jetzt sind sie im Monitoring. Nun können wir zur check Funktion weiter. Aber das dann erst in Teil 3.

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahren Sie mehr darüber, wie Ihre Kommentardaten verarbeitet werden .

7 Gedanken zu “Check Plugin Entwicklung für check_mk Teil 2”