Nagios

Der eigentliche Nagios-Prozess basiert im Wesentlichen auf einer objektorientierten Konfiguration von

Hosts

die im Wesentlichen über ihre IP-Adresse definiert sind,

Services

die zu überwachenden Eigenschaften eines Host,

Kommandos

die zur Überwachung, zur Alarmierung oder anderen Zwecken ausgeführt werden sollen und

Kontakten

die im Alarmfall zu verständigen sind.

Ein „Service“ kann dabei ein von einem Host zur Verfügung gestellter Dienst (z. B. HTTP, FTP, SSH, …), eine interne Eigenschaft eines Host (z. B. der noch verfügbare Festplattenplatz, Speicher- und CPU-Auslastung, Uptime, interne Fehlermeldungen, …) oder die über entsprechende Zusatzhardware messbaren Umweltbedingungen (z. B. Temperaturwerte, Luftfeuchtigkeit, Füllstände von Flüssigkeitstanks, …) sein.

Für eine einfache Grundinstallation von Nagios ist die Installation zumindest noch folgender Software-Komponenten erforderlich:

• Der Apache HTTP Server mit PHP-Modul
• Der GCC-Compiler mit bzw. nur dessen Entwicklungs-Programmbibliotheken

Neben der Nagios-Kern-Software benötigt man noch die Nagios-Plug-ins: Das sind eine Reihe von Zusatzprogrammen (Modulen), die die eigentlichen Überwachungsabfragen durchführen und (gemäß ggf. vorzugebender Parameter) auswerten.

Da einige Testmethoden auf Protokollebene arbeiten (TCP, UDP, SNMP, …), ist es möglich, verschiedene Betriebssysteme, aber auch Netzwerkgeräte oder andere technische Geräte mit einer entsprechenden, für die Überwachung eingerichteten Netzwerkschnittstelle (z. B. eine USV) zu überwachen.

Zur Überwachung interner Eigenschaften von Rechnern müssen Plug-ins meist direkt auf den Hosts ausgeführt werden. Dazu ist z. B. ein exekutiver Fernzugriff auf den Host erforderlich, was aber entweder bei sicherem Zugriff z. B. per SSH mit einer unverhältnismäßigen CPU-Belastung (auf beiden Seiten) verbunden ist oder wegen der für die Ausführung erforderlichen administrativen Privilegien als sicherheitsbedenklich erachtet wird. Eine andere Möglichkeit ist die Installation weiterer Programme („Add-ons“) auf den Hosts, die nur lokal vorkonfigurierte (und damit nicht missbrauchbare) Systemabfragen ausführen können (standardmäßig NRPE[4], der Nagios Remote Plugin Executor, oder z. B. auch NSClient oder NC_Net). Die Kommunikation zwischen diesen Programmen und dem Nagios-Server (Abfrage und Ergebnisübermittlung) erfolgt dann über eigene definierbare Netzwerk-Ports.

Eleganter, wenn auch schwieriger zu konfigurieren, ist die passive Überwachung z. B. mit dem Add-on Nagios Service Check Acceptor (NSCA) oder via SNMP-Traps (z. B. mittels des Frontends NagTrap).

Neben den Standardmodulen und einer Vielzahl weiterer kostenlos verfügbarer Nagios-Plug-ins können auch eigene Module auf einfache Weise mit Hilfe einer Programmiersprache, wie z. B. Perl, C, C++, Java, C#, Python oder PHP erstellt werden. Die Module müssen lediglich die Nagios-Richtlinien für Plug-ins[5] beinhalten, d. h. vor allem müssen sie bei ihrer Beendigung den ermittelten Status als POSIX-konformen Rückgabewert an den aufrufenden Prozess (Nagios-Dienst) übergeben und Ausgaben an die Standardausgabe tätigen.

Der Statuswert teilt hierbei mit,

• ob das überprüfte Objekt (Dienst/Host) in Ordnung war (OK, Wert 0),
• ob es zu einer Warnmeldung kam (WARNING, Wert 1),
• ob es sich um einen kritischen Fehler handelte (CRITICAL, Wert 2) oder
• der Status nicht ermittelbar/unbekannt ist (UNKNOWN, Wert 3).

Bei vielen Überprüfungen kann man beim Aufruf des Moduls als Parameter Alarmschwellenwerte für Warn- und Fehlerzustände angeben: Über- oder unterschreitet der Messwert diese Grenzwerte, ändert sich der Status des Dienstes entsprechend.

Die Daten, die an die Standardausgabe gesendet werden, enthalten normalerweise eine Statusmeldung, eventuell weitere Detailinformationen und ggf. auch Messwerte und werden 1:1 in der Web-Oberfläche als Zusatzinformationen angezeigt. Die so erfassten Messwerte („Performancedaten“) können weiter bearbeitet und insbesondere für eine Langzeiterfassung gespeichert werden. An diese Möglichkeit knüpfen diverse Zusatzprogramme zur Erstellung von Graphen an.

Sobald ein Dienst bzw. ein Host den Status ändert und nach einer vorkonfigurierbaren Anzahl von Wiederholungen der Abfrage bei diesem Status bleibt, wird der geänderte Status als gegeben angesehen („hard state“) und erst dann folgen weitere Aktionen:

• Es wird ein Alarm ausgelöst, wobei untereinander bestehende Abhängigkeiten durch entsprechende Konfiguration berücksichtigt werden können: So kann man alle zusätzlich überwachten Eigenschaften eines Hosts als abhängig von der Erreichbarkeit des Hosts definieren und so bei einem Ausfall des Hosts die Meldungen über dessen einzelne Dienste unterdrücken.
• Es können vorkonfigurierte Ereignisaktionen gestartet werden.

Nagios alarmiert die vorkonfigurierten Kontaktpersonen über diverse Kanäle (zum Beispiel E-Mail, SMS, Pager, IM-Messages[6], Telefonanrufe, …). Dabei besteht auch die Möglichkeit, festzulegen, in welcher Reihenfolge Meldungen an weitere Kontaktpersonen erfolgen sollen, wenn eine Störung nach den ersten Meldungen nicht behoben wurde (Eskalationsmanagement).

Um ein Nagios-System ausfallsicher, redundant und fehlalarmsicherer zu gestalten, gibt es die Möglichkeit des Setups als Distributed Monitoring sowie des Redundant/Failover-Monitoring. Bei verteiltem Monitoring werden mehrere, dezentral installierte Nagios-Instanzen genutzt, die ihre Ergebnisse mittels NSCA an einen zentralen Nagios-Server senden, der sie als passive Checks verarbeitet. Bei redundantem Monitoring arbeiten zwei Nagios-Instanzen parallel wie bei einem Clusternode und halten sich mit einem Heartbeat gegenseitig auf dem Laufenden. Neben der NSCA-Methode gibt es auch hierauf spezialisierte Erweiterungen wie Mod-Gearman, Merlin oder DNX.

Im Mai 2009 hat eine Gruppe von Nagios-Entwicklern den Nagios-Fork Icinga gegründet.[7] Er zeichnet sich durch eine modernere Weboberfläche aus, zusätzliche Datenbankkonnektoren (Beispielsweise für MySQL und PostgreSQL) und einen dynamischeren Entwicklungsprozess als Nagios, so dass Patches schneller angewendet werden und mehr Rücksicht auf die Community genommen wird.

Im Sommer 2009 begann Jean Gabès, Nagios in der Programmiersprache Python neu zu programmieren. Die schleppende Weiterentwicklung des in die Jahre gekommenen C-Codes und die monolithische Architektur von Nagios hatten ihn zu diesem Schritt veranlasst. Sein Proof of Concept mit dem Namen Shinken verteilt die Aufgaben des Monitoring-Systems auf mehrere spezialisierte und ggf. redundant vorhandene Prozesse und soll dadurch in der Lage sein, eine weitaus größere Zahl von Endgeräten zu überwachen als ein herkömmliches Nagios-System. Im Dezember 2009 schlug Jean Gabès auf der nagios-devel-Mailingliste[8] vor, Shinken als Grundlage für ein künftiges Release 4 von Nagios zu verwenden. Dieser Vorschlag wurde von einigen Mitgliedern der Mailingliste begrüßt, aber es wurden auch deutliche Zweifel laut, ob die Programmiersprache C wirklich ersetzt werden sollte, weil unter anderem nicht mehr die Kompatibilität mit anderer Software gegeben wäre. Obwohl dieses Angebot weiterhin gilt, wird Shinken seitdem als eigenständiges Projekt entwickelt.[9]

Im Oktober 2013 kündigte Andreas Ericsson, der Hauptentwickler der Nagios-Core-Version 4 einen neuen eigenen Fork Naemon (Networks, Applications and Event Monitor) an,[10] nachdem er als Hauptentwickler von Nagios Enterprises aus dem Entwicklerteam ausgeschlossen worden war.[11] Naemon ist wie die bisherigen Versionen von Nagios in der Programmiersprache C geschrieben, die CGI-Weboberfläche wurde jedoch durch die Thruk-FastCGI-Oberfläche (Perl) ersetzt. Naemon wird unter der GNU GPL veröffentlicht.

Nagios Enterprise gerät zunehmend wegen seiner rigiden Trademarkpolitik in die Kritik. So mussten sich mehrfach Opensource-Projekte und -Websites, welche den Namen Nagios verwendeten, auf Druck von Nagios Enterprise umbenennen. Vorangegangen ist jeweils eine Auseinandersetzung über Namensnennung von Nagios im Zusammenhang mit daraus hervorgegangenen Forks.

• 23. Februar 2010: monitoring-fr.org,[12] ehemals nagios-fr.org
• 23. Mai 2012: monitoring-portal.org,[13] ehemals nagios-portal.de
• 16. Januar 2014: monitoring-plugins.org,[14] ehemals nagios-plugins.org

Am 15. Januar 2014 wurde ohne Rücksprache die Website des bis dahin unabhängig geführten Nagios-Plugins-Projekts auf Webserver der Nagios Enterprise LLC umgezogen. Das bisherige Team nannte sich daraufhin in Monitoring-Plugins um und führt das Projekt seither auf monitoring-plugins.org[15] fort. Als Grund hierfür nannte Ethan Galstad eine vorangegangene Auseinandersetzung über die Nennung von Nagios-Forks (Naemon, Icinga und Shinken) auf der Nagios-Plugins-Website.