Monitoring mit Nagios Holger Weiß Zentraleinrichtung für Datenverarbeitung (ZEDAT) Freie Universität Berlin 1. Dezember 2005
Gliederung 1 Konzept Hosts versus Services Nagios Plugins NRPE und NSCA Performance Daten 2 Konfiguration Überblick Objekt-Definitionen Hosts Services Contacts und Contactgroups Commands Templates und Gruppierung Sonstige Konfigurationsdateien
Hosts versus Services Nagios überwacht zunächst Services Services können Dienste wie z. B. HTTP, SMTP oder POP3 sein Aber auch beliebige andere, irgendwie messbare Daten eines Systems Beispielsweise Load, Plattenbelegung, Anzahl aktiver User, Größe der Mailqueue etc.
Hosts versus Services Nagios überwacht zunächst Services Services können Dienste wie z. B. HTTP, SMTP oder POP3 sein Aber auch beliebige andere, irgendwie messbare Daten eines Systems Beispielsweise Load, Plattenbelegung, Anzahl aktiver User, Größe der Mailqueue etc.
Hosts versus Services Jeder Service ist einem Host zugeordnet Solange der Service-Check einen OK Status zurückgibt, geht Nagios davon aus, dass auch der entsprechende Host UP ist Erst wenn ein Service ausfällt, prüft Nagios den Status des Hosts Abhängig vom Ergebnis wird entweder ein Host- oder ein Service-Alert ausgelöst
Hosts versus Services Jeder Service ist einem Host zugeordnet Solange der Service-Check einen OK Status zurückgibt, geht Nagios davon aus, dass auch der entsprechende Host UP ist Erst wenn ein Service ausfällt, prüft Nagios den Status des Hosts Abhängig vom Ergebnis wird entweder ein Host- oder ein Service-Alert ausgelöst
Hosts versus Services Vorteile: Hosts werden nur bei Bedarf gepingt Aus einem Alert lässt sich schliessen, ob es sich um einen Hostoder Service-Problem handelt Bei Bedarf können je nachdem, ob es sich um ein Host- oder Service-Problem handelt, unterschiedliche Admins kontaktiert werden
Nagios Plugins Nagios selbst prüft weder Hosts noch Services Sämtliche Checks werden über Plugins realisiert»plugins«sind externe Kommandos, die von Nagios aufgerufen werden Plugins können also in beliebigen Sprachen geschrieben werden: C, Perl, Shell,... Es gibt ein»offizielles«plugin-paket, im Netz finden sich viele weitere Plugins
Nagios Plugins Nagios selbst prüft weder Hosts noch Services Sämtliche Checks werden über Plugins realisiert»plugins«sind externe Kommandos, die von Nagios aufgerufen werden Plugins können also in beliebigen Sprachen geschrieben werden: C, Perl, Shell,... Es gibt ein»offizielles«plugin-paket, im Netz finden sich viele weitere Plugins
Nagios Plugins Nagios selbst prüft weder Hosts noch Services Sämtliche Checks werden über Plugins realisiert»plugins«sind externe Kommandos, die von Nagios aufgerufen werden Plugins können also in beliebigen Sprachen geschrieben werden: C, Perl, Shell,... Es gibt ein»offizielles«plugin-paket, im Netz finden sich viele weitere Plugins
Nagios Plugins Das Plugin-Interface ist simpel: Nagios prüft den Status eines Hosts oder Services anhand des Return Code des Plugins Return Codes: 0 - OK 1 - WARNING 2 - CRITICAL 3 - UNKNOWN Darüber hinaus wird eine Zeile Text von STDOUT gelesen Diese Zeile erscheint im Webinterface und ggf. in Alerts Beispiel: SMTP CRITICAL - Socket timeout after 15 seconds
Nagios Plugins Das Plugin-Interface ist simpel: Nagios prüft den Status eines Hosts oder Services anhand des Return Code des Plugins Return Codes: 0 - OK 1 - WARNING 2 - CRITICAL 3 - UNKNOWN Darüber hinaus wird eine Zeile Text von STDOUT gelesen Diese Zeile erscheint im Webinterface und ggf. in Alerts Beispiel: SMTP CRITICAL - Socket timeout after 15 seconds
Beispiel-Plugin 1 #!/bin/sh 2 3 LOAD=`uptime sed -E s/.+ (.+)\..+/\1/ ` 4 5 if [ -z "${LOAD}" ]; then 6 echo "LOAD UNKNOWN - Cannot get system load" 7 exit 3 8 elif [ ${LOAD} -gt 50 ]; then # load greater than 50 9 echo "LOAD CRITICAL - System load is ${LOAD}" 10 exit 2 11 elif [ ${LOAD} -gt 20 ]; then # load greater than 20 12 echo "LOAD WARNING - System load is ${LOAD}" 13 exit 1 14 fi 15 echo "LOAD OK - I m feeling good" 16 exit 0
Nagios Plugins Übliche Kommandozeilenoptionen: -H, --hostname=address -P, --port=integer -w, --warning=float -c, --critical=float -t, --timeout=integer -v, --verbose
Nagios Plugins Testen von Plugins: Aufruf via Kommandozeile Normalerweise keine manpages, Hilfe via -h oder -help
Nagios Plugins Testen von Plugins: Aufruf via Kommandozeile Normalerweise keine manpages, Hilfe via -h oder -help
Nagios Plugins Auch Host Checks werden via Plugins vorgenommen Üblicherweise check_ping oder check_icmp Die Plugin Return Codes und Meldungen sind dieselben wie im Fall von Service Checks Nagios»übersetzt«die Return Codes im Fall von Host Checks jedoch in einen UP bzw. DOWN Status
Nagios Plugins Auch Host Checks werden via Plugins vorgenommen Üblicherweise check_ping oder check_icmp Die Plugin Return Codes und Meldungen sind dieselben wie im Fall von Service Checks Nagios»übersetzt«die Return Codes im Fall von Host Checks jedoch in einen UP bzw. DOWN Status
Nagios Plugins Vorteil des Plugin-Konzepts: Neue Service-Checks sind einfach zu implementieren Nachteil: Performance/Skalierbarkeit Aber optional für Perl-Plugins: Nagios»Embedded Perl Interpreter«Die kompilierten Perl-Skripts können gecached werden Derzeit setzen wir beides nicht ein
Nagios Plugins Vorteil des Plugin-Konzepts: Neue Service-Checks sind einfach zu implementieren Nachteil: Performance/Skalierbarkeit Aber optional für Perl-Plugins: Nagios»Embedded Perl Interpreter«Die kompilierten Perl-Skripts können gecached werden Derzeit setzen wir beides nicht ein
Nagios Plugins Vorteil des Plugin-Konzepts: Neue Service-Checks sind einfach zu implementieren Nachteil: Performance/Skalierbarkeit Aber optional für Perl-Plugins: Nagios»Embedded Perl Interpreter«Die kompilierten Perl-Skripts können gecached werden Derzeit setzen wir beides nicht ein
NRPE und NSCA Lokale Plugins können natürlich nur lokale Daten auf dem Nagios-System oder Services auf Remote-Systemen, die über das Netz ansprechbar sind, prüfen Um Services auf Remote-Systemen zu prüfen, die nicht via IP erreichbar sind, bietet Nagios zwei Alternativen: NRPE und NSCA
NRPE und NSCA Lokale Plugins können natürlich nur lokale Daten auf dem Nagios-System oder Services auf Remote-Systemen, die über das Netz ansprechbar sind, prüfen Um Services auf Remote-Systemen zu prüfen, die nicht via IP erreichbar sind, bietet Nagios zwei Alternativen: NRPE und NSCA
NRPE und NSCA NRPE (der»nagios Remote Plugin Executor«) ist ein Client/Server-Paar Auf dem zu prüfenden Remote-System wird der NRPE-Server installiert Nagios ruft den NRPE-Client auf, dieser verbindet sich mit dem NRPE-Server, welcher auf dem Remote-System ein Nagios-Plugin aufruft und das Ergebnis zurückgibt Wir setzen NRPE nicht ein
NRPE und NSCA NRPE (der»nagios Remote Plugin Executor«) ist ein Client/Server-Paar Auf dem zu prüfenden Remote-System wird der NRPE-Server installiert Nagios ruft den NRPE-Client auf, dieser verbindet sich mit dem NRPE-Server, welcher auf dem Remote-System ein Nagios-Plugin aufruft und das Ergebnis zurückgibt Wir setzen NRPE nicht ein
NRPE und NSCA NSCA (der»nagios Service Check Acceptor«) ist ebenfalls ein Client/Server-Paar Jedoch läuft der Server hier auf dem Nagios-System, während der Client auf dem Remote-System installiert wird Auf dem Remote-System können Ergebnisse von Service-Checks über den NSCA-Client an den NSCA-Server übermittelt werden, welcher die Daten an Nagios weitergibt»passive Service Check«weil Nagios nicht aktiv ein Plugin aufruft Wir setzen NSCA derzeit für Kaspersky ein
NRPE und NSCA NSCA (der»nagios Service Check Acceptor«) ist ebenfalls ein Client/Server-Paar Jedoch läuft der Server hier auf dem Nagios-System, während der Client auf dem Remote-System installiert wird Auf dem Remote-System können Ergebnisse von Service-Checks über den NSCA-Client an den NSCA-Server übermittelt werden, welcher die Daten an Nagios weitergibt»passive Service Check«weil Nagios nicht aktiv ein Plugin aufruft Wir setzen NSCA derzeit für Kaspersky ein
NRPE und NSCA NSCA (der»nagios Service Check Acceptor«) ist ebenfalls ein Client/Server-Paar Jedoch läuft der Server hier auf dem Nagios-System, während der Client auf dem Remote-System installiert wird Auf dem Remote-System können Ergebnisse von Service-Checks über den NSCA-Client an den NSCA-Server übermittelt werden, welcher die Daten an Nagios weitergibt»passive Service Check«weil Nagios nicht aktiv ein Plugin aufruft Wir setzen NSCA derzeit für Kaspersky ein
Performance Daten Nagios kennt nur den Status von Hosts und Services Performance-Daten o. ä. werden nicht ausgewertet Plugins können jedoch Performance-Daten übermitteln, welche dann in eine Datei geschrieben oder an ein externes Kommando (beispielsweise RRDtool) übergeben werden können Nagios hält alles, was im Plugin-Output einem» «-Zeichen folgt, für Performance-Daten Beispiel: SMTP OK - The MTA is happy response_time=0.2
Performance Daten Nagios kennt nur den Status von Hosts und Services Performance-Daten o. ä. werden nicht ausgewertet Plugins können jedoch Performance-Daten übermitteln, welche dann in eine Datei geschrieben oder an ein externes Kommando (beispielsweise RRDtool) übergeben werden können Nagios hält alles, was im Plugin-Output einem» «-Zeichen folgt, für Performance-Daten Beispiel: SMTP OK - The MTA is happy response_time=0.2
Überblick Die Nagios-Konfiguration kann auf beliebig viele Dateien aufgesplittet werden, Ausgangspunkt ist etc/nagios.cfg. Dort werden eine Reihe von globalen Optionen gesetzt, wie z. B. Dateipfade, Timeouts, Logging, Service-Check Scheduling etc. Die Syntax ist hier schlicht variable = value Üblicherweise setzt man hier auch die Pfade zu weiteren Konfigurationsdateien cfg_file gibt eine Konfigurationsdatei an, cfg_dir ein Konfigurationsverzeichnis Beide Variablen können wiederholt verwendet werden, um mehrere Dateien/Verzeichniss anzugeben
Überblick Die Nagios-Konfiguration kann auf beliebig viele Dateien aufgesplittet werden, Ausgangspunkt ist etc/nagios.cfg. Dort werden eine Reihe von globalen Optionen gesetzt, wie z. B. Dateipfade, Timeouts, Logging, Service-Check Scheduling etc. Die Syntax ist hier schlicht variable = value Üblicherweise setzt man hier auch die Pfade zu weiteren Konfigurationsdateien cfg_file gibt eine Konfigurationsdatei an, cfg_dir ein Konfigurationsverzeichnis Beide Variablen können wiederholt verwendet werden, um mehrere Dateien/Verzeichniss anzugeben
Überblick In den via cfg_dir angegebenen Verzeichnissen (und deren Unterverzeichnissen) liesst Nagios alle *.cfg Dateien ein. Seit Nagios 2.0b5 funktioniert das auch vernünftig ;-) Bei uns gibt es folgende cfg_dir Verzeichnisse: etc/commands etc/contacts etc/hosts etc/services etc/misc Hier werden Nagios»Objekte«definiert
Überblick In den via cfg_dir angegebenen Verzeichnissen (und deren Unterverzeichnissen) liesst Nagios alle *.cfg Dateien ein. Seit Nagios 2.0b5 funktioniert das auch vernünftig ;-) Bei uns gibt es folgende cfg_dir Verzeichnisse: etc/commands etc/contacts etc/hosts etc/services etc/misc Hier werden Nagios»Objekte«definiert
Objekt-Definitionen Objekt-Definitionen sehen immer wie folgt aus: define <type> { directive1 = value1 directive2 = value2 }
Objekt-Definitionen Es gibt folgende Objekt-Typen (die jeweils eine Vielzahl von Direktiven kennen): host hostgroup hostdependency hostextinfo service servicegroup servicedependency serviceextinfo contact contactgroup command timeperiod
Hosts Die zu überwachenden Hosts können via IP oder Hostname spezifiziert werden Hostnamen sind leichter zu pflegen, haben aber den Nachteil, dass Alerts ausgelöst werden, wenn DNS kaputt ist Wir verwenden ausschliesslich Hostnamen Host-Definitionen können optional parent Direktiven enthalten Ein parent ist der letzte Router oder Switch vor dem Host Auf diese Weise kann Nagios testen, ob ein Host wirklich down oder ob ein Router/Switch auf dem Weg zum Host ausgefallen ist und dann entsprechende Alerts produzieren
Hosts Die zu überwachenden Hosts können via IP oder Hostname spezifiziert werden Hostnamen sind leichter zu pflegen, haben aber den Nachteil, dass Alerts ausgelöst werden, wenn DNS kaputt ist Wir verwenden ausschliesslich Hostnamen Host-Definitionen können optional parent Direktiven enthalten Ein parent ist der letzte Router oder Switch vor dem Host Auf diese Weise kann Nagios testen, ob ein Host wirklich down oder ob ein Router/Switch auf dem Weg zum Host ausgefallen ist und dann entsprechende Alerts produzieren
Services Das Intervall von Service-Checks wird über folgende Direktiven bestimmt: normal_check_interval Check-Intervall, wenn Status OK retry_check_interval Check-Intervall, wenn Status!= OK max_check_attempts Wieviele Non-OK-Versuche, bevor der Service als kaputt klassifiziert wird?
Contacts und Contactgroups Die Kontaktdaten der Admins, die Nagios-Alerts erhalten sollen, werden in contact Definitionen angegeben. Diese werden in contactgroups gruppiert Die jeweils zuständigen contactgroups werden dann in den Host- und Service-Definitionen angegeben
Commands Sowohl Host-/Service-Checks als auch die Kommandos zum Versand der Nagios-Alerts werden mittels command Definitionen spezifiziert Beispiel: define command { command_name check_ping command_line $USER1$/check_ping \ -H $HOSTADDRESS$ -p $ARG1$ } Host-/Service-Definitionen können dieses Kommando dann wie folgt verwenden: check_command check_ping!5
Templates und Gruppierung Hosts, Services (und Kontakte) können in Gruppen zusammengefasst werden Dies beeinflusst zum einen die Darstellung im Webinterface, Zum anderen können die Gruppen in Objekt-Definitionen referenziert werden Darüber hinaus kennt Nagios»Templates«: Objekt-Definitionen können die Direktiven aus anderen Objekte mittels use Direktive»erben«Das neue Objekt kann wiederum vererbt werden, so dass eine»baumstruktur«gebaut werden kann Allerdings kann ein gegebenes Objekt nicht aus mehreren Objekten erben (use kann nur einmal verwendet werden) Mittels Templates und Gruppierung lässt sich Redundanz in der Konfiguration recht gut reduzieren
Templates und Gruppierung Hosts, Services (und Kontakte) können in Gruppen zusammengefasst werden Dies beeinflusst zum einen die Darstellung im Webinterface, Zum anderen können die Gruppen in Objekt-Definitionen referenziert werden Darüber hinaus kennt Nagios»Templates«: Objekt-Definitionen können die Direktiven aus anderen Objekte mittels use Direktive»erben«Das neue Objekt kann wiederum vererbt werden, so dass eine»baumstruktur«gebaut werden kann Allerdings kann ein gegebenes Objekt nicht aus mehreren Objekten erben (use kann nur einmal verwendet werden) Mittels Templates und Gruppierung lässt sich Redundanz in der Konfiguration recht gut reduzieren
Templates und Gruppierung Hosts, Services (und Kontakte) können in Gruppen zusammengefasst werden Dies beeinflusst zum einen die Darstellung im Webinterface, Zum anderen können die Gruppen in Objekt-Definitionen referenziert werden Darüber hinaus kennt Nagios»Templates«: Objekt-Definitionen können die Direktiven aus anderen Objekte mittels use Direktive»erben«Das neue Objekt kann wiederum vererbt werden, so dass eine»baumstruktur«gebaut werden kann Allerdings kann ein gegebenes Objekt nicht aus mehreren Objekten erben (use kann nur einmal verwendet werden) Mittels Templates und Gruppierung lässt sich Redundanz in der Konfiguration recht gut reduzieren
Sonstige Konfigurationsdateien timeperiods.cfg»arbeitszeiten«, bei uns: 24x7 ;-) cgi.cfg Webinterface Konfiguration (Pfade, Authentisierung) resources.cfg Private Makros für Pfade oder auch sensible Daten wie Passwörter (wird von den CGIs nicht gelesen)
Sonstige Konfigurationsdateien timeperiods.cfg»arbeitszeiten«, bei uns: 24x7 ;-) cgi.cfg Webinterface Konfiguration (Pfade, Authentisierung) resources.cfg Private Makros für Pfade oder auch sensible Daten wie Passwörter (wird von den CGIs nicht gelesen)
Sonstige Konfigurationsdateien timeperiods.cfg»arbeitszeiten«, bei uns: 24x7 ;-) cgi.cfg Webinterface Konfiguration (Pfade, Authentisierung) resources.cfg Private Makros für Pfade oder auch sensible Daten wie Passwörter (wird von den CGIs nicht gelesen)
Command File Named Pipe für passive Checks, Downtimes und viele weitere Laufzeit-Kommandos Um Nagios beispielsweise neu zu starten: [1041175870] RESTART_PROGRAM;1041175870 Beispielsweise müsste ein Kommandozeilen-Tool, das das Webinterface ersetzt, in diese Datei schreiben
Webinterface Das Nagios-Webinterface ist»optional«, bietet aber Features, die out-of-the-box nicht anders zu haben sind, insbesondere: Detaillierte Status-Übersicht Problem-Acknowledgements Scheduling von Downtimes Konfigurationsänderungen nicht empfehlenswert Alternative zum Webinterface: nsc (Nagios Console Monitor) Bietet nur Status-Übersicht Acknowledgements und Scheduling von Downtimes sind mit nsc nicht möglich
Webinterface Das Nagios-Webinterface ist»optional«, bietet aber Features, die out-of-the-box nicht anders zu haben sind, insbesondere: Detaillierte Status-Übersicht Problem-Acknowledgements Scheduling von Downtimes Konfigurationsänderungen nicht empfehlenswert Alternative zum Webinterface: nsc (Nagios Console Monitor) Bietet nur Status-Übersicht Acknowledgements und Scheduling von Downtimes sind mit nsc nicht möglich