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!

Icinga for Windows 1.0 – Eine neue Ära

Seit heute ist der erste offizielle, stabile Release des Icinga für Windows Pakets in Version 1.0 verfügbar. Das Paket besteht aus drei individuellen Komponenten – dem Icinga PowerShell Framework, dem Icinga PowerShell Service und den Icinga PowerShell Plugins. In Kombination bilden sie den Grundbaustein für die künftige Überwachung von Windows Systemen – inklusive Software, Hardware und alles was dazugehört.

Neben der klassischen Überwachung der Windows Systeme geht das Framework aber noch einen Schritt weiter: Mit über 200 Cmdlets wird nicht nur das Monitoring an sich sichergestellt, sondern auch das Deployment der einzelnen Komponenten inklusive Icinga 2 Agent. Darüber hinaus wird die Verwaltung des Agents, die Konfiguration, aber auch das Troubleshooting auf Windows System deutlich vereinfacht: Für die gängigsten Befehle wurden Wrapper-Cmdlets entwickelt, mit denen neben dem Logfile-Tracing auch Features aktiviert und deaktiviert werden können, Icinga 2 Objects auslesbar und durchsuchbar gemacht wurden oder die Funktionsfähigkeit der Icinga 2 Installation auf dem lokalen System überprüft werden kann.

Vereinfachte Installation

Folgt man der Installationsanleitung, dann stellt man fest, dass die meisten Schritte vereinfacht über einen Installations-Wizard durchgeführt werden können. Der große Vorteil dabei ist, dass die Grundinstallation nur auf einem System vollständig manuell durchgeführt werden muss. Ist der Wizard erst einmal durchgeklickt, erhält man einen Konfigurations-String, der auf einem anderen System einfach ausgeführt werden kann, nachdem dort das Framework über den Kickstart installiert worden ist. Somit ist der künftige Rollout der Systeme einfacher denn je.

Standardisiertes Monitoring

Plugins bieten die Möglichkeit, schnell und effizient einzelne Komponenten zu überwachen. Die Schwierigkeit liegt darin, den Output der Plugins richtig zusammen zu bauen und Performance-Metriken sauber zu kapseln. Zum Schluss bleibt dann nur noch das Einpassen in das standardisierte Threshold-Verhalten der Icinga Plugins sowie die Ausführung der bekannten Prüfung, ob ein Wert nun Ok, Warning, Critical oder vielleicht doch Unknown ist.

All das wird mit dem Icinga PowerShell Framework deutlich vereinfacht, denn es werden einige Funktionen bereitgestellt, die sich genau um diese Tasks kümmern. Am Ende des Tages holt man sich einfache seine Daten über PowerShell Cmdlets und packt diese in ein Icinga Check-Objekt. Mit den Informationen, die das Objekt erhält, kann anschließend geprüft werden, welchen Status das Objekt hat und mittels einem Check-Result Objekt in ein gültiges Icinga 2 Format gebracht werden. Der Output ist anschließend für alle Plugins standardisiert.

Zeitintervall-Metriken

In der Vergangenheit lag der große Vorteil von Lösungen wie NSClient++ darin, dass diese als Dienst gestartet werden konnten und dabei Metriken gesammelt haben. Hierdurch konnte man auch auf Windows beispielsweise die CPU-Load in Intervallen von 1, 3, 5 und 15 Minuten in den Performance-Daten abbilden. Installiert man das PowerShell Framework als Dienst, ist dieser Zustand für jedes Plugin ebenfalls abbildbar. Hierfür ist lediglich der Background-Daemon für den Service Check mittels

Register-IcingaBackgroundDaemon -Command ‚Start-IcingaServiceCheckDaemon‘

zu registrieren. Anschließend können einzelne Service-Checks für die regelmäßige Ausführung konfiguriert werden. Möchte man für die CPU-Load alle 30 Sekunden Metriken für die Intervalle 1, 3, 5 und 15 Minuten sammeln, registriert man den Service-Check entsprechend

Register-IcingaServiceCheck -CheckCommand ‚Invoke-IcingaCheckCPU‘ -Interval 30 -TimeIndexes 1, 3, 5, 15;

Anschließend startet man den PowerShell Dienst neu und erhält alle Metriken in den gewünschten Intervallen:

Administrationsunterstützung

Wer den Icinga 2 Agent auf Windows administriert, muss auch hier öfter einmal die Konsole zur Hand nehmen und das Icinga 2 Binary mit diversen Befehlen starten. Das PowerShell Framework bietet auch hierfür einige Lösungen, da – wie bereits erwähnt – gängige Befehle in einem Wrapper-Cmdlet hinterlegt sind. Ein einfaches Parsen und stetiges Lesen der Logfiles erfolgt damit über einen einzigen Befehl – ohne am Ende in das Icinga Verzeichnis navigieren oder die Logdatei suchen zu müssen:

PS> Use-Icinga; Read-IcingaAgentLogFile
[2020-02-19 14:40:31 +0100] information/RemoteCheckQueue: items: 0, rate: 0/s (6/min 30/5min 90/15min);
[2020-02-19 14:40:41 +0100] information/RemoteCheckQueue: items: 0, rate: 0/s (12/min 60/5min 180/15min);

Sucht man mittels icinga2 object list nach bestimmten Check-Commands oder generellen Einträgen, gibt es auch hierfür eine elegante Lösung:

PS> Use-Icinga; Find-IcingaAgentObjects -Find ‚*CheckMemory*‘
Line #4948 => „Object ‚Invoke-IcingaCheckMemory‘ of type ‚CheckCommand‘:“
Line #4950 => “ * __name = „Invoke-IcingaCheckMemory““
Line #4955 => “ * value = „Use-Icinga; exit Invoke-IcingaCheckMemory““
Line #4958 => “ * value = „$IcingaCheckMemory_String_CriticalBytes$““
Line #4961 => “ * value = „$IcingaCheckMemory_Object_CriticalPercent$““
Line #4964 => “ * set_if = „$IcingaCheckMemory_Switchparameter_NoPerfData$““
Line #4967 => “ * value = „$IcingaCheckMemory_Int32_Verbosity$““
Line #4970 => “ * value = „$IcingaCheckMemory_String_WarningBytes$““
Line #4973 => “ * value = „$IcingaCheckMemory_Object_WarningPercent$““
Line #4986 => “ * name = „Invoke-IcingaCheckMemory““
Line #4994 => “ * templates = [ „Invoke-IcingaCheckMemory“, „plugin-check-command“, „PowerShell Base“, „plugin-check-command“, „plugin-check-command“ ]“

Damit wird die generelle Administration nicht nur einfacher, sondern mittels PowerShell Remote-Execution können auch mehrere Systeme gleichzeitg abgefragt und Statusinformationen eingesammelt werden.

Um sicherzustellen, dass der Agent korrekt ausgeführt wird, der Dienst gestartet werden kann und alle notwendigen Komponenten vefügbar sind, gibt es einen simplen Test, der alle Funktionalitäten überprüft:

Einfache Erweiterbarkeit

Alles in allem ist das Framework so gebaut, dass es eine solide Basis für weitere Entwicklungen bietet – sei es direkt von Seiten Icinga, NETWAYS oder aus der Community. Der Developer Guide bietet schon jetzt grundlegende Erklärungen und Erläuterungen und wird in den nächsten Wochen noch erweitert. Wer sein eigenes PowerShell Modul entwickeln möchte, um Plugins für die Überwachung oder eigene Background-Daemons bereitzustellen, der findet mit diesem Framework das nötige Werkzeug.

Live Webinar

Wer sich einen eigenen Eindruck über das Icinga PowerShell Framework und dessen zahlreiche Möglichkeiten machen möchte, der sei herzlich zu unserem Icinga for Windows – Einstieg“ Webinar am 11. März 2020 um 10:30 Uhr eingeladen. Wir freuen uns wie immer auf eine rege Teilnahme.

Wer Unterstützung bei der Installation und Konfiguration oder bei der Entwicklung eigener Plugins benötigt, kann natürlich gerne Kontakt mit uns aufnehmen. Ansonsten freuen wir uns natürlich über Feedback und breite Unterstützung aus der Community!

Christian Stein
Christian Stein
Manager Sales

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Manager Sales und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".

Monitoring Plug-Ins selbst gemacht

Es heißt ja immer mit Icinga ließe sich alles überwachen. Prinzipiell ist das auch richtig, aber manchmal gibt es einfach noch nicht das passende Plug-In. Da es aber schon Tausende Plug-Ins auf exchange.icinga.org gibt, kann es ja nicht so schwer sein ein eigenes Plug-In zu schreiben.

Was macht das Stück Code zum Plug-In?

Kürzeste Antwort: Der Exit Code. Jedes Nagios/Icinga/Shinken/Naemon Plug-In hat 4 Exit Codes. Diese Rückgabewerte lassen sich mit „echo $?“, nach dem Ausführen, überprüfen. Sie haben folgende Bedeutung: 0=OK, 1=Warning, 2=Critical, 3=Unknown

schulung_icinga2Was gibt es noch zu beachten?

Plug-Ins können in jeder auf dem jeweiligen System zur Verfügung stehenden Sprache geschrieben werden. Für einfache Fälle und schnelle Hilfe bietet sich Shell-Skripte an. Schöner sind oft aber perl oder python.
Ich möchte heute einmal ein schönes Shell Plugin schreiben. Um das umzusetzen lohnt sich als erstes ein Blick in die Monitoring Plugins Development Guidelines. Dort kann man unter anderem folgende Voraussetzungen für ein Plugin nachlesen.

Params

  • Es muss bei -h oder –help eine Hilfe bereitstellen
  • Es muss bei -v oder –verbose mehr Output liefern
  • Schwellwerte können als range definiert werden.
    „-c 5:  “ bedeutet z.B. alles kritisch, was unter 5 ist. Praktischerweise übernimmt die Interpretation der Ranges eine Funktion aus der utils.sh. Sie ist Bestandteil des Monitoring Plug-In Pakets

Perfdata

Plugins können Performancedaten ausgeben. Mit Hilfe dessen ist es tools wie pnp4nagios, ingraph oder graphite möglich Kurven über die ermittelten Werte zu zeichnen. Performancedaten müssen in folgendem Format vorliegen:
| ‚label’=value[UOM];[warn];[crit];[min];[max]
Also z.B. ‚Drive C‘ = 15GB;5;3;0;20 bedeutet folgendes: Drive C hat noch 15GB frei. Bei 3 bzw. 5 GB wird’s kritisch bzw. gewarnt.
Obacht: Es gibt nur bestimmte Maßeinheiten, die hier nachgelesen werden können. Diese sind s(Sekunden), %(Prozent), B (Bytes, auch MB KB usw) und c (counter)

Los geht’s

Nicht lang schnacken sondern losgelegt. Wir schreiben ein Plugin, dass die Files in /tmp zählt. Auf die gleiche Weise lassen sich auch alle anderen Plugins schreiben die auf zählbaren Werten basieren. mehr lesen…

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.