Seite wählen

NETWAYS Blog

Check-Plugins für Monitoring – Professionelle Entwicklung mit NETWAYS

Open Source Monitoring Lösungen wie Icinga sind mächtige Werkzeuge zur Überwachung der IT-Infrastruktur. Doch wie bei vielen „historisch aus Nagios gewachsenen“ Varianten, ist die reine Installation der Software nur der erste Schritt. Die volle Bandbreite der Möglichkeiten zeigt sich erst, wenn Check-Plugins hinzugefügt werden. Dadurch lassen sich (fast) alle Monitoringwünsche erfüllen. Und da es sich bei der Open Source Monitoring-Community um eine lang bestehende und sehr aktive Gruppe von Menschen handelt gibt es bereits umfassende Plugin-Sammlungen, die Heute den Standard bilden.

Sollte bei dem vielfältigen Angebot dennoch einmal nicht das richtige dabei sein oder du benötigst ein auf deinen speziellen Use Case zugeschnittenes Check-Plugin, hilft dir unsere interne Entwicklung weiter. Wir konzipieren und entwickeln dein Check-Plugin. Welche Programmiersprache wir dabei nutzen und wieso wir als Open Source Consulting Dienstleister überhaupt selbst entwickeln, erklärt dir unser Technical Service Manager und Entwickler Philipp Dorschner.

Aller Anfang ist schwer!

Wir bei NETWAYS Professional Services bieten neben unserem klassischen Kerngeschäft Open Soure-Consulting und Operations seit etwas über zwei Jahren auch Entwicklungsarbeiten an. Dies war jedoch nicht immer so. Einige meiner Kolleg:innen können sich noch an die Anfänge zurückerinnern, als sich bei einem Consultingtermin vor Ort oft neue und spezielle Herausforderungen herauskristallisierten, welche mit den „Standardmitteln“ nicht abgedeckt werden konnten. Kolleg:innen mit Programmiererfahrung konnten zwar dank ihrer Erfahrung ein paar Anforderungen umsetzen, dennoch musste man dabei immer den Spagat zwischen Consulting und Entwicklung bewältigen.
War das Problem so wichtig, dass die Zeit vom eigentlichen Consulting weggeht oder lässt man es wohl oder übel sein?

Ein weiterer Aspekt war die „Vermischung“ von Icinga und NETWAYS. Aufgrund der gemeinsamen Vergangenheit war es für Außenstehende oftmals verwirrend, dass NETWAYS und Icinga bereits seit mehr als vier Jahren keine zusammenhängende Unternehmung mehr ist. Die örtliche Nähe spielte dabei natürlich eine Rolle, aber das entwicklungstechnische stand im Vordergrund. Hin und wieder fragten Kunden während des Consulting an, ob wir nicht nachfragen können ob Icinga nicht ein spezielles Check Plugin für sie entwickeln könne, da wir ja sowieso „nebenan sitzen und zusammengehören würden“. Dadurch, dass Icinga das bestmögliche unternimmt um das Produkt Icinga mit immer neuen Features zu erweitern, sind die Ressourcen von Icinga für individuell angepasste Check Plugins nicht vorhanden. Da die NETWAYS aber als langjähriger Icinga Partner mit Plugins und anderen Entwicklungsarbeiten dem Icinga Projekt zuarbeitet und zu dessen Weiterentwicklung beiträgt, gelang manchmal dieser Spagat.

Wirft man einen Blick auf die oben genannten Punkte, wird klar, dass eine eigene Entwicklung bei NETWAYS durchaus Sinn ergibt. Somit wurde entschieden, dass wir bei NETWAYS selbst fortan kleinere bis mittelgroße Entwicklungsarbeiten für Kunden übernehmen.

Was genau bieten wir an?

