Open Source im professionellen Einsatz
Linux-Magazin 04/2010
© Arthur Fatykhov, 123RF.com

© Arthur Fatykhov, 123RF.com

Ein neuer Nagios-Fork bietet bereits vielversprechende Features

Auf Messers Schneide

Nagios, der Platzhirsch unter den Open-Source-Monitoringsystemen, scheint zu straucheln. Zwar hat sich die Software als De-facto-Standard etabliert und selbst große Unternehmen setzen sie ein, aber seit geraumer Zeit stagniert die Entwicklung. Konkurrenten rücken auf.

872

Die letzte große Innovation erlebte das Nagios-Projekt Ende 2005 mit den NDO-Utils - die sich bis heute im Betastadium befinden. Danach gab es zwar im März 2008 noch die Release 3.0, ansonsten blieb es aber beim Beseitigen von Bugs. An der Architektur von Nagios hat sich seit der Gründung des Projekts vor zehn Jahren nichts geändert. Ein großes Problem bei Nagios war lange, dass es nur einen einzigen Entwickler gab, Ethan Galstad, der sich zuletzt immer seltener auf der Devel-Mailingliste zu Wort meldete. Dieser Engpass hatte zur Folge, dass zum Teil wichtige Patches der Community monatelang auf Halde lagen.

Der Nagios-Fork Icinga vom Frühjahr 2009 sorgte zwar kurzzeitig für ein Strohfeuer und die Aufnahme zweier weiterer Entwickler ins Nagios-Team, kann aber nachhaltig wenig an der Situation ändern. Es steht zu befürchten, dass niemand Nagios in seiner derzeitigen Form weiterentwickelt - vielleicht abgesehen von Korrekturreleases. Es gibt weder eine Roadmap noch eine aktive Diskussion über die Zukunft des Projekts.

Auch das Erscheinen von Nagios XI, eines kommerziellen Produkts auf Basis des freien Nagios-Core, lässt vermuten, dass Ethan Galstad seine eigenen Interessen verfolgt. Das ist zweifellos sein gutes Recht, erzeugt aber mit Blick auf die Zukunft von Nagios bei so manchem Beobachter ein ungutes Gefühl.

Gleichzeitig schläft die Konkurrenz nicht. Weitere Open-Source-Systeme wie Zabbix oder Open NMS fassen ebenfalls im Enterprise-Segment Fuß. Deren zahlreiche und aktive Entwickler haben auch aus den Schwächen der Konkurrenz gelernt und machen es einem Nagios-Fan zunehmend schwer, Argumente für den Einsatz seines Systems zu finden. Insbesondere verteilte Umgebungen sind mit Nagios nur sehr umständlich abzubilden, da sie im ursprünglichen Design niemals vorgesehen waren.

Nicht zuletzt profitieren die Konkurrenzsysteme vom Einsatz moderner Programmiersprachen und -methoden. Dagegen wirkt der zehn Jahre alte C-Code von Nagios altbacken. Tatsächlich ist dies auch ein Grund, warum die Nagios-Entwickler vor Änderungen zurückschrecken, die über Bugfixes hinausgehen. Der Code ist schlichtweg nicht mehr wartbar.

Was ist Shinken?

Die Gefahr, dass ein Newcomer Nagios verdrängen könnte, erkannte der Franzose Jean Gabès im Sommer 2009 und nahm daraufhin ein ehrgeiziges Projekt in Angriff. In sehr kurzer Zeit programmierte er Shinken, eine Neuimplementierung von Nagios in der Skriptsprache Python. Ende des Jahres stellte Jean Gabès Shinken als Proof of Concept vor und forderte nicht weniger, als die Entwicklung einer künftigen Version 4 von Nagios nun auf der Basis von Shinken anzupacken.

