© Arthur Fatykhov, 123RF.com

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.

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.

Arbeitspferde

Poller: Die Schwerarbeit übernehmen Poller. Sie holen sich vom Scheduler Aufträge (Service- und Hostchecks) ab und sorgen dafür, dass ein Pool von Worker-Prozessen sie ausführt. Auch die Ergebnisse, Exitcodes und Ausgaben von Plugins erhält der Scheduler einmal pro Sekunde zugeschickt und wertet sie aus. Anders als bei Nagios sind hier bei der Übergabe der Checkergebnisse keine Dateien im Spiel. Die Kommunikation findet ausschließlich im Memory statt. Da beliebig viele Poller pro Scheduler laufen können, lassen sich Performance-Engpässe einfach durch Hinzufügen zusätzlicher Poller-Knoten beheben.

Reactionner: Ein weiterer Typ von Satellite-Prozess ist der Reactionner. Er ist im Prinzip genauso aufgebaut wie ein Poller, nur dass er keine Checks, sondern Eventhandler und Notification-Skripte abarbeitet. Auch hier gibt es wieder einen Prozess-Pool konfigurierbarer Größe. Der Vorteil dieses Daemon liegt auf der Hand, wenn man bedenkt, dass das Vorbild Nagios während der Ausführung eines Eventhandlers für andere Aufgaben blockiert ist.

Broker: Für die Anbindung externer Tools ist der Broker-Prozess zuständig. Er entspricht den Nagios Event Broker Modules. Bei jedem Event (Statusänderung eines Service, Einlesen der Konfiguration, Downtime und so weiter) steckt der Scheduler eine Datenstruktur, genannt Brok, in eine Queue, die der Broker-Prozess im Sekundentakt ausliest. Was mit diesen Informationen geschieht, ist konfigurierbar. Dem Broker lassen sich mehrere so genannte Module zuweisen, die den Code zur Weiterverarbeitung enthalten. Bereits jetzt gibt es Module für eine NDO-Datenbank, eine Merlin-Datenbank, für Host- und Service-Perfdata-Files und vieles mehr.

Auf diese Weise lassen sich anfallende Daten leicht durch ein entsprechendes Modul an alle möglichen Fremdsysteme schicken. Auch hier gilt wieder: Anders als bei Nagios bringt zum Beispiel eine hängende Datenbank nicht das gesamte Monitoring zum Stehen. Auch das Schrei-ben der teils sehr großen Datei »status.dat« bremst nicht einen zentralen Prozess, sondern geschieht hier asynchron.

Loadbalancing

Alle bis zu diesem Punkt vorgestellten Prozesse können bei Shinken auch mehrfach vorhanden sein, um die Aufgabenlast dadurch besser zu verteilen. Sie müssen noch nicht einmal auf demselben Rechner laufen.

Das einigermaßen bekannte Nagios-Addon DNX ist eine Nagios-Erweiterung, bei der spezialisierte Worker-Prozesse die Ausführung der Plugins übernehmen. Damit entlasten sie einerseits den Nagios-Prozess und verteilen andererseits die Ausführung von Plugins auf eine Reihe unterschiedlicher Server.

Ein vergleichbares Loadbalancing lässt sich mit Shinken recht einfach bewerkstelligen. Der Anwender muss dazu lediglich mehrere Poller in der Datei »shinken-specific.cfg« konfigurieren und dafür sorgen, dass sie auf mehreren Rechnern starten. Und schon verteilt sich die Last gleichmäßig zwischen ihnen (Abbildung 2). Die zugehörige Konfiguration könnte so aussehen, wie es der Auszug in Listing 1 zeigt.

Abbildung 2: Lastverteilung und auch Failover realisiert Shinken durch Bordmittel. Was bei Nagios kompliziert war, geht hier einfacher von der Hand.

01 define poller{ 
02 poller_name poller-All-1 
03 address shinken1.muc 
04 port 7771 
05 realm All 
06 } 
07 define poller{ 
08 poller_name poller-All-2 
09 address shinken2.muc 
10 port 7771 
11 realm All 
12 }

Auch eine Ebene höher, beim Scheduler, lässt sich im Bemühen um höhere Ausfallsicherheit ansetzen. Konfiguriert der Anwender nämlich mehrere Scheduler, so zerteilt anschließend der Arbiter die Konfiguration. Im Ergebnis hat jeder Scheduler ungefähr die gleiche Anzahl an Services zu bearbeiten. Mit Hilfe des Attributs »weight« ist dabei auch eine Gewichtung möglich. Auf diese Weise bietet Shinken mehrere Möglichkeiten, administrative Aufgaben wie das Scheduling und Schwerstarbeiten wie das Ausführen von Plugins auf mehrere Prozesse und/oder Server zu verteilen.