Entwicklung im Allgemeinen ist natürlich ein sehr großes Spektrum und muss daher differenziert werden. Unser Hauptaugenmerk liegt auf Check-PluginsBei einem Check Plugin handelt sich um eine Softwarekomponente, die von einem Monitoring-System wie Icinga verwendet wird, um die Verfügbarkeit und Leistung von IT-Systemen und/oder Diensten zu überwachen. Dabei ist zu beachten, dass ein Check Plugin meist eine sehr spezifische Funktionalität wie z.B. das Überprüfen einer AWS EC2 Instanz erfüllt. Neben diesem spezifischem Beispiel gibt es jedoch viele weitere Möglichkeiten und Szenarien, die Check Plugins erfüllen kann.

Individuelle Beratung und Entwicklung

Wird Entwicklungsarbeit angefordert, startet der Consultant vor Ort oder unsere Sales-Abteilung zunächst einen internen Prozess. Hierbei werden die Rahmeninformationen gesammelt, um einen groben Überblick der eigentlichen Entwicklungsarbeit zu bekommen. Um überhaupt abzuschätzen, welche Unterstützung wir dir bei deinem Projekt geben können, wird im nächsten Schritt zusammen mit einem Techniker eine Machbarkeitsanalyse durchgeführt.
In manchen Fällen stellt sich leider heraus, dass die Anforderung den Rahmen der von uns möglichen Entwicklungsarbeit überschreiten. In solchen Fällen setzen wir uns direkt mit den Auftraggeber:innen zusammen und arbeiten gemeinsam an einer zufriedenstellenden Lösung.

Sind die Rahmenbedingungen abgesteckt und mit dem Techniker evaluiert, geht es an die Plugin-Programmierung. Die Wahl der Programmiersprache fällt bei uns auf GoLang. Der Vorteil einer kompilierbaren Programmiersprache wie GoLang ist, dass das Binary welches am Ende „herausfällt“ theoretisch auf fast allen Systemen lauffähig ist.

Die Entwicklung selbst findet bevorzugt auf GitHub statt. Das sollte keine Überraschung sein, denn wir bei NETWAYS leben den Open Source-Gedanken bei all unseren Projekten. Zudem können die Auftraggeber:innen so immer den aktuellen Entwicklungsstand einsehen. Wenn die Anforderungen des Plugins erfüllt und eine releasefähige Version vorhanden ist, durchläuft es unseren internen QA Prozess, um letzte Probleme auszumerzen.
Ein anschließender Test des Plugins zusammen mit dem Kunden schließt das Projekt ab.

Interessiert? Einfach anfragen!

Jetzt bist du an der Reihe! Nutzt du in deinem Unternehmen Icinga und benötigst ein auf deine Bedürfnisse zugeschnittenes Check-Plugin? Du hast andere Softwarelösungen wie z.B. Prometheus oder Elasticsearch und suchst nach einer zu deinen Wünschen angepassten Schnittstelle? Dann setze dich jetzt unverbindlich mit meinen Kolleg:innen in Verbindung. Gemeinsam lassen wir deine Vorstellungen Realität werden!

Epische Entwicklungsumgebung in Eclipse

In letzter Zeit habe ich häufiger mit dem Thema Plugin Programmierung zu tun. Und da, wie letzte Woche schon geschrieben, die Programmiersprache meiner Wahl in den meisten Fällen Perl ist, suche ich schon seit längerem eine adäquate IDE. Nun gibt viele Wege ein Programm in Perl zu schreiben. Der auf jedem unixoiden System verfügbare Weg ist vi, mit vim sogar mit Syntax highlighting. Unter win-digen Umständen tut’s auch das notepad. Aber so richtig komfortabel sieht das alles nicht aus.
Eine wirklich gute Hilfe, die ich vor kurzem gefunden habe, ist die Erweiterung EPIC für Eclipse. Eclipse ist an und für sich als Entwicklungsumgebung für Java bekannt, viele kennen auch noch die Erweiterung für C/C++ aber dass Eclipse auch etwas für Perl bietet ist nicht jedem bekannt. Natürlich steht es wie Eclipse selber auch unter einer Open Source Lizenz, der Source Code kann daher hier bezogen werden, die Installation gestaltet sich aber ungleich einfacher wenn man den Eclipse Update Manager benutzt. Dieser befindet sich im Menü „Help“ unter „Install new Software“.
Trägt man hier die Adresse „http://e-p-i-c.sf.net/updates/testing“ ein, ist man nur noch einen Klick von der fertigen Installation entfernt.
Eclipse selber steht für die meisten Plattformen zur Verfügung. Entweder man installiert es unter der jeweiligen Linux Distribution direkt aus den Software Repositories oder man bezieht es von der Eclipse Homepage.