Damit, so seine Hoffnung, wäre Nagios technisch dann wieder so positioniert, dass es auch die nächsten zehn Jahre gegen Konkurrenten bestehen könne. Von Seiten des Nagios-Erfinders Ethan Galstad erfolgte keinerlei Reaktion, sodass Jean Gabès sich unter diesen Umständen entschloss Shinken als einen neuen Fork von Nagios weiterzuentwickeln.

Die Architektur

Was ist nun, außer der verwendeten Programmiersprache, das Bahnbrechende an Shinken? Anders als bei Nagios gibt es keinen einzelnen Prozess, der wie die berühmte eierlegende Wollmilchsau sowohl für das Lesen der Konfiguration als auch für das Scheduling, das Ausführen von Checks, für sonstige Skripte und vieles mehr zuständig ist. Bei Shinken laufen mehrere Prozesse, die jeweils nur einen Teil der Aufgaben, diesen jedoch so performant wie möglich abarbeiten und sich dabei gegenseitig nicht blockieren. Es gibt fünf verschiedene Prozesse in einem Shinken-System (Abbildung 1):

Abbildung 1: Einen Nagios-Prozess ersetzen beim Shinken-Minimalsystem fünf Prozesse.

Arbiter: Dieser Prozess - der wichtigste - startet als letzter. Er liest die Konfigurationsdateien und prüft deren Gültigkeit. Nachdem er die Konfiguration aufbereitet und in eine interne Darstellung in Form von Python-Objekten überführt hat, absolviert er gegebenenfalls einen Schritt, der eine Besonderheit von Shinken und auch für den Namen des Projekts verantwortlich ist. Hat der Anwender mehrere Scheduler definiert, zerlegt der Arbiter die Konfiguration in Portionen, so genannte Packs, und verteilt sie zu gleichen Teilen auf die Scheduler. Shinken ist ein scharfes japanisches Schwert, das dem Autor Jean Gabès die Idee zu diesem Namen geliefert hat.

Im Unterschied zu Nagios kennt Shinken eine zweite Konfigurationsdatei, die in der Regel »shinken-specific.cfg« heißt. Sie enthält Informationen, aus welchen Prozessen das Gesamtsystem besteht und wie diese über das Netzwerk zu erreichen sind. Dadurch weiß der Arbiter, wo welche Prozesse laufen und wer mit wem kommuniziert. Den Pfad zu dieser neuen Konfigurationsdatei enthält eine bekannte »cfg_file«-Direktive in »nagios.cfg«.

Hat er die Konfiguration verteilt, kümmert sich der Arbiter um die Überwachung des Shinken-Gesamtsystems. Er pingt die einzelnen Komponenten an und versendet Updates, wenn etwa durch einen Ausfall anschließend eine Neukonfiguration der Kommunikationswege erforderlich geworden ist.

Scheduler: Der Scheduler ist dafür zuständig, über den Status der ihm zugewiesenen Hosts und Services Buch zu führen und für die Ausführung von Checks, Eventhandlern und Notifications zu sorgen. Er entscheidet auch, wann ein Ausfall zu einem Alarm führt und welche Abhängigkeiten dabei zu berücksichtigen sind. Es gehört jedoch nicht zu seinen Aufgaben, die Service- und Hostchecks, Eventhandler und Notificationskripte selber auszuführen. Dafür sind die so genannten Satellite-Prozesse (Poller und Reactionner) zuständig. Der Scheduler schreibt lediglich entsprechende Arbeitsaufträge in Queues, die die Satellites im Sekundentakt auslesen und abarbeiten. Die Ergebnisse landen wiederum in einer Queue, die diesmal der Scheduler liest.

Linux-Magazin kaufen

Einzelne Ausgabe
 
Abonnements
 
TABLET & SMARTPHONE APPS
Bald erhältlich
Get it on Google Play

Deutschland

Ähnliche Artikel

comments powered by Disqus

Ausgabe 01/2017

Digitale Ausgabe: Preis € 6,40
(inkl. 19% MwSt.)

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.