Nagios
# Nagios

Nagios ist eine Software zum Service-Monitoring komplexer IT-Infrastrukturen.
Nagios bietet dazu eine Sammlung von Modulen zur Überwachung von Netzwerken, Hosts und speziellen Diensten sowie eine Web-Schnittstelle zum Abfragen der gesammelten Daten. Es steht unter der GNU GPL, ist also freie Software und läuft unter zahlreichen Unix-ähnlichen Betriebssystemen. Nagios und das Nagios-Logo sind in den USA eingetragene Warenzeichen von Ethan Galstad.
Der Name Nagios ist offiziell ein rekursives Akronym, welches sich auf den ursprünglichen Namen der Software (NetSaint) bezieht, und bedeutet ausgeschrieben Nagios Ain't Gonna Insist On Sainthood, inoffiziell wird er jedoch auch als Synonym für den früheren Namen interpretiert (Network + griechisch ἅγιος hagios ‚heilig‘).
2007 wurde die Nagios Enterprises LLC von Ethan Galstad gegründet, welche Consulting und technische Unterstützung rund um das Thema Nagios als kommerzielle Dienstleistung anbietet. Die Kern-Software selbst bleibt weiterhin unter einer freien Lizenz.

## Arbeitsweise
### Zentrale Begriffe der Konfiguration und Komponenten

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.

### Software-Komponenten

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.

### Überwachungsmethoden

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, 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).

### Überwachungsmodule und ihre Standards

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 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.

### Alarmierungslogik

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.

### Meldewege

Nagios alarmiert die vorkonfigurierten Kontaktpersonen über diverse Kanäle (zum Beispiel E-Mail, SMS, Pager, IM-Messages, 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).

### Distributed Monitoring

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.

## Zusatzprogramme

Nagios kann mit Add-ons erweitert werden. Beispiele hierfür sind:
* Nmap2Nagios-NG: Add-on zur automatischen Generierung von Konfigurationsdateien
* Centreon: Add-on zur Konfiguration und zum Monitoring via Webinterface
* Nagvis: Add-on zur Visualisierung der Überwachungsergebnisse
* monarch: (Veraltete) Administrationsoberfläche für Nagios 1.x und 2.x
* Groundwork Monitor Community Edition: Administrationsoberfläche für Nagios 2.x und 3.x (Nachfolger von Monarch)
* NConf: Webgestützte Administrationsoberfläche für Nagios 3.x
* NagiosQL: Webgestützte Administrationsoberfläche für Nagios 2.x, 3.x und 4.x
* PerfParse: Datenbankanbindung zur Verarbeitung der von Nagios gesammelten „Performancedaten“
* PNP: Tool zur Generierung von Graphen aus den von Nagios gelieferten Daten
* Check MK: Add-on zum vereinfachten und beschleunigten Betriebssystem- und SNMP-Monitoring
* Nagios Business Process AddOns: Erweiterung um statt einzelne Komponenten ganze Anwendungen („Geschäftsprozesse“) zu überwachen
* NagiosGrapher: Tool zur Generierung von Graphen anhand von Nagios-Performancedaten, welches sich automatisch ins Web-Front-End von Nagios einbettet
* NagiosEventDB: Ereignisdatenbank für Nagios z. B. für SNMPTraps, Syslog-Meldungen, …
* N2RRD Add-on für Nagios zum Speichern der Performance-Daten in Round-Robin-Datenbanken; enthält zusätzlich den Viewer „rrd2graph“, mit dem sich die gespeicherten Daten betrachten lassen
* Nagios-virt: Zur Überwachung von virtuellen Maschinen mithilfe der libvirt-Schnittstelle.
* Thruk: Verbesserte Weboberfläche für große und verteilte Umgebungen
* Mod-Gearman: Add-on für verteiltes Monitoring
Weiterhin gibt es Programme, die Nagios überwachen und Ereignisse melden:
* Nagios-Checker: ein Add-on für Mozilla Firefox
* nagstamon: Nagios-Status-Monitor für den Desktop
* NagiosCenter: Webanwendung mit Übersichten, um mehrere Nagios-Server gleichzeitig zu betreiben und zu überwachen

## Forks
### Icinga

Im Mai 2009 hat eine Gruppe von Nagios-Entwicklern den Nagios-Fork Icinga gegründet. 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.

### Shinken

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 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.

### Naemon

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, nachdem er als Hauptentwickler von Nagios Enterprises aus dem Entwicklerteam ausgeschlossen worden war. 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.

## Kritik
### Trademarkpolitik

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, ehemals nagios-fr.org
* 23. Mai 2012: monitoring-portal.org, ehemals nagios-portal.de
* 16. Januar 2014: monitoring-plugins.org, ehemals nagios-plugins.org

### Nagios-Plugin Übernahme

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 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.