Hallo kohly.de
ja, gern!
Also, wenn man einen Check bauen möchte, dann muss man ja einen Agenten auf den Host befördern, der eine Section aufmacht und Daten liefert.
<<<my_check_type>>>
mydata = 1
myotherdata = 2
Dieser Text (also ohne den Header) wird ja dann an den Check weitergegeben, nur eben als 2-Dimenionale Liste an die jeweilige Parse-Funktion.
Dafür sucht CheckMK einfach nach einer Datei in
/opt/omd/sites/master/local/share/check_mk/checks/
wenn da keine ist, dann in den vordefinierten Checks
/opt/omd/sites/master/share/check_mk/checks/
mit genau dem Namen, der in den <<<…>>> eingeschachtelt ist.
Diese Datei ist der Check. Der Check muss dabei einigen Formalien genügen, er muss in Python2 (CheckMK unter v2.0) oder Python3 (CheckMK ab v2.0) geschrieben sein, der Dateiname, darf aber kein .py hinten haben … außer die Section hat das auch.
Die ersten Zeilen des Check-Files müssen
#!/usr/bin/python
# -*- encoding: utf-8; py-indent-offset: 4 -*-
lauten.
Dann braucht es (mindestens 3 Funktionen)
- Eine Parsed-Funktion, die von der Section eine zweidimensionale Liste list[lineNo][wordNo] bekommt und die vorformatiert
- Eine Inventory-Funktion, die die parsed-Datenstruktur der Parsed-Methode bekommt und für jeden Service, der erstellt werden soll, einen Wert zurückgibt (yield)
- Eine Check-Funktion, die neben dem parsed (und möglichen Params), auch noch einen der Services aus Inventory bekommt und für diesen Service Status, Text und Messwerte zurückgibt.
Das sieht zum Beispiel so hier aus:
def parse_my_check_type(info):
# some Magic
return formated_info_as_parsed
def inventory_my_check_type(parsed):
for service in parsed.keys():
yield service
def check_my_check_type(item, params, parsed):
perfdata = [('metricName", numericValue, numericWarnLevel, numericCritLevel), ...]
# perfdata ist eine Liste von Tupeln, Warn und Crit sind optional (gelbe, rote Linie im Graph)
return parsed[item][status], parsed[item][outputtext]
Das ist für CheckMK jetzt aber nicht zu gebrauchen. CheckMK kennt den Namen der Methoden nicht und es kann auch mehr geben, theoretisch kann man parsed weglassen … also muss man CheckMK jetzt noch sagen, wie die Funktionen heißen, die es in diesem Check-Plugin benutzen muss.
Also steht am Ende der Check-Datei noch ein sehr wichtiger Block, der sieht in dem Fall hier so aus:
check_info['my_check_type'] = { # Wieder der Check-Name (Section-Bezeichner)
'parse_function' : parse_my_check_type,
'inventory_function' : inventory_my_check_type,
'check_function' : check_my_check_type,
'service_description' : 'Anfang des ServiceName %s', # erweitert um item-Name
'has_perfdata' : True,
}
Wenn es einen Check gibt, der perfdata verwendet, dann ist die Zeile ganz am Ende wichtig. Nur wenn man in dem Block am Ende
'has_perfdata' : True
schreibt, genau nur dann, wird CheckMK auch Kurven zeichnen.
Mir persönlich ist nicht klar, warum man darauf verzichten sollte, wenn man keine Performance-Werte erfassen möchte, ich schreibe das (jetzt) einfach immer in jeden Check unten rein und damit trifft mich dieses Problem gar nicht mehr.
