Ich bin in letzter Zeit vermehrt über Plugins gestolpert, die fehlerbehaftet waren und somit ganz interessante Situationen hervorrufen könnten oder teilweise auch getan haben. Diese will ich nun aufzeigen und anhand der Nagios Plug-in Development Guidelines zeigen wie es richtig geht.

Fall 1: Das “immer OK”-Plugin
Zur Überwachung des Logins auf eine wichtige Webanwendung kommt ein selbst geschriebenes Plugin zum Einsatz. Nachdem ich bei einer Migration immer alle Plugins in der Shell teste, fällt mir auf das Plugin gibt “Critical: …” aus. Erster Gedanke ist natürlich: “Ok, ich komm von einer anderen IP-Adresse, liegt es daran?” Also flink ins Webinterface des Altsystems geschaut und siehe an, dort ist alles grün und zwar seit über zwei Jahren. Allerdings wenn ich mir die Ausgabe anschaue steht da auch “Critical: …”!
Der Fall ist schnell gelöst, im Quelltext steht am Ende ein für die Ausgabe verantwortliches IF-Konstrukt, aber in keinem der Zweige gibt es ein exit, also ist der Rückgabewert des Plugins der des letzten Kommandos. Nun ja, echo schlägt wohl nie fehl und darum ist der Rückgabewert 0, was Nagios als OK interpretiert.
Als Lösung importierte ich die Datei utils.sh aus den Nagios-Plugins und füge ein exit STATE_OK bzw. STATE_CRITICAL ein.

Fall 2: Das “Warum UNKNOWN?”-Plugin
Dieser Fall schlägt in die gleiche Kerbe wie der vorherige. Diesmal wurde das Plugin in vollstem Vertrauen aus dem Internet besorgt, der Status war aber plötzlich UNKNOWN und ohne eine Ausgabe im Webinterface.
Hier reicht für die Lösung des Falls einmal Ausführen in der Kommandozeile. Das Plugin stirbt einen grausamen Tod, wenn es keine Verbindung aufbauen kann und gibt seinen Todesschrei auf STDERR aus.
Die Lösung ist wieder genauso simpel. utils.pm importiert, die "Todesschrei" durch print "Critical: Todesschrei" and exit $ERRORS{'OK'} ersetzt.

Fall 3: Die “Kein Graph”-Plugins
Wenn ein Plugin keine Performance-Daten liefert, ist recht schnell geklärt warum kein Graph gezeichnet wird. Sobald da aber was hinter der Pipe steht beim Ausführen auf der Kommandozeile oder gar im Webinterface als Performance-Daten angezeigt wird, erwartet man einfach eine graphische Aufbereitung.
Im Falle 3a war ganz offensichtlich, dass diese Ausgabe nicht für Nagios gedacht ist und ein Blick auf die ausführliche Hilfe offenbart einen Parameter zum Umschalten des Formats. Wäre dann noch Fall 3b und 3c hier kann ich den Fehler nicht auf den ersten Blick erfassen, also Guidelines auf. Mit dem Vergleich wird der jeweilige Fehler offensichtlich. In dem einen Fall ist das Label nicht einfache Hochkommas eingefasst obwohl es ein Leerzeichen enthält, im andere sind die verschiedenen Werte statt durch Leerzeichen durch Semikolon getrennt und somit werden die Werte als Warning- und Critical-Wert des ersten interpretiert.
Da es sich um Bash bzw. Perl handelt ist, ist dies natürlich auch schnell gefixt.

Fall 4: Das “4 von 5″-Plugin
Fünf identische Systeme, bei vieren laufen alle Plugins sauber, beim fünften bleibt eines permanent auf unknown. Mögliche Fehlerursache laut des Verantwortlichen ist die neuere Firmware und damit fehlende OID in SNMP.
Zwar halte ich dies für möglich, da man Hardwareherstellern nach einer Weile alles zutraut, doch überzeuge ich mich lieber selbst. Und siehe da ein snmpwalk liefert auf alle Systemen die OID nicht, gut nun bin ich verwirrt. Also snmpwalk mit Angabe der OID und siehe da plötzlich bekomme ich bei beiden getesten Systemen eine Antwort. In vollster Verwirrung und Unglaube führe ich das Plugin nochmal aus und bekomme diesmal auch eine Antwort. Da ich nur an 0 und 1 in der IT glaube und 0,5 nicht gelten lasse, probiere ich das Plugin noch öfter. Nachdem sich ein lustiger Blinkereffekt zeigt, setze ich den Timeout auf zehn Sekunden statt dem Default von einer Sekunde. Und somit ist auch dieses Rätsel gelöst, das neue System lässt die gleichen Abfragen zu, ist allerdings nur mit größerer Latenz zu erreichen.
Zwar meckere ich warum der Standard-Timeout so niedrig ist und der Timeout nicht in der Ausgabe erscheint, aber sonst kann man nicht meckern denn einen sauberen Timeout-Mechanismus zu implementieren gehört auch zu den Guidelines.

Noch viele andere interessante Dinge sind in den Guidelines geregelt, beispielsweise wie die Warning- und Critical-Bereichsangaben zu interpretieren sind, welche Optionen vorhanden sein sollten oder wie verbose denn verbose sein sollte. Darum meine Bitte: Lieber Entwickler, lest euch die Guidelines durch bevor ihr Plugins entwickelt! Das schont nicht nur meine Nerven und die der Kollegen, sondern sorgt auch für Kompatibilität zu Graphing-Lösungen wie PNP4Nagios und Ingraph oder interessanten Komponenten wie Check-multi, die diese Standards brauchen und recht wenig Spielraum haben um diese zu interpretieren.

Autor: Dirk Götz

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Nagios, Puppet und andere Systems Management Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich.

• More Posts (7)