Doppelte Daemons sorgen für Ausfallsicherheit

Bei Ausfällen können so genannte Spare Daemons Schäden am Gesamtsystem verhindern. Sie erhalten nach dem Start zunächst noch keine Aufgaben zugewiesen. Stürzt aber ein aktiver Prozess ab, springt sofort ein solcher Spare-Prozess für ihn ein. Diese Absicherung ist für jeden beliebigen Typ von Daemon vorgesehen. Ein Beispiel dafür demonstriert das Listing 2.

01 define poller{
02  poller_name poller-All-1
03  address shinken1.muc
04  port 7771
05  realm All
06 }
07 ...
08 define poller{
09  poller_name poller-All-spare
10  address shinken9.muc
11  port 7771
12  realm All
13  spare 1
14 }

Auf dem Knoten Shinken1 läuft ein Poller-Prozess namens »poller-All-1« und führt kontinuierlich Plugins aus. Stürzt nun dieser Prozess oder – was wahrscheinlicher ist – der ganze Server Shinken1 ab, so bemerkt dies der Arbiter. Dieser schickt daraufhin dem Poller auf dem Knoten Shinken9 die Aufforderung einzuspringen. Dieser wendet sich nun seinerseits an den zuständigen Scheduler, holt sich von dort Arbeitsaufträge und führt sie aus. Die Ergebnisse schreibt er wieder in die Ergebnisqueue des Schedulers zurück.

Für den Scheduler hat sich dadurch im Grunde nichts geändert: Wer sich von ihm Checkaufträge abholt und -resultate zurückschreibt, ist dem Scheduler egal.

Kommunikation spart Forks

Die Kommunikation zwischen den Prozessen bewerkstelligt Shinken mit Hilfe des Pyro-Moduls (Python Remote Objects). Betrachtet man ein verteiltes Nagios-System, bei dem beispielsweise zwei Nagios-Instanzen jeweils 1000 aktive Checks im 5-Minuten-Takt ausführen und deren Ergebnisse per »send_nsca« an eine zentrale Instanz übermitteln, so bedeutet dies:

• Drei Forks/Sekunde auf jedem aktiven Knoten für
  »send_nsca«
• Drei Dateien/Sekunde, die jeder aktive Knoten erzeugt und
  wieder löscht
• Sechs Forks/Sekunde des NCSA-Daemon auf dem Master-Knoten

Bei Shinken würde dieses Szenario so aussehen, dass ein Scheduler zwei Poller besitzt, die ihre Checkergebnisse mittels Pyro direkt in seine Result-Queue schreiben. Dafür sind lediglich Netzwerk- und Hauptspeicheroperationen erforderlich. Datei-Operationen und Forks finden dabei nicht statt.

Realms

Eine Neuerung, die es bei Nagios nicht gibt, sind die Realms. Damit lassen sich Scheduler, Poller, Reactionner und Broker zu einem logischen Verbund gruppieren. Weist man nun Hosts oder Hostgroups das optionale Realm-Attribut zu, bearbeitet sie ausschließlich der entsprechende Prozessverbund. Da Shinken-Prozesse auf unterschiedlichen Servern laufen können, lässt sich auf diese Weise ein verteiltes System aufbauen. Bei Nagios sind dazu noch individuelle Konfigurationen für die einzelnen Standorte nötig oder das teilweise Abschalten von aktiven Checks.

Shinken dagegen zerlegt eine einzige Nagios-Konfiguration automatisch und verteilt sie so an die Poller, dass diese selbst über Kontinente hinweg Hosts dort checken, wo sie stehen (Abbildung 3). Konkret bedeutet das, dass die Überwachung der Clients in einer amerikanischen Niederlassung auch ein amerikanischer Poller durchführt.

Abbildung 3: Beim verteilten Monitoring – sei es auch über Ländergrenzen und Erdteile hinweg – sorgen Domänen für kurze Wege.

Fundamente

Durch die Programmierung in Python ist Shinken auf allen Systemen lauffähig, für die eine Implementierung dieser Skriptsprache existiert. Darunter fällt auch Windows, sodass Shinken ohne Portierungsaufwand auf Microsoft-Betriebssystemen einzusetzen ist. Für kleine Firmen, die Open-Source-Monitoring benutzen wollen, aber nicht über Unix-Know-how verfügen, eröffnet dies sicherlich eine interessante Alternative.

