check_generic koennte das Schweizer Messer in Ihrer Monitoring-Toolbox werden, aber vor dem Vergnuegen steht noch etwas Anstrengung. Lassen Sie uns in einer kleinen Session herausfinden, was sich alles anstellen laesst mit check_generic.

Zuerst einmal sollten wir tun, was man immer tun sollte, wenn man Plugins testet: sich als User 'nagios' einloggen. Viele Fehler entstehen dadurch, dass Plugins unter 'root' getestet werden und man sich wundert, warum sich die Plugins ploetzlich soviel anders verhalten als spaeter in der Produktivumgebung unter dem User 'nagios'.

# su - nagios
$

Zum zweiten werfen wir schon mal einen kleinen Blick auf das Plugin und rufen es ohne Option auf. Damit erhalten wir die Aufrufuebersicht:

$ ./check_generic 
check_generic error: no commandline specified

check_generic -e <cmdline> -o|u|w|c <expression> [-f false_state] [-n name] [-t timeout] [-r level]
check_generic [-h | --help]
check_generic [-V | --version]

Na prima Das Plugin meckert ueber ein fehlendes Kommando. Ok, wir werden das Problem beheben…

Lassen Sie uns beginnen mit den zwei Teilen, die Sie fuer jeden Aufruf von check_generic benoetigen:

1. -e/–execute um den Befehl festzulegen, der ausgefuehrt werden soll und
2. -c/–critical um die Bedingung zu bestimmen, bei der das Plugin den Status 'critical' annehmen soll.

Das koennten ebenso -w/–warning oder -u/–unknown sein, aber wie auch immer: wir fangen klein an und steigern uns spaeter.

Nun brauchen wir noch etwas zum Monitoren. (Normalerweise sollte man sich darueber Gedanken gemacht haben, bevor man ein Plugin schreibt )
Wie waere es damit, Nagios selber zu monitoren? Es gibt ein kleines Programm namens nagiostats, das in jeder Nagios-Installation enthalten ist. Lassen Sie uns nun mal sehen, was wir alles damit anstellen koennen.
Wenn man nagiostats auf einem laufenden Nagios-Server startet, gibt es haufenweise Zahlenkolonnen aus, die die Anzahl der Checks und die Performance des Nagios-Systems beschreiben. Wir werden uns hier auf die Performance konzentrieren und die wird am besten durch die sogenannte Latency beschrieben. Latency entsteht, wenn Nagios einen Check fuer einen bestimmten Service plant, diesen Zeitpunkt aber nicht nicht einhalten kann. Die Differenz zwischen geplantem und wirklich durchgefuehrtem Check ist die Service Check Latency.
Unser naechster Schritt ist, diese Zahl aus den Ausgaben von nagiostats zu extrahieren. Wir koennen das natuerlich mit der folgenden Unix-Befehlskette tun

$ /usr/local/nagios/bin/nagiostats  | grep "Active Service Latency:" | awk '{print $8}'

Besser geht es aber mit der MRTG-Option

$ /usr/local/nagios/bin/nagiostats -m -d AVGACTSVCLAT

Dieser Befehl gibt die durchschnittliche Latency in Millisekunden aus. Damit heisst unsere check_generic Zeile nun

$ ./check_generic -e "/usr/local/nagios/bin/nagiostats -m -d AVGACTSVCLAT"

Oops - check_generic meckert immer noch irgendwas wie
Sorry Dave. No evaluation expression specified.
Nun gut - hier kommt jetzt endlich der Trick:

Jeder Perl-Ausdruck zur Bewertung des Outputs des angegebenen Befehls ist erlaubt.

• Bei numerischen Vergleichen kann man “>100“ oder “<50“ formulieren.
• Wenn es um einen Stringvergleich geht, einfach „eq 'abc'“ nehmen.
• Auch regulaere Ausdruecke sind erlaubt: “=~/perl-regex/“

Fuer unser Beispiel fangen wir mal mit 1 Minute Latency an, das sind umgerechnet 60000 Millisekunden:

$ ./check_generic -e "/usr/local/nagios/bin/nagiostats -m -d AVGACTSVCLAT" -c ">60000"

Uebrigens: meiner Meinung nach ist diese Schwellwert-Notation wesentlich einfacher und weniger verwirrend als die original Nagios-Mimik mit -c „2:5“…
Aber schau'n wir mal, was unser Plugin tut:

$ ./check_generic -e "/usr/local/nagios/bin/nagiostats -m -d AVGACTSVCLAT" -c ">60000"
CHANGEME OK - result:533 match:none

Was heisst das nun? Unser Plugin hat eine simple Perl-Evaluation durchgefuehrt: „533>60000“ → false
Schauen wir nochmal auf die Details der Ausgabe CHANGEME OK - result:533 match:none:

• CHANGEME - hier kann mit der -n-Option ein beliebiger Name definiert werden
• OK - kein kritischer Status, alles bestens
• result:533 - die gegenwaertige Service Check Latency betraegt 533 Millisekunden
• match:none - es gibt hier keine Uebereinstimmung gegen den kritischen Schwellwert

Nun ists an der Zeit, das Ganze noch ein bisschen aufzubohren. Zuerst einmal brauchen wir auch noch einen Warning-Schwellwert. Das ist kein Problem: einfach -w “>500“ anfuegen. OK, damit heisst die Kommandozeile (inklusive Namen fuer unsern Check):

$ ./check_generic -n nagios_service_latency -e "/usr/local/nagios/bin/nagiostats -m -d AVGACTSVCLAT" -c ">60000" -w ">500"
nagios_service_latency WARNING - result:616 match:>500 severities:warning

Hier gibts nun etwas Neues:

• Das Plugin hat einen Namen: nagios_service_latency (siehe -n-Option)
• es hat den Status WARNING
• es matcht gegen die Regel '>500'
• severities: warning heisst, dass hier die WARNING-Regel matcht. Es koennen schliesslich mehrere Regeln zutreffen.

Das wars. Hat etwas gedauert, aber sagen Sie selbst: war das wirklich schwer?

Zum Schluss noch ein paar nuetzliche Hinweise fuer die Konfiguration Ihrer check_generic-Einstellungen:

• Immer als 'nagios' einloggen. Einfach mit dem Plugin spielen, bis die Konfiguration passt.
• Wenn es mal ein schwierigeres Kommando sein soll: erst mal ausserhalb von check_generic testen, bis es funktioniert.
• Mit den Schwellwerten herumspielen, um auch mal WARNING und CRITICAL Events zu provozieren. Einfach mal schauen, ob alles sich so verhaelt, wie Sie sich das gedacht haben.
• Ansonsten viel Spass (und schauen Sie auch mal auf die Beispielseite).