Icinga 2 Best Practice Teil 6: Service-Checks auf Agenten schedulen

This entry is part 6 of 7 in the series Icinga 2 Best Practice

In Teil 1 dieser Blogserien beschäftigten wir uns mit Zonen, Agenten und wie man zentral angetriggert Plugins auf diesen Agenten ausführt. Nun im aktuellen Teil soll es darum gehen, das einplanen und ausführen dem Agenten selbst zu überlassen, damit werden auch während eines Verbindungsausfalls weiter Daten gesammelt und später, wenn die Verbindung wieder besteht, nachträglich übertragen.
In dem hier folgenden verdeutlichen wir, wie dies zu konfigurieren ist, mit einem Beispiel von einer Zone master, einer globalen Zone global-templates und einer Zone zu einem Beispiel Agenten agent.example.org.
Die Zonen- und Endpoint-Definitionen des Agenten auf Seite des Masters müssen in einer Datei in der Master-Zone oder in zones.conf hinterlegt werden. Leider ist es hier nicht möglich die jeweiligen Host-, Zonen- und Endpoint-Objekte in einer Datei zusammen zufassen, da wir das Host-Objekt agent.example.org zum Agenten selbst synchronisieren müssen und diese Definition in der Agenten-Zone abgelegt sein muss, z.B. in der Datei zones.d/agent.example.org/agent.conf:

object Host "agent.example.org“ {
 import "generic-host"
 address = "10.0.10.42"
 zone = get_object(Zone, name).parent
 vars.os = "Linux“
}

Durch die Ablage an genau diesem Ort, wird das Objekt zum Agenten synchronisiert. Mit setzen des Attributes zone auf die eigene Parent-Zone sorgen wir jedoch wieder dafür, dass das Host-CheckCommand sowie alle an diesen Host gebundenen Services auf einem Endpoint der Parent-Zone ausgeführt werden, hier die Zone master.
Damit wird der hostalive vom Master ausgeführt, was gewünscht ist, da sonst der Host seine Erreichbarkeit von sich selbst aus testen würde. D.h. alle Services, die auf den Agenten über das Netzwerk zugreifen sollen, bleiben wie sie sind und wir müssen keine Anpassungen vornehmen. Ganz im Gegensatz zu Services, die ein Plugin lokal auf dem Agenten ausführen sollen.

apply Service "load“ {
 import "generic-service“
 check_command = "load“
 if ( get_object(Zone, host.name) ) {
   zone = host.name
 }
 assign where host.vars.os == "Linux"
}

Auch Objekte vom Typ Service besitzen das Attribut zone mit dem wir hier nun die umgekehrten Weg beschreiten, existiert zum Host eine Zone selben Namens, wird die Zone zur Ausführung des zugeordneten Plugins in die eigene Agenten-Zone verlegt.

Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

Icinga 2 – Monitoring automatisiert mit Puppet Teil 3: Plugins

This entry is part 3 of 14 in the series Icinga 2 Monitoring automatisiert mit Puppet

Heute gehen wir der Frage nach wann und wie Plugins installiert werden sollten, was besonders wichtig bei Systemen mit icinga Benutzern zum Gegensatz nagios zu beachten ist. Auf z.B. RedHat-Systemen besteht das Problem, dass der Prozess Icinga 2 unter dem Benutzer icinga läuft, aber unteranderem das Plugin check_icmp oder auch check_dhcp nur vom Benutzer root oder einem Mitglied der Gruppe nagios mittels suid-Bit ausgeführt werden können.

# ls -l /usr/lib64/nagios/plugins/check_icmp
-rwsr-x---. 1 root nagios ... /usr/lib64/nagios/plugins/check_icmp