Aber auch für große Umgebungen sind Szenarien denkbar, bei denen ein Teil der Monitoring-Infrastruktur unter Windows läuft. Man könnte beispielsweise alle Windows-Clients dem Realm »windows« zuordnen und dafür eigene Scheduler und vor allem Poller vorsehen. Sämtliche Windows-Checks würden in diesem Fall auf dedizierten Windows-Pollern ausgeführt.

Aufbau einer Testumgebung

Shinken ist im jetzigen Stadium noch nicht für den produktiven Einsatz vorgesehen. Dem interessierten Admin sei hier aber dennoch eine Methode vorgestellt, die es mit wenig Aufwand erlaubt, bereits heute ein Gefühl für die Handhabung von Shinken zu bekommen. Es gibt ja sowohl durch die unterschiedlichen Prozesse als auch neue Konfigdateien deutliche Unterschiede zu Nagios.

Zunächst erzeugt der Admin am besten ein temporäres Verzeichnis, das sowohl die Sources von Shinken als auch sämtliche Konfigurationsdateien und Plugins enthält. Dieses Verzeichnis lässt sich dann nach dem Abschluss der Tests wieder löschen, sollte Shinken nicht überzeugen können. Die Shinken-Quellen hostet Sourceforge.

Die jeweils neuesten Sourcen lädt sich der Tester dort mit den folgenden Git-Kommandos herunter:

cd /tmp/shinken_test
git clone git://shinken.git.sourceforge.net
/gitroot/shinken/shinken

Dadurch erhält er ein Verzeichnis »shinken«. Darin wiederum befindet sich das Unterverzeichnis »src«. Aus ihm lässt sich nachher das System starten.

Als sehr praktisch erweist sich das Perl-Modul Monitoring::Generator::TestConfig von Sven Nierlein, das automatisch Testkonfigurationen erstellt [1]. Man erzeugt damit einen Satz von Konfigurationsdateien inklusive Plugins, die sich ausschließlich in einem wählbaren Verzeichnis befinden und keine Abhängigkeiten außerhalb dieses Verzeichnisses besitzen. Um eine lebendige Umgebung zu simulieren, ändern sich die Zustände von Hosts und Services je nach Einstellung mehr oder weniger häufig. Das Perl-Skript aus Listing 3 erzeugt im Verzeichnis »/tmp/shinken_test« so eine Simulationsumgebung.

01  use Monitoring::Generator::TestConfig;
02  my $mgt = Monitoring::Generator::TestConfig->new(
03  output_dir => "/tmp/shinken_test",
04  layout =>     "shinken",
05  binary =>     "/usr/local/nagios/bin/nagios",
06  overwrite_dir => 1,
07  hostcount => 10, # frei waehlbar
08  routercount => 1, # frei waehlbar
09  services_per_host => 10, # frei waehlbar
10  host_settings => {
11  check_period => "24x7",
12  },
13  service_settings => {
14  check_interval => 5,
15  retry_interval => 1,
16  },
17  # nur falls ein eigener shinken-user
18  # eingerichtet wurde. ansonsten aktueller user.
19  main_cfg => {
20    nagios_user =>  "shinken",
21    nagios_group => "shinken",
22  },
23 );
24 $mgt->create();

Durch den Aufruf des Skripts entstehen nun die erzeugten Dateien unter »/tmp/shinken_test/«. Exemplarisch für die Daemon-Konfigurationsdateien soll es an dieser Stelle um das File »brokerd.cfg« gehen, weil der Nutzer in dieser Datei noch eine Anpassung vornehmen muss (Listing 4).

01 [daemon]
02 workdir=/tmp/shinken_test/var
03 pidfile=%(workdir)s/brokerd.pid
04 interval_poll=5
05 maxfd=1024
06 port=7772
07 host=0.0.0.0
08 user=shinken
09 group=shinken
10 idontcareaboutsecurity=no
11 modulespath=/tmp/shinken_test/shinken/src/modules

Allen Daemon-Konfigurationsdateien gemeinsam sind die Parameter »workdir«, »pidfile«, »port«, »host«, »user«, »group« und »idontcareaboutsecurity«. Sie dürften weitgehend selbsterklärend sein und geben an, wo das PID-File liegt, auf welchem Port und gegebenenfalls unter welcher IP-Adresse der Daemon lauscht und unter welcher Benutzerkennung er laufen soll. Der letzte Parameter »idontcareaboutsecurity« ist nur dann von Bedeutung, wenn der Daemon unter dem Root-Account laufen soll. Dies ist im Regelfall nicht gestattet. Gibt es einen zwingenden Grund dafür, ist besagter Parameter auf »yes« zu setzen.

