Immer wieder kommt es im Alltag eines Sysadmins mit Monitoring Ambitionen zu dem Fall, dass er etwas überwachen möchte, dass so vorher noch nie dagewesen ist oder dass er bestimmte Aspekte mit einbeziehen will/muss/möchte die bisher noch nicht in ein Plugin gegossen wurden.
An Stellen wie diesen kommt man oft nicht am neu- oder umprogrammieren eines Plugins vorbei. Hierbei stellt sich im Regelfall die Frage: „Welche Sprache benutze ich denn?“
Nagios und Icinga verstehen alle Programmiersprachen, die es fertig bringen auf der Kommandozeile ein Zahl zwischen 0 und 3 auszugeben. Das sind meines Wissens nach so gut wie alle und daher ist man der Lösung der Frage noch keinen Schritt näher gekommen.
Ein weit wichtigerer Aspekt der Auswahl ist wohl die Portierbarkeit auf verschiedenartige Systeme. So kann man z.B. mit Microsofts Powershell viele tolle Sachen machen. Sobald man dieses aber auf einem alten Windows oder wohl möglich auf einem unixoiden System ausführen will wird es trickreich bis unmöglich.
Sprachen wie Java, Python oder Perl sind hierfür einfach besser geeignet. Sie bieten für alle gängigen und für viele exotische Systeme Interpreter oder lassen sich, wie z.B. Perl, auch gleich mit Interpreter in ein handliches Paket (windows Exe) schnüren. Wie das funktioniert wurde im Blog vor kurzem schon mal erklärt.
Meine Wahl fällt schon seit längerem immer wieder auf Perl. Wenn’s ums umschreiben geht kommt man oft nicht dran vorbei weil viele Plugins schon in Perl verfasst wurden. Wenn’s ums neu schreiben geht macht einem Perl das Leben einfach einfacher. Dank des universellen und einfach nur genialen CPAN, dass mit einem Haufen von Modulen für jeden nützlichen bis unnützen Zweck daher kommt, kann man innerhalb kürzester Zeit eigene Plugins für so ziemlich alles schreiben was eine Schnittstelle aufweist bis hin zu Modulen die einem die Logüberwachung oder das auslesen von CLI tools vereinfachen.
[poll id=“3″]
Wie mit jeder Sprache ist es wichtig, die Nagios Developement Guidelines einzuhalten, um den Nutzen eines Plugins zu maximieren. Nützlich sind hierfür z.B. die Module Nagios::Plugin::Threshold und Nagios::Plugin::Range. Beide kann man hier finden. Jedoch kann man diesen Teil auch noch leicht selbst implementieren.
Schwieriger wird es bei so Dingen wie einer Datenbankschnittstelle. Aber auch hierfür bietet Perl schon fix und fertige Module die bloß noch eingebunden werden müssen. Das sind z.B. DBD::Sybase für mssql oder DBD::mysql.
Auch für die universelle Windows Verwaltungs Datenbank bietet das CPAN ein Modul(Win32::OLE), mit dessen Hilfe man fix ein generisches Plugin für WMI angelegt hat.
Und last but not least hat Perl einfach das schönste Wappentier 🙂 Für mich steht die Entscheidung fest und Ihnen wird sie hoffentlich jetzt einfacher gemacht die „richtige“ Sprache für die Plugin Programmierung auszuwählen.
Hallo Christoph,
hast Du vielleicht mal Lust, mal einen Artikel für das Perl-Magazin zu schreiben, wie man Plugins in Perl umsetzt?
– Renée