Das Ändern der Gruppenzugehörigkeit mit Puppet ist wenig hilfreich, da leider bei einem Update des Paketes nagios-plugins die alten Berechtigungen wieder hergestellt werden. Man könnte nun natürlich den Benutzer icinga und das Paket nagios-plugins explizit vor der Klasse icinga2 managen, verliert dann jedoch die Paketkontrolle über die uid und muss das Home-Directory, Shell und weitere Eigenschaften per Hand in Puppet entscheiden. Klarer ist die Methode genau diese Sachen dem Paket zu überlassen und erst danach icinga in die Gruppe nagios aufzunehmen.

yumrepo { 'icinga-stable-release':
  ...
}
->
package { [ 'icinga2', 'nagios-plugins' ]:
  ensure => installed,
}
->
user { 'icinga':
  groups => [ 'nagios' ],
}
->
class { '::icinga2':
  manage_package => false,
}

Um dieses Vorhaben umzusetzen ist es erforderlich die benötigten Repositories zuerst einzubinden, hier mit yumrepo angedeutet, dann die Pakete zu installieren, den Benutzer anzupassen und erst dann die Klasse icinga2 zu deklarieren.

Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

Monitoring Plugins in Go

Auf Twitter hat Jan Schaumann vor Kurzem begonnen eine Liste aufzustellen mit Dingen, die jeder Sysadmin in seinem Leben schon mindestens ein mal getan hat. Darunter zählen Sachen wie einen Parser für den ifconfig Befehl zu schreiben oder unvollständige Regexes für IP Adressen zu basteln. Beim Durchgehen dieser Liste habe ich mich immer wieder selbst ertappt. Es ist erschreckend, wie viele von diesen Dingen auf einen selbst zutreffen. Dennoch ist es sehr amüsant zu lesen.
Bei Netways arbeiten wir sehr viel im Bereich Monitoring. So ist es kein Wunder, das ich bei den Dingen die jeder Sysadmin schon mal getan hat, sofort auch an dieses Thema denken musste. Lange muss man da auch nicht überlegen: Jeder Sysadmin hat mindestens schon ein mal in seiner Karriere ein monitoring Plugin geschrieben. Das gehört einfach dazu und selbst DevOps wird uns vermutlich nicht davor bewahren.
Das Schreiben von monitoring Plugins ist auf den ersten Blick ein ziemlich einfaches Thema. So ein Plugin muss einen Rückgabewert von 0, 1 oder 2 liefert und im besten Fall einen Text ausgeben, der den Zustand beschreibt. Damit wären schon mal alle Grundvoraussetzungen gegeben. Weil es eben so einfach ist, gibt es auch so viele von diesen Plugins. Sie werden in nahezu jeder Programmiersprache geschrieben. Manche Plugins sind umfangreich mit vielen Optionen und noch mehr Performance Daten in der Ausgabe. Andere wiederum bestehen nur aus wenigen Zeilen und erfüllen einen einzigen speziellen oder simplen Zweck.
Was mich bei monitoring Plugins schon immer gestört hat, ist das Deployment von jenen. Je nachdem in welcher Sprache das Plugin entwickelt ist, müssen mit cpan, gem, pip, npm, pear, composer oder andern Package Managern Abhängigkeiten nachinstalliert werden. So richtig lästig wird das bei ein paar Hundert Plugins für ein paar Tausend Server mit unterschiedlichen Distributionen. Sind Windows Systeme dabei, … ach davon fang ich garnicht erst an.
Welche Lösung gibt es also dafür? Noch keine fertige, zumindest meiner Meinung nach. Selbst Configuration Management löst das Problem nicht ganz. Um das vernünftig zu machen, müsste man ja seine 3-Zeiler Plugins packetieren und vernünftige Module oder Cookbooks schreiben, die das dann auf die Systeme ausrollen. Bestenfalls natürlich auf jedes System nur die Plugins die dort auch wirklich hin gehören. Seitdem ich mich bezüglich eines Projekts aber mit der Programmiersprache Go auseinander setze, beschäftigt mich ein anderer Ansatz um das Problem zu lösen: was wäre, wenn so ein Plugin gar keine Abhängigkeiten hat?
Go ist eine Programmiersprache, deren Wurzeln bei C liegen. Sie ist dementsprechend auch keine Scriptsprache wie Ruby oder Python, fühlt sich manchmal aber trotzdem so an. Das führt dazu das Leute wie ich, die aus der Scripting Welt kommen, sich sehr schnell wohl fühlen mit Go. Ob Go eine objektorientierte Sprache ist, da scheiden sich die Geister. Objekte im klassischen Sinne gibt es nicht, zumindest werden sie nicht so genannt. Betrachtet man es im Detail, kann man aber nachvollziehen warum es Stimmen gibt, die Go als objektorientiert bezeichnen.
Wie bei anderen Sprachen auch gibt es bei Go viele Libraries die verwendet werden können, sie werden aber Packages genannt. Der in Go geschriebene Code muss kompiliert werden. Ein großer Vorteil dabei ist, dass die entstandenen Binaries standardmäßig statisch gelinkt sind. Das heißt im Umkehrschluss es muss nichts nachinstalliert werden mit gem, pip, cpan usw. Alles steckt schon in dieser einen Binary. Sicherlich lässt sich dasselbe auch mit C, C++ oder anderen Sprachen erreichen. Keine ist aber so einfach und einsteigerfreundlich wie Go. Das zählt für mich als sehr großer Vorteil, schließlich werden diese Plugins oft von Sysadmins entwickelt, deren Hauptbeschäftigung nicht das Programmieren ist.
Statisch gelinkte Binaries könnten also das Problem der Abhängigkeiten lösen. Spinnt man die Idee weiter, könnte man mit einem “monitoring plugin” Package für Go ein Framework schaffen mit dem einheitliche Plugins entwickelt werden. Eine tolle Idee, wenn ihr mich fragt. Das Problem des packetierens lässt sich übrigens wunderbar mit fpm lösen, dazu aber vielleicht ein anderes Mal mehr.
Mein Aufruf an dieser Stelle also: Schreibt eure monitoring Plugins in Go, denn ich möchte mich nicht stundenlang damit Beschäftigen sie zum Laufen zu kriegen!