Broker-Konfiguration

Für den Broker ist noch das Verzeichnis wichtig, aus dem er die einzelnen Verarbeitungsmodule nachlädt. Dazu trägt der Admin als Argument von »modulespath« den entsprechenden Pfad ins Testverzeichnis ein. In diesem Beispiel lautet der Pfad »/tmp/shinken_test/src/modules«.

Auch ein Blick in die neue Datei »shinken-specifig.cfg« bietet sich an dieser Stelle an. In ihr sind sämtliche Komponenten einer Shinken-Installation hinterlegt. Primär dient diese Datei dem Arbiter, der mit ihrer Hilfe das Gesamtsystem überwacht und einzelne Mitglieder fernsteuert.

Vor dem ersten Start von Shinken ist zunächst der Broker (Listing 5) so zu konfigurieren, dass mindestens zwei Module vorhanden sind. Das ist zum einen Simple-log, das für das Schreiben einer Logdatei analog zu Nagios zuständig ist. Außerdem empfiehlt sich der Einsatz des Moduls vom Typ »status_dat«. Es sorgt dafür, dass es die Dateien »objects.cache« und »status.dat« gibt. Sie sind notwendig, wenn man mit der Weboberfläche einer vorhandenen Nagios-Installation einen Blick auf die laufende Shinken-Instanz werfen möchte.

01 define broker{
02  broker_name broker-All
03  address localhost
04  port 7772
05  spare 0
06  realm All
07  manage_sub_realms 1
08  manage_arbiters 1
09  modules Status-Dat,Simple-log
10  }
11 
12 define module{
13  module_name Simple-log
14  module_type simple_log
15  path /tmp/shinken_test/var/nagios.log
16 }
17 
18 define module{
19  module_name Status-Dat
20  module_type status_dat
21  status_file /tmp/shinken_test/var/status.dat
22  object_cache_file /tmp/shinken_test/var/objects.cache
23  status_update_interval 15
24 }

Start frei

Nach dem Abschluss dieser Vorbereitungen lässt sich nun das Shinken-System starten. Dazu begibt sich der Tester in das Verzeichnis »/tmp/shinken_test/shinken/src« und führt nacheinander die folgenden Kommandos aus (Listing 6). Der Parameter »-d« bewirkt, dass die Programme im Hintergrund laufen. Neugierige können ihn auch weglassen und jeden der Prozesse in einem eigenen Fenster starten. Auf diese Weise können sie auch leicht mitlesen, welche Informationen welcher Prozess jeweils zur Laufzeit ausgibt.

01 cd /tmp/shinken_test/shinken/src
02 python shinken-broker.py -d -c /tmp/shinken_test/etc/brokerd.cfg
03 python shinken-reactionner.py -d -c /tmp/shinken_test/etc/reactionnerd.cfg
04 python shinken-poller.py -d -c /tmp/shinken_test/etc/pollerd.cfg
05 python shinken-scheduler.py -d -c /tmp/shinken_test/etc/schedulerd.cfg
06 python shinken-arbiter.py -d -c /tmp

Wie bereits angesprochen ist es möglich, die CGIs einer vorhandenen Nagios-Installation zu benutzen, um eine Weboberfläche für das soeben gestartete Shinken zu bekommen. Dazu ist weiter nichts nötig, als in der Datei »/usr/local/nagios/etc/cgi.cfg« den Parameter »main_config_file« auf den Wert »/tmp/shinken_test/nagios.cfg« zu setzen.

Alternativ kann der Admin auch den Broker so konfigurieren, dass er mit Hilfe eines Merlin-DB-MySQL-Moduls in eine Datenbank schreibt. So eine Merlin-Datenbank ist die Grundlage für das Webfrontend Ninja [2]. Es gibt auch eine virtuelle Maschine mit diesem Aufbau, sie ist inzwischen allerdings schon etwas älteren Datums [3].

Ausblick

Das Projekt Shinken befindet sich noch in einer frühen Phase. Jean Gabès hat ganze Arbeit geleistet, aber ein paar Dinge noch nicht implementiert, was bei einer Proof of Concept auch nicht üblich ist. Vorrangiges Ziel der Entwickler ist die hundertprozentige Kompatibilität zu Nagios (bezüglich der Konfigurationsdateien). Sie dürfte spätestens im Mai 2010 erreicht sein. Danach wird Jean Gabès voraussichtlich noch einmal an Ethan Galstad appellieren, Shinken als Basis für künftige Nagios-Versionen einzusetzen. Weitere Informationen, darunter die Roadmap, sind auf der Webseite des Projekts [4] zu finden. (jcb)