Wie ich vorhin in einem Gespräch mit einem der Plugin Entwickler feststellen durfte, zeigt nagios-plugins.org nicht denselben Inhalt wie eigentlich vom Monitoring Plugins Team angedacht. Also so mit Nagios Forks wie Icinga, und nicht nur Nagios only und so. Nachdem das ganze schon wieder sehr übelriechend nach Zensur und Contenthijacking von einer nicht erwähnenswerten Firma aussieht, meine Bitte an den geneigten Leser:
Aktualisiert eure Bookmarks – offizielle Monitoring Plugins (früher: Nagios Plugins) gibts von nun an auf https://www.monitoring-plugins.org, auch für Icinga 1.x und Icinga 2.
NETWAYS Blog
Nagios Plugins 1.5 veröffentlicht
Das Nagios Plugin Development Team hat heute die Version 1.5 der Nagios Plugins veröffentlich. Diese sind ebenso mit Icinga 1.x als auch Icinga 2.x kompatibel, neben vielen anderen Plugins im Netz.
Ebenso hat sich die Domain geändert, mit Bindestrich „nagios–plugins.org“, (Update: monitoring-plugins.org) sowie Code und Bugtracker nun auf Github zu finden sind.
HP System Health Tools auf Debian Wheezy
Um auf HP Systemen die Hardware ordentlich überwachen zu können, gibt es die HP System Health Tools (die über die Jahre hinweg verschiedene Namen gehabt haben, wie etwa hpasm / hp-health). Um diese Abfragen dann beispielsweise in den SNMP Baum einzupflegen, damit Plugins diese Schnittstelle abfragen können, müssen zusätzlich die SNMP Agents installiert werden.
Die Leidensgeschichte der nicht vorhandenen bzw nicht aktuellen Debian Repositories ist lang, aber die frohe Botschaft ist – es gibt seit einigen Tagen ein aktuelles Debian Wheezy Repository mit non-free Paketen direkt von HP 🙂
Und so gehts:
Repository hinzufügen
# echo "deb wheezy/current non-free" >> /etc/apt/sources.list.d/hp.list
GPG Repository Schlüssel importieren
# wget -O - | apt-key add -
HP Tools suchen und gegebenenfalls installieren.
# apt-get update # apt-cache search ^hp- ... hp-search-mac - Search for a MAC address on HP switches hp-smh-templates - HP System Management Homepage Templates hp-health - hp System Health Application and Command line Utility Package hp-snmp-agents - Insight Management SNMP Agents for HP ProLiant Systems hp-ams - Agentless Monitoring Service for HP ProLiant Gen8 Systems
Damit kann man dann mit gängigen (SNMP) Plugins die HP Hardware überwachen. Wie das im Detail funktioniert, erklären meine Kollegen gerne in Schulungen/Workshops oder erstellen auch gerne individuell an Bedürfnisse angepasste Plugins.
Nagios Plug-in Development Guidelines oder warum tut mein Plugin nicht wie es soll?
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.
Dirk Götz
Principal Consultant
Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman 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 wie nun bei NETWAYS.
check_open_problems – Alles bunt und doch im Griff
Mit der Idee zu einem überaus nützlichen Plugin trat kürzlich unser Kunde Perdata an uns heran. Das Plugin für Icinga und Nagios sollte Performancedaten zur Anzahl der gegenwärtig offenen Host- und Service-Probleme liefern und bei Überschreiten einer bestimmten Anzahl von Problemen auch entsprechende Benachrichtigungen auslösen können. Das Ziel dahinter ist klar: erstens kann man sich so historisch schön darstellen, wie sich die eigenen „Probleme“ entwickelt haben. Und zweitens erhält man eine Benachrichtigung, wenn neue Probleme im alltäglichen Grundrauschen untergehen und sich zu lange keiner darum kümmert.
Die Performancedaten wurden aufgeschlüsselt in offene Probleme, solche die acknowledged wurden sowie Downtimes. Die „konfigurierbare Anzahl“ wurde zugunsten einer Mindestdauer verworfen, das Plugin ändert seinen eigenen Zustand also nach dem Zustand des „schlimmsten“ Problems, um das sich nach entsprechend verstrichener Zeit noch keiner kümmert.
Der Aufruf ist relativ simpel, und das Plugin „erklärt“ sich im Grunde selbst:
Options: check_open_problems.pl -H <db_host> -U <db_user> -P <db_pass> -... -H|--host Database Host, default is 'localhost' -U|--user Database user, default is 'icinga' -P|--pass Database password, default is 'icinga' -B|--blacklist Blacklisted service names, comma-separated. Default: 'Open problems' -M|--min-duration Ignore problems lasting less than min-duration seconds. Default: 0
Beachtung verdient der Blacklist-Parameter. Er sollte dem Namen entsprechen, der als Service-Bezeichner für dieses Plugin vergeben wurde. Nur so hat das Plugin eine Chance, seinen eigenen Zustand ignorieren zu können. In der ersten Zeile zeigt die Ausgabe den aktuellen Zustand und eine Zusammenfassung der zugehörigen Stati an:
[CRITICAL] Hosts: 8x DOWN, 1x UNREACHABLE – Services: 6x acknowledged
Anschließend werden im „long-output“ die neuesten Host-Probleme angezeigt, davon aber immer nur die letzten 5:
Host problems: gmx-www (19.08. 20:48), google-www (19.08. 20:48), web_de-www (19.08. 20:48), yahoo-www (19.08. 20:48), ...
Darunter stehen dann zudem noch die neuesten Service-Probleme samt gekürztem Output. Das fertige Plugin ist wie üblich auf Monitoring Exchange verfügbar und steht unter git.netways.org in der aktuellsten Version zum Download bereit. Viel Freude mit dem Plugin – und an Perdata nochmals ein herzliches Dankeschön für die gute Idee und das Sponsern der Entwicklung!
Thomas Gelf
Principal Consultant
Der gebürtige Südtiroler Tom arbeitet als Principal Consultant für Systems Management bei NETWAYS und ist in der Regel immer auf Achse: Entweder vor Ort bei Kunden, als Trainer in unseren Schulungen oder privat beim Skifahren in seiner Heimatstadt Bozen. Neben Icinga und Nagios beschäftigt sich Tom vor allem mit Puppet.