Blerim Sheqa
Blerim Sheqa
Product Manager

Blerim ist seit 2013 bei NETWAYS und seitdem schon viel in der Firma rum gekommen. Neben dem Support und diversen internen Projekten hat er auch im Team Infrastruktur tatkräftig mitgewirkt. Hin und wieder lässt er sich auch den ein oder anderen Consulting Termin nicht entgehen. Mittlerweile kümmert sich Blerim hauptsächlich im Icinga Umfeld um die technischen Partner und deren Integrationen in Verbindung mit Icinga 2.

Monitoring Plugins 2.0 Release

nagios-plugins-upgradeWas lange reift, wird endlich gut – wer im Jänner mitbekommen hat, dass die ursprünglichen Nagios Plugin Entwickler vom Trademark-Besitzer rausgekickt worden sind, und ihre Software nunmehr unter dem Namen “Monitoring Plugins” an Mann/Frau ausliefern, hat lange auf dieses Release warten müssen. Nun ist es aber endlich da – Monitoring Plugins 2.0. Aktualisierte Pakete gibts hoffentlich bald, und jedem sei ans Herz gelegt, die vorherigen Nagios Plugins aus dieser vertrauenswürdigen Quelle zu aktualisieren.
Icinga 2 ist mit den Monitoring Plugins vollständig kompatibel, und liefert mit den Plugin Check Commands sogar erste Templates out-of-the-box die einfach weiterverwendet werden können. Wie man das macht, gibts unter anderem auch in unserer Icinga 2 Schulung zu bestaunen.
 
(Bild (c) memegenerator.net)

Michael Friedrich
Michael Friedrich
Senior Developer

