Das Icinga-Ökosystem beinhaltet bereits eine Vielzahl an Monitoring-Plug-ins. Trotzdem kommt jeder früher oder später an den Punkt, an dem bestehende Plug-ins nicht ausreichen und die Entwicklung eines eigenen Plug-ins ansteht. In diesem Vortrag wird die Funktion von Plug-ins exemplarisch an Beispielen in Shell und Perl dargestellt. Die folgenden Themen werden behandelt: Die Plug-in-Schnittstelle von Icinga Performance-Daten (PNP4Nagios) Beispielimplementationen in Shell Beispielimplementationen in Perl Schreiben von Plug-ins gemäß Monitoring-Plug-ins-Konvention Nagios::Plug-In Perl-Bibliothek Kurze Beispiele in Ruby, Python und Windows Powershell

1. Plugin Entwicklung
für Einsteiger
Alexander Wirt
19. November 2014

2. Inhaltsverzeichnis
Persönliches
Die Theorie
Was ist ein Plugin
Über Returncodes
die Ausgabe
Performancecounter
Parameterübergabe
Die Praxis
Debugging
Hello World
Perl
Python
Fragen
Dokumentation

3. Persönliches
I IT Leiter bei einem kleinen norddeutschen Mittelständler
I Nebenberuflicher Consultant
I Debian Entwickler seit 2003
I 15 Jahre Nagios Erfahrung
I Maintainer von Paketen wie Nagios, Icinga, Icinga2, nsca-ng und
andere

4. Die Theorie
Was ist ein Plugin?
I Plugins sind ausführbare Dateien
I diese werden in regelmässigen Abständen vom Monitoringsystem
aufgerufen
I der Rückgabecode bestimmt den Status des Objekts
I Plugins können in jeder Sprache geschrieben sein

5. Die Theorie
Über Returncodes
I Der Returncode eines ausgeführten Plugins bestimmt das Ergebniss
I Der zurückgegebene Text hat keinerlei Einfluss auf das Ergebniss
I Die meisten Checks können sowohl für Hosts, als auch für
Servicechecks verwendet werden

6. Die Theorie
Returncodes bei Hostchecks
Hostchecks
0 UP
1 UP / DOWN 1
2 DOWN
3 DOWN
1Hängt von der Option use_aggressive_host_checking ab

7. Die Theorie
Returncodes bei Servicechecks
Servicechecks
0 OK
1 Warning
2 Critical
3 Unknown

8. Die Theorie
Textausgabe
Ausgabeformat
Textausgabe | Performancecounter
Erweiterter Text Zeile 1
Erweiterter Text Zeile 2
...
Letzte Zeile erweiterter Text | Performancecounter Zeile 2
Performancecounter Zeile 3
...
Letzte Zeile Performancecounter

9. Die Theorie
Ausgabebeispiele
Einzeilige Ausgabe
SSH OK - OpenSSH_6.7p1 Debian-3 (protocol 2.0) | time=0,004733s;;;0,000000;10,000000

10. Die Theorie
Ausgabebeispiele
Mehrzeilige Ausgabe
DISK OK - free space: / 3326 MB (56%); | /=2643MB;5948;5958;0;5968
/ 15272 MB (77%);
/boot 68 MB (69%);
/home 69357 MB (27%);
/var/log 819 MB (84%); | /boot=68MB;88;93;0;98
/home=69357MB;253404;253409;0;253414
/var/log=818MB;970;975;0;980

11. Die Theorie
Zusammenfassung Ausgabe
I Die Textausgabe ist nicht standardisiert
I Die Ausgabe hat keine Auswirkung auf den Checkresult
I Mehrzeilige Ausgaben können Probleme verursachen

12. Die Theorie
Perfomancecounter
I Counter werden im Normalfall nicht vom Monitoringsystem
interpretiert
I Ausnahme: Icinga2 (Graphite Addon)
I Formatierungsempfehlungen kommen aus dem Monitoring Plugins
Projekt

13. Die Theorie
Performancecounter - Format
Format
‘LABEL’=VALUE[Einheit];[WARN];[CRIT];[MIN];[MAX]
I Weitere Felder werden Leerzeichen separiert hinzugefügt
I Bei mehrzeiligen Performancecounter Feldern fügt das System die
Zeilen zusammen. Hierbei wird kein Leerzeichen eingefügt. Es ist
also darauf zu achten das nach dem Zusammenfügen die einzelnen
Counter weiterhin durch ein Leerzeichen separiert sind.

14. Die Theorie
Performancecounter - Label
I Singleticks sind optional, aber empfohlen
I Bei Leerzeichen im Label sind sie verpflichtend
I Labels dürfen keine Singleticks oder Gleicheitszeichen enthalten

15. Die Theorie
Performancecounter - Einheiten
% Wenn ein Wert als Prozentwert angegeben wird sind Min
und Max optional
{u,s}s Sekunden
{K,M,T}B Bytes
c Counter
int,float Werte ohne Einheit (z.B. Load, Benutzer)
I Alle Werte müssen in der selben Einheit sein
I Für Werte die nicht ermittelt werden konnten kann ein ‘U’
eingesetzt werden
I Warn und Crit müssen dem Monitoring Plugins Bereichsformat
entsprechen

16. Die Theorie
Performancecounter - Bereichsformat
Bereichsformat
[@]start:ende
I startende
I start: ist optional wenn start Null ist
I Wenn end nicht spezifiert ist wird er als unendlich angenommen
I Negative Unendlichkeit kann mit ˜spezifiziert werden
I Ohne führendes @ wird angenommen das beim Verlassen des
Bereiches ein Alarm ausgelöst wird
I Mit führendem @ wird angenommen das innerhalb des Bereichs ein
Alarm ausgelöst wird

17. Die Theorie
Parameterübergabe
Argumente
I Makros können als Argumente an ein Plugin übergeben werden
I Zusätzliche Argumente können über $ARGX$ Makros übergeben
werden
Umgebungsvariablen
I Können über die ienable_environment_macros Option
eingeschaltet werden
I Performancekiller
I On-Demand und $USER$ Makros sind nicht verfügbar

18. Die Praxis
Debugging
I Plugins sollten immer zuerst auf der Kommandozeile getestet werden
I Immer als der Benutzer ausführen unter dem sie auch später laufen
(nagios/icinga/..)
I test-plugin

19. Die Praxis
hello world
1 #!/bin/bash
2 echo Hello World
3 r=$RANDOM
4 let r %= 4
5 exit $r

20. Die Praxis
hello world

21. Die Praxis
Perl
I Perl kann durch EPN ausgeführt werden
I Monitoring::Plugins benutzen

22. Die Praxis
Python
I nagiosplugin Bibliothek

23. Die Praxis
EPN
EPN
I Wesentlich schneller
I Größerer Memory Footprint
I EPN Dokumentation
I # nagios: +epn zum Einschalten innerhalb der ersten 10 Zeilen
Code
I # nagios: -epn zum Einschalten

24. Und danach?
share your work!
I Icinga Exchange
I Nagios Exchange

25. Fragen?
IRC
Join us on IRC #icinga@freenode
E-Mail
I Icinga Users Mailingliste
I Monitoring Plugins Mailingliste

26. Dokumentation
I Monitoring Plugins Development Guidelines
I Icinga Dokumentation zu Hostchecks
I Icinga Dokumentation zu Servicechecks
I Macros in Icinga