Vorteile

Ich kann hier in der kürze natürlich nicht alle Features aufzählen, die wichtigsten sind jedoch:

  • Syntax Highlighting
    Sieht nett aus und funktioniert richtig gut.
  • Syntax Validation
    Man muss nicht immer erst das Programm starten damit man merkt dass es doch nicht so tut wie man will
  • Debugger
    Erleichtert einem das debugging enorm durch die Möglichkeit Breakpoints zu setzen und den Wert von Variablen zur Laufzeit zu überprüfen und wahlweise auch zu ändern.
  • Wortvervollständigung
    für tippfaule, ein Druck auf Enter und das Wort ist da
  • Integrierte Hilfe
    Integration von perldoc. Man hält den Mauszeiger über einen Befehl und schon erscheint die Hilfe. (Wichtig: unter dem Menü Window \ Preferences muss der Pfad zu Perl vollständig und richtig hinterlegt sein)
  • Regex Testing Machine
    Gegen böse Überraschungen gut. Einfach mal testen ob der Regex auch das findet was man erwartet.
Christoph Niemann
Christoph Niemann
Senior Consultant

Christoph hat bei uns im Bereich Managed Service begonnen und sich dort intensiv mit dem internen Monitoring auseinandergesetzt. Seit 2011 ist er nun im Consulting aktiv und unterstützt unsere Kunden vor Ort bei größeren Monitoring-Projekten und PERL-Developer-Hells.

The glory of Perl

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.

Christoph Niemann
Christoph Niemann
Senior Consultant

Christoph hat bei uns im Bereich Managed Service begonnen und sich dort intensiv mit dem internen Monitoring auseinandergesetzt. Seit 2011 ist er nun im Consulting aktiv und unterstützt unsere Kunden vor Ort bei größeren Monitoring-Projekten und PERL-Developer-Hells.

OSMC 2009 – Official Nagios Plugin Development Team Meeting

Nagios Plugin Development Team meeting Seit letzter Woche steht es fest, die „Open Source Monitoring Conference 2009 on Nagios“ wird der offizielle Treffpunkt des Nagios Plugin Development Teams. Das Team, bestehend aus Ton Voon, Matthias Eble, Holger Weiss und Thomas Guyot-Sionnest arbeitet und entwickelt seit 2007 an bestehenden und neuen Plugins für das beliebte Open Source Monitoring Tool Nagios und veröffentlicht regelmäßig die  nagiosplug-Distribution.
Das Team trifft sich auf der diesjährigen OSMC 2009 mit dem Ziel, die aktuellen Trends rund um Nagios Plugins sowie den aktuellen Stand des Plugin Projekts zu besprechen. Neben den internen Besprechungen stehen die Mitglieder allen Interessierten im Rahmen des Meetings für Diskussionen, Anregungen und Gespräche zur Verfügung.
Nachdem der Call for Papers bereits seit drei Wochen läuft konnten bereits einige Referenten bestätigt werden, darunter unter Anderem Kristian Köhntopp (booking.com), Ton Voon (Projektleiter im Nagios Plugin Development Team und Nagios-Core Entwickler), Wolfgang Barth (Author des ersten Nagios Buches) und Michael Medin (Entwickler von NSClient++).  Die ständig aktualisierte Liste der Referenten findet sich auf den Sprecherseiten der OSMC 2009.
Wer selbst einen Vortrag auf der OSMC 2009 halten möchte, der Call for Papers läuft noch.