Michael ist seit vielen Jahren Icinga-Entwickler und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi und der Linzer Torte. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht in der Community helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst...

Monitoring Plugins URL Update

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.

Michael Friedrich
Michael Friedrich
Senior Developer

Michael ist seit vielen Jahren Icinga-Entwickler und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi und der Linzer Torte. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht in der Community helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst...

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 “nagiosplugins.org”, (Update: monitoring-plugins.org) sowie Code und Bugtracker nun auf Github zu finden sind.

Michael Friedrich
Michael Friedrich
Senior Developer

Michael ist seit vielen Jahren Icinga-Entwickler und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi und der Linzer Torte. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht in der Community helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst...

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 http://downloads.linux.hp.com/SDR/repo/mcp wheezy/current non-free" >> /etc/apt/sources.list.d/hp.list

GPG Repository Schlüssel importieren

# wget -O - http://downloads.linux.hp.com/SDR/repo/mcp/GPG-KEY-mcp | 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.

Michael Friedrich
Michael Friedrich
Senior Developer

Michael ist seit vielen Jahren Icinga-Entwickler und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi und der Linzer Torte. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht in der Community helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst...

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
Dirk Götz
Senior 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
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.

Wie man ein Icinga Plugin nicht schreiben sollte

(this is a cross-post with my private blog, you will find there the English version of this post)
oder: Frameworking falsch gemacht
Ich bin diese Woche bei einem Kunden auf etwas interessantes gestoßen. Einige Plugins für Icinga verursachten enorme CPU Last, sobald ein paar Checks gleichzeitig gestartet sind waren beide CPUs der VM auf 80-90%.
Als ich mir die Plugins angeschaut habe fand ich seltsamen PHP Code, sah ungefähr so aus:

<?php
require_once('phplib/Framework.php');
if(!FRAMEWORK_LOADED) Framework::initialize();
CheckLicenseManager::run();

So auf den ersten Blick wirkt es ja nicht mal schlecht, da wird halt ein Framework geladen, dass die jeweiligen Klassen bereitstellt und dann wird die jeweilige Klasse “ausführt”. Das Framework selbst bestand aus mehreren PEAR Klassen und selbst geschriebenen Klassen die die jeweiligen Checks implementieren.
Das faszinierende an der Geschichte war jedoch dass das Plugin knapp 6 Sekunden dafür gebraucht hat die “–help” Ausgabe zu liefern, die eigentliche Funktion des Plugins ist in unter einer Sekunde fertig.
Ein strace des Skripts brachte dann das Problem recht schnell ans Tageslicht: das Framework tut nichts anderes als per PHP-Autoloadfunktion sämtliche PHP Dateien und Klassen im Verzeichnis zu laden, was ca. 90 Stück waren.
Ich erklärte dem Kunden das Problem, und dass ich wohl keine direkte Lösung anbieten könnte, außer eben die paar Plugins neu zu schreiben. Das machte ich dann auch und dem Server war wieder langweilig.
Ein paar Regeln für Icinga Plugins (die ich für mich gesetzt habe):

  • Keep it simple ™
  • Ordentlich kommentieren
  • eine verständliche –help Ausgabe mit Beispielen
  • bei komplexen Plugins: Verbose und Debug Funktionen für spätere Probleme und Tests
  • Möglichst in Perl oder Shell schreiben um weniger Abhängigkeitsprobleme zu haben
  • und last but not least:
    Wenn möglich veröffentlichen, denn dafür gibt’s monitoringexchange.org, denn irgendjemand kann es sicher auch gebrauchen!  😉
Markus Frosch
Markus Frosch
Principal Consultant

Markus arbeitet bei NETWAYS als Principal Consultant und unterstützt Kunden bei der Implementierung von Nagios, Icinga und anderen Open Source Systems Management Tools. Neben seiner beruflichen Tätigkeit ist Markus aktiver Mitarbeiter im Debian Projekt.