Nagios 3. Administrationsleitfaden

Transkript

1 Institut für Informatik Nagios 3 Administrationsleitfaden Martin Steinbach Oktober 2008 martin-luther-universität halle-wittenberg

2 Inhaltsverzeichnis 1 Die Installation von Nagios Anforderungen Installation unter Debian Übersicht über relevante Verzeichnisse Konfiguration des Nagios-Servers Grundlegende Konfiguration nagios.cfg Übersicht über die wichtigsten Plugins Kommandos einrichten Neue Hosts anlegen Neue Services anlegen Gruppen Für Nagios benötigte Dienste Webserver Mail Transfer Agent Konfiguration der Clients Nagios Remote Plugin Executor Xinetd Secure Shell Webinterface Detailansichten Monitoring-Ansichten Prozessansichten Reporting Legende Abbildungs- und Tabellenverzeichnis 30 2

3 1 Die Installation von Nagios Nagios lässt sich über viele Wege installieren. Man kann sich den Sourcecode von der Homepage des Nagiosprojektes herunterladen 1 oder die Paketverwaltung der meisten Linux - Distributionen verwenden. Im Institut wird als Serverbetriebssystem hauptsächlich Debian verwendet, es bietet mit mehr als Paketen eine riesige Softwareauswahl in der auch Nagios angeboten wird. 1.1 Anforderungen Die Anforderungen an den Nagios-Server sind im Allgemeinen sehr gering, können allerdings sehr hoch werden, je nachdem wie viele Dienste und Clients überwacht werden sollen. Auch die Auslastung der zu überwachenden Clients gilt es zu beachten. Ein System welches an sich schon einen Flaschenhals darstellt sollte man nicht mit zu vielen Tests belasten. Die erhöhte Netzlast kann ebenfalls eine Rolle spielen, insbesondere wenn die Datenübetragung das Internet passiert. Nagios läuft auf nahezu jedem POSIX 2 -kompatiblen Unix System, unter Anderem: AIX, HP-UX, Solaris und GNU/Linux. Voraussetzungen dafür sind ein funktionierender C - Compiler und ein Webserver mit CGI - Schnittstelle. Empfohlen wird der Gnu C Compiler (gcc) und Apache als Webserver Portable Operating System Interface Martin Steinbach 3 von 30

4 1.2 Installation unter Debian Installiert wird das Paket mit dem Paketverwaltungstool Aptitude: # aptitude update && aptitude install nagios3 Folgendes Listing zeigt die direkten Abhängigkeiten des Nagios 3 Paketes (Stand 10/2008): libc6 ( 2.7) libgd2-noxpm ( ) libjpeg62 libperl5.10 libpng12-0 ( ) perl zlib1g ( 1.1.4) nagios3-common Über das Paket nagios3-common werden auch der Apache Webserver und die benötigten Nagiosplugins installiert. 1.3 Übersicht über relevante Verzeichnisse Die Nagiosinstallation erstreckt sich über das gesamte System; hier eine Übersicht über die wichtigsten Ordner, in denen Debian relevante Dateien für Nagios abgelegt hat. Tabelle 1.1: Verzeichnisübersicht Verzeichnisse Konfiguration /etc/nagios3/ Dokumentation /usr/share/doc/nagios3/ Startskript /etc/init.d/nagios3/ Html - Dateien /usr/share/nagios3/htdocs/ CGI - Binarys /usr/lib/cgi-bin/nagios3/ Log - Datei /var/log/nagios3/ Martin Steinbach 4 von 30

5 2 Konfiguration des Nagios-Servers Die Konfiguration von Nagios wird hauptsächlich über die Konfigurationsdateien im /etc/nagios3 Verzeichnis vorgenommen. Die wichtigste Datei ist nagios.cfg, dort stehen alle Nagios direkt betreffenden Parameter und die Pfade der optionalen Konfigurationsdateien. Nagios unterscheidet zwischen der Hostkonfiguration und der Servicekonfiguration, ein Service kann für mehrere Hosts verfügbar sein. Die von der Host- und Servicekonfiguration aufgerufenen Kommandos werden in der commands.cfg, Zeitperioden in timeperiods.cfg und Kontaktdaten in contact.cfg angegeben. Das Debian Paket bietet schon eine sinnvoll editierte nagios.cfg an, so dass in diesem Kapitel nur auf wesentliche und wichtige Parameter der nagios.cfg eingegangen wird. Im Gegensatz dazu wird besonderes Augenmerk auf die Einrichtung der zu überwachenden Rechner und Services gelegt, insbesondere auf das Hinzufügen neuer Hosts und Services. Martin Steinbach 5 von 30

6 2.1 Grundlegende Konfiguration Der Nagiosdienst läuft auf inf-stat.informatik.uni-halle.de, einem der zahlreichen VServer des Instituts. Um eine übersichtliche Konfiguration zu gewährleisten, wurde die Struktur der Konfigurationsdateien den Anforderungen gemäß angepasst. Dabei wurden größtenteils die vom Debianpaket bereitgestellten Konfigurationsdateien entfernt oder das Laden dieser in der Konfigurationsdatei nagios.cfg ausgeschlossen: Tabelle 2.1: Übersicht Konfigurationsdateien Verzeichnisse Funktion /etc/nagios3/ nagios.cfg Hauptkonfiguration commands.cfg Kommandokonfiguration apache2.conf Webserverkonfiguration cgi.cfg Plugin -Konfiguration /etc/nagios3/common/ contacts.cfg Kontaktdefinition timeperiods.cfg Zeitperioden /etc/nagios3/servers/ arbeitsgruppen-server.cfg Hostkonfiguration-AGs linux-server.cfg Hostkonfiguration-Linux unix-server.cfg Hostkonfiguration-Solaris windows-server.cfg Hostkonfiguration Windows groups.cfg Gruppendefinition services.cfg Servicekonfigurationen cluster-services.cfg Clusterkonfiguration nagios.cfg Der Aufbau der Konfigurationsdatei ist übersichtlich und durchdacht. Am Zeilenanfang stehen Optionen, denen Werte zugewiesen werden. Dabei ist darauf zu achten, dass man keine Leerzeichen oder Nicht-ASCII-konforme Zeichen verwendet. Kommentare werden, wie in Unix-Konfigurationsdateien üblich, durch eine Raute eingeleitet. -Adresse des Nagiosadmins, diese kann über das Makro $ADMIN $ als Kontakt verwendet werden. cfg_dir=/etc/nagios3/common cfg_dir=/etc/nagios3/servers Martin Steinbach 6 von 30

7 Alle.cfg Dateien aus diesen Ordnern werden in die Konfiguration eingebunden. cfg_file=/etc/nagios3/commands.cfg Mittels der Option cfg_file kann eine einzelne Datei in die Konfiguration eingebunden werden. debug_level=0 Diese Option legt fest, welche Informationen von Nagios protokolliert werden. Dies ist besonders bei der Fehlersuche nützlich. Wichtige Werte sind: -1 = alle Informationen 0 = Debugging ist deaktiviert 2 = Konfigurationsinformationen 4 = Prozessinformationen 16 = Host und Servicechecks debug_verbosity=1 Hier gibt man die Geschwätzigkeit des Debugging an, wobei der Wert 0 grundlegende Informationen und der Wert 2 Informationen ausgibt die lediglich für Entwickler interessant sind. Als sinnvolle Einstellung sollte der Wert 1 gesetzt sein. enable_flap_detection=1 Wenn dieser Schalter aktiviert ist, so ist Nagios in der Lage Hosts und Services mit ständig wechselnden Zuständen zu erkennen. Damit können unnötig viele Benachrichtigungen verhindert werden. enable_notification=1 Diese Option legt global fest, ob Benachrichtigungen versendet werden können. host_check_timeout=30 service_check_timeout=60 Wird ein Host- oder Serviceheck-Ergebnis nicht in angegebener Zeit (in sec.) geliefert, so bricht Nagios diesen Test ab. log_file=/var/log/nagios3/nagios.log In dieser Logdatei stehen alle Fehler und Ergebnisse der Checks. Diese Datei sollte nur mit der Nagios eigenen Logrotation rotiert werden. log_rotation_method=d Martin Steinbach 7 von 30

8 Gibt an, wie oft eine Logdatei in das Verzeichnis /var/log/nagios3/archives gesichert wird. Mögliche Werte sind: n = keine Archivierung d = täglich 00:00 Uhr h = zu Beginn jeder Stunde w = in der Nacht von Sonntag zum Samstag m = an jedem Monatsersten 00:00 Uhr nagios_group=nagios nagios_user=nagios Gruppen- und Benutzerrechte mit denen Nagios läuft. Nutzer müssen auf dem System existieren. Sie sollten allerdings kein Passwort besitzen, damit kein Login von außerhalb möglich ist Übersicht über die wichtigsten Plugins Die von Nagios ausgeführten Tests werden ausschließlich über sogenannte Plugins realisiert. Nagios wertet diese Daten dann aus, erstellt Benachrichtigungen und archiviert die Ergebnisse. Debian liefert in dem Paket nagios-plugins die gängigsten Nagiosplugins als Binärdateien mit. Diese befinden sich nach der Installation des Paketes im Verzeichnis /usr/lib/nagios/plugins/ und sind nach dem Schema check_ressource benannt, sie sollten für die gängigsten Überwachungslösungen ausreichend sein. Falls jedoch spezielle Plugins benötigt werden, kann man sich diese entweder selbst schreiben (z.b. als Bash-Skript) oder aber die Nagios -Tauschbörse 1 durchsuchen. Es wird zwischen plattformunabhängigen Plugins, die Netzwerkdienste überwachen und Plugins für das Prüfen von lokalen Ressourcen unterschieden. Netzwerkressourcen Da die Nagiosplugins eigenständige Programme darstellen, können sie auch ohne Nagios aufgerufen werden. Fast alle Plugins unterstützen folgende Standardoptionen, mit denen sie aufgerufen werden können: -h - Ausgabe der Hilfe -V - Versionsausgabe -v - Verbose Mode ( Geschwätzigkeit ) -H - Als Argument Hostname oder IP-Adresse des zu prüfenden Ziels -w - Spezifikation der Warnschwelle -c - Spezifikation der kritischen Schwelle 1 Martin Steinbach 8 von 30

9 Ein Beispielaufruf eines Plugins soll die Funktion und das System der Rückgabewerte verdeutlichen. # check_ldap -3 -H example.com -b o=example,c=com -p 389 -D Bindname -w C 0.1 -c 1.0 LDAP OK seconds response time time= s;;; Dieser Check hat ein OK ausgelöst, kein WARNING und kein CRITICAL. Damit Nagios auf die Plugins zugreifen kann, müssen diese als Kommando in der Nagioskonfiguration definiert werden, mehr dazu in Pluginübersicht: Check_ping verwendet das Unix-Kommando Ping um die Erreichbarkeit eines Rechners über das Netz festzustellen, als Schwellenwerte werden Antwortzeit des ICMP-Echo-Response- Paketes und deren Verluste in Prozent angegeben. Werte werden in Millisekunden bzw. in Prozent angegeben: -c antwortzeit,paketverlust -c 500.0,20% # check_ping -H example.com -w 5,0,20% -c 7.0,60% Check_icmp ist nicht auf externe Hilfsmittel angewiesen, es schickt kleinere ICMP-Echo- Requests und ist damit effizienter. Da die Abwärtskompatibilität zu check_ping gegeben ist, sollte man dieses Plugin bevorzugt verwenden. Check_smtp und Check_ssmtp sind in der Lage Mail-Transport-Agents zu überwachen. Mittels der Option -p spricht es den Mailserver auf dem angegeben Port an und sendet ihm helo. Wird dieser Verbindungsaufbau korrekt beantwortet, so ist die Prüfung erfolgreich verlaufen. Die Option -A bietet die Möglichkeit, sich am Mailserver als bestimmter Nutzer zu authentifizieren. Check_ssmtp überprüft den Standard-TCP-Port für eine SSL-Verbindung am Mailserver. # check_smtp -H example.com -p 25 -w c 20.0 Check_pop und Check_imap bauen ebenfalls eine TCP-Verbindung am mitgegebenen Port auf und überprüfen den Rückgabestring des Dienstes hinter diesem Port. Erfolgreich verläuft dieser Test nur, wenn +OK bei POP oder * OK bei IMAP zurückgegeben wird. Analog dazu gibt es auch die Plugins Check_spop und check_simap. Martin Steinbach 9 von 30

10 # check_pops -H example.com -p 995 -w c 20.0 Check_http überprüft Webserver per HTTP und HTTPS. Mit der Option -H kann man verschiedene virtuelle Hosts des Webservers ansprechen, währenddessen man mit der Option -I immer in der Standardumgebung des Webservers landet. Um direkt eine URL auf dem Server zu überprüfen, verwendet man die Option -u. Verlangt der Webserver eine Benutzerauthentifizierung per htaccess, werden Benutzername und Passwort der Option -a angefügt. Wie für alle Plugins gilt, dass die gesamte Bandbreite der Optionen nur durch einen Aufruf der Hilfeseite des Plugins deutlich wird. # check_http -ssl -H vh.example.com -p 443 -u /pfad/index.html -a C username:passwort Check_ssh wertet den SSH-Handshake aus. Nur wenn dieser korrekt verläuft, gibt das Plugin kein CRITICAL zurück. # check_ssh -H vexample.com -p 22 timeout=12 Check_ldap stellt anonym oder mit Authentifizierung eine Suchabfrage an einen LDAP- Server. Dazu benötigt es zwingend den Base Domain Name des LDAP -Servers, dieser wird mit der Option -b angegeben. Es ist darauf zu achten, dass Check_ldap standardmäßig die Version 2 des LDAP-Protokolls verwendet. Um mit aktuellen Versionen von OpenLDAP kompatibel zu sein, muss man mittels des Schalters -3 das Plugin dazu zwingen für die Anfrage Version 3 des Protokolls zu verwenden. # check_ldap -3 ssl -p 636 -H example.com -b o=example,c=com -w 1.0 -c 5.0 Check_dhcp sendet per UDP-Broadcast ein DHCPDISCOVER an Port 67 und erwartet vom angegebenen Server ein DHCPOFFER. Trifft dieser in der vorgegebenen Zeit ein, so ist der Test erfolgreich. Standardmäßig wird die MAC-Adresse des angegebenen Interfaces (-i) des Nagiosservers verwendet. Möchte man eine andere MAC-Adresse verwenden, so kann das mit der Option -m realisiert werden. # check_dhcp -s example.com -i eth2 -t 10 Lokale Ressourcen Plugins, die lokale Ressourcen überprüfen, funktionieren nach dem gleichen Prinzip wie die Netzwerkplugins. Sie sind jedoch erst sinnvoll, wenn auf den zu überprüfenden Rechnern der NRPE-Dienst (4.2) läuft oder sie per SSH (4.4) ausgeführt werden. Folgende Übersicht gibt einen Überblick über die am häufigsten benutzten Plugins im Institut. Martin Steinbach 10 von 30

11 Pluginübersicht: Check_disk prüft ob, auf den lokalen Platten noch genug Speicherplatz bereit steht. Es werden Schwellenwerte für WARNING und CRITICAL gesetzt, die Standardeinheit ist Megabyte. Der Option -p wird der zu prüfende Mountpoint oder aber eine Deviceadresse mitgegeben. # check_disk -w 100 -c 50 -p /export/home Check_swap gibt man statt einer festen Einheit als Schwellenwert nur Prozentzahlen mit, welche den freien Speicher definieren. # check_swap -w 50% -c 20% Check_procs bietet mehrere Möglichkeiten Prozesse zu überprüfen. So kann man die Anzahl gleichnamiger Prozesse -C, die Hauptspeicher- und CPU-Auslastung einzelner Prozesse -m sowie die Gesamtzahl laufender Prozesse und deren Prozessstatus -s überwachen. Das Beispiel prüft, ob ein Prozess namens rpc.statd läuft, allerdings mit nicht mehr als drei Instanzen. # check_procs -c 1:3 -C rpc.statd Check_users überwacht die Gesamtanzahl der eingeloggten Nutzer auf einem System, egal ob eine Remoteverbindung besteht oder der Nutzer lokal eingeloggt ist. # check_users -w 5 -c 10 Check_ntp vergleicht die Systemzeit mit der eines anzugebenden Zeitservers. Schwellenwerte werden in Sekunden angegeben. # check_ntp -H time.example.com -w 60 -c 120 Check_sensors greift auf das Programm lm-sensors zurück und wertet dessen Ausgaben aus. Sobald lm-sensors einen Alarm meldet, gibt check_sensors ein CRITICAL zurück. Die Konfiguration, wann ein CRITICAL erscheint, wird in lm-sensors vorgenommen. Mit einem einfachen Aufruf von check_sensors kann man das Plugin ausführen Kommandos einrichten Kommandos bilden die direkte Schnittstelle zu den Plugins; sie werden von den Service-Checks angesprochen und somit ausgeführt. Kommandodefinitionen sind in die Konfigurationsdatei /etc/nagios3/commands.cfg einzutragen. Sie werden, wie auch Host- und Servicedefinitionen, als Objekte behandelt. Ein beispielhafter Eintrag sieht folgendermaßen aus: Martin Steinbach 11 von 30

12 define command{ command_name check_https command_line /usr/lib/nagios/plugins/check_http ssl -H $HOSTADDRESS$ -p 443 } define_command erstellt ein neues Kommandoobjekt innerhalb seiner geschweiften Klammern. Auf den command_name greifen später die Serviceobjekte zu, um die in command_line angegebene Befehlszeile auszuführen. Dabei werden sogenannte Makros verwendet. Eines dieser Makros ist $HOSTADDRESS$. An dessen Stelle wird später die IP-Adresse (oder der DNS- Hostname) der Hosts eingefügt, welche in dem Serviceobjekt eingetragen sind, dass dieses Kommando aufruft. Folgendes Beispiel zeigt eine Kommandodefinition der mehrere Argumente übergeben werden. define command{ command_name check_ping command_line /.../check_ping -H $HOSTADDRESS$ -w $ARG1$ -c $ARG2$ } Diese zusätzlichen Argumente werden in der Servicedefinition hinzugefügt, so kann ein Kommando für mehrere Servicechecks mit unterschiedlichen Argumenten verwendet werden Neue Hosts anlegen Neue zu überwachende Server werden in eine der Host-Dateien im /etc/nagios3/servers/ Verzeichnis eingetragen. Wie Kommandos werden auch Hosts als Objekte betrachtet. Der größte Vorteil bei der Verwendung von Objekten ist die Möglichkeit der Vererbung von Eigenschaften. Damit müssen nicht bei jeder Host- und Servicedefinition alle zwingenden Einstellungen einzeln gesetzt werden. Solch ein generischer Host ist in jeder Hostdatei auf dem Nagiosserver zu finden: define host{ name generic-linux register 0 check_command check-host-alive max_check_attempts 10 check_period 24x7 contact_groups admins notification_interval 180 notification_period 24x7 notification_options d,u,r,f icon_image base/linux40.png icon_image_alt Linux - Server statusmap_image base/linux40.gd2 } Martin Steinbach 12 von 30

13 Sollen nun Einstellungen geändert werden, sind Anpassungen am generischen Host notwendig. Folgende Einstellungen sind für eine funktionierende Hostkonfiguration unbedingt erforderlich: name generic-linux Name des Hostes auf dem später z.b. über das Serviceobjekt auf das Hostobjekt zugegriffen wird. register 0 Definiert eine einmalige Einstellung für den generischen Host, die Nagios anweist dieses Objekt nicht als alleinstehendes Objekt zu betrachten. check_command check-host-alive Gibt das Kommando an, mit welchem die Hostchecks durchgeführt werden sollen. Falls der Hostcheck einen kritischen Status liefert, werden keine Benachrichtigungen mehr für kritische Services generiert. max_check_attempts 10 Läuft ein Hostcheck fehl, so ändert sich der Status dieses Checks in ein Soft-State. Hier wird angegeben, wie oft ein Check in diesem Fall wiederholt wird, bevor ein Hard-State erreicht ist und somit eine Benachrichtigung versandt wird. check_period contact_groups 24x7 admins In diesen Einstellungen werden das Zeitfenster (common/timeperiods.cfg), in dem der Check ausgeführt wird und die Kontaktgruppe, die benachrichtigt werden soll, (common/contacts.cfg) angegeben. notification_interval 180 notification_period 24x7 Wird eine Benachrichtigung ausgelöst, so wird diese bei einem Fortbestehen des Fehlers im dreistündigen Intervall 24 Stunden am Tag und 7 Tage die Woche wiederversandt. notification_options d,u,r,f Martin Steinbach 13 von 30

14 Diese Option beschreibt Zustände über die Nagios informieren soll, sobald diese eintreffen. Mögliche Zustände sind: n - Nagios versendet keine Benachrichtigung (diesen Host betreffend) d - Der Host ist nicht erreichbar u - Zustand des Hosts nicht erkennbar r - Recovery (OK Zustand nach einem Fehler) f - Flapping (Zustand des Hosts wechselt oft) s - Informationen über geplante Wartungszeiträume icon_image icon_image_alt statusmap_image base/linux40.png Linux - Server base/linux40.gd2 Zur besseren Übersicht im Webinterface wurden Icons aus dem Paket Nagios-Images für jeden Host eingerichtet. Damit kann man schnell erkennen, welches Betriebsystem auf dem jeweiligen Host läuft. Die Optionen für das generic-linux Hostobjekt können für alle neu anzulegenden Hostdefinitionen genutzt werden. Dadurch bleibt die eigentliche Hostkonfiguration übersichtlich: define host{ host_name vs-inf-stat hostgroups vserver alias Vs-inf-stat address use generic-linux } In den Hostkonfigurationen müssen neben Hostname und Adresse lediglich noch eine Hostgruppe und ein Alias gesetzt werden. Hostgroups legt fest, in welchen Hostgruppen der Host Mitglied sein soll. Der Alias erscheint als Name des Hosts im Webinterface. Use erbt die Einstellungen des angegebenen generischen Hostobjekts, dabei werden eigene Einträge höher gewichtet. Martin Steinbach 14 von 30

15 2.1.5 Neue Services anlegen Die Konfiguration der zu überwachenden Dienste umfasst den größten Teil der Nagioskonfiguration. Sie wird ausschließlich in der Datei /etc/nagios3/servers/services.cfg vorgenommen. Analog zur Hostkonfiguration werden nur die Einstellungen betrachtet, welche in der Servicedefinition neu sind. define service{ name generic-service register 0 max_check_attempts 10 normal_check_interval 5 retry_check_interval 1 check_period 24x7 notification_interval 120 notification_period 24x7 notification_options w,u,c,r,f contact_groups admins } normal_check_interval 5 Intervall, in dem Nagios den Check in einem stabilen Zustand (Hard-State) wiederholt. retry_check_interval 1 Intervall, in dem Nagios den Check in einem nicht stabilen (Soft-State) Zustand wiederholt. Ist der angegebene Wert von max_check_attempts erreicht, so wird eine Benachrichtigung versandt. notification_options w,u,c,r,f Diese Option gibt an, über welche eintretenden Zustände Nagios für diesen Service berichten soll. Folgende Schalter sind möglich: n - Nagios versendet keine Benachrichtigung für diesen Service c - kritischer Zustand (critical) w - Warnung (warning) u - unbekannter Zustand r - Recovery (OK Zustand nach einem Fehler) f - Flapping (Zustand des Services wechselt oft) s - Informationen über geplante Wartungszeiträume des Services Martin Steinbach 15 von 30

16 Ebenso wie die Hostobjekte bleiben auch die Serviceobjekte durch Nutzung der Vererbung übersichtlich: define service{ host_name service_description servicegroups check_command use } markov,heka,church CHECK_LDAP ldap check_ldap!ou=informatik,o=uni-halle,c=de generic-service Anstatt für host_name eine kommaseparierte Liste aller Hosts, für welche dieser Servicecheck ausgeführt werden soll, anzugeben, kann man auch mit hostgroup_name eine Liste ganzer Hostgruppen angeben und somit die Übersichtlichkeit erhöhen. Die service_description taucht als Beschreibung für den Servicecheck im Webinterface und den Benachrichtigungen auf. Sie sollte daher selbsterklärend sein. check_command check_ldap!ou=informatik,o=uni-halle,c=de Über check_command werden die in der Datei /etc/nagios3/commands.cfg definierten Kommandos aufgerufen. Die von einigen Kommandos verlangten Argumente schreibt man hinter ein Ausrufezeichen. Mehrere benötigte Argumente werden durch ein Semikolon voneinander getrennt. Martin Steinbach 16 von 30

17 2.2 Gruppen In der Datei /etc/nagios3/servers/groups.cfg sind die Host- und Servicegruppen definiert. Besonders im Webinterface erweisen sich diese als nützlich, so erkennt man z.b. sehr schnell welche Dienste auf welchen Servern laufen. Folgende Hostgruppen wurden für das Institut eingerichtet: Tabelle 2.2: Hostgruppen Mitglieder Pool-Server wodan,odin,anubis,turing VServer inf-serv,vs-inf-stat,users Zentrale-Server church,markov,heka,inf-www,janus,isis,osiris Arbeitsgruppen-server ada,verdi,haydn,haendel,ada,sol,kapella,alcyone Möchte man einen Host zu einer Gruppe hinzufügen, so muss man ihm das in seiner Hostdefinition mitteilen und als Mitglied in das Hostgruppenobjekt eintragen. define hostgroup{... members church,markov,example.com } Für jeden Servicecheck gibt es auch eine passende Servicegruppe. 2.3 Für Nagios benötigte Dienste Nagios benötigt zum Anzeigen seiner Testergebnisse und zum Verschicken der Info-Mails noch weitere Dienste. Zum Einen einen Webserver mit Common Gateway Interface und zum Anderen einen Mail Transfer Agent. Als Webserver kommt der Apache Webserver in seiner aktuellen Version mit seinen Modulen mod_cgi und mod_ssl zum Einsatz. Für den Ersatz eines kompletten MTAs wird der Nullmailer-Daemon eingesetzt Webserver Die für Nagios relevanten Apache2 Konfigurationsdateien /etc/apache2/conf.d/nagios3.cfg und /etc/apache2/sites-avaiable/inf-stat wurden so angepasst, dass man nur über eine Benutzerauthentifizierung und über HTTPS auf das Nagios Webinterface zugreifen kann. Die Passwortdatei /etc/nagios3/htpasswd.users regelt den Zugriff auf den Webserver. Neue Nutzer können jederzeit angelegt werden, jedoch haben diese standardmäßig keinerlei Rechte Martin Steinbach 17 von 30

18 im Webinterface. Möchte man Nutzern Rechte gewähren, so kann man das in der Konfigurationsdatei der CGI-Programme konfigurieren. Einen neuen Nutzer legt man mittels des htpasswd Befehls an, dabei wird die Option -s verwendet. Sie weist htpasswd an, nicht die systemeigenen crypt()-hashes, sondern sicherere SHA-Hashes zum Speichern der Passwörter zu nutzen. # htpasswd -s /etc/nagios3/htpasswd.users NUTZERNAME Die Konfigurationsdatei der CGI-Programme (/etc/nagios3/cgi.cfg) bietet neben der Rechteverwaltung für das Webinterface auch noch weitere relevante Optionen an. Zum Beispiel kann man das Zeitintervall, in dem das Webinterface neu geladen werden soll, über die Option refresh_rate einstellen. Wie in allen anderen Listen zur Rechteverwaltung kann man hinter der Option authorized_for_system_information eine Liste von Nutzern angeben, die auf die Funktionen der Option zugreifen dürfen. Speziell diese Option erlaubt dem Nutzer auf das extinfo.cgi Programm zuzugreifen und somit Informationen über den Nagiosprozess zu erhalten. Analog dazu erlaubt ein Eintrag in authorized_for_configuration_information die Konfiguration von Hosts, Services und Kommandos über das Webinterface zu betrachten. Soll ein Nutzer in der Lage sein den Nagiosdienst über das Webinterface neu zu starten, so muss er in der authorized_for_system_commands-liste vermerkt werden. Um Nutzern Zugriff auf die Service- oder Hostchecks zu erlauben, muss man sie jeweils in eine oder beide der folgenden Listen eintragen: authorized_for_all_[services,hosts]. Soll der Nutzer darüber hinaus auch auf das Kommandointerface des Webinterfaces zugreifen können, so muss er jeweils in eine oder beide authorized_for_all_[service,hosts]_commands Listen eingetragen werden Mail Transfer Agent Auf dem Nagiosserver wurde, wie im Institut üblich, kein größerer Mail Transfer Agent installiert. Die Einrichtung des einfachen nullmailer genügt, um eine Mail an den Mailserver des Instituts (janus.informatik.uni-halle.de) zu senden, da innheralb des Instituts keine besondere Authentifizierung verlangt wird. Damit der Nullmailer Mails korrekt weiterleitet, muss lediglich in der Datei /etc/nullmailer/remote der Full Qualified Domain Name des Mailservers eingetragen sein. Nagios versendet seine Mails über das Unix-Kommando /usr/bin/mail, daher muss an der Nagioskonfiguration keine Änderung vorgenommen werden. Martin Steinbach 18 von 30

19 3 Konfiguration der Clients Die Nagiosplugins erlauben auch das Anzeigen lokaler Ressourcen. Um diese Ergebnisse dem Nagiosserver zur Verfügung zu stellen, kann man drei Methoden verwenden: 1. Auf dem Server läuft ein Dienst, der auf Anfrage von Nagios lokal gespeicherte Plugins ausführt. 2. Das Plugin wird über Secure Shell auf dem Host ausgeführt. 3. Ein Dienst der selbsständig Tests ausführt und die Ergebnisse an den Nagiosserver weiterleitet (passiver Test). Für diese drei Methoden bietet Nagios eine Lösung an. Auf den Servern mit Debian oder Ubuntu ist die erste Methode vorzuziehen, sie wird mittels des Nagios Remote-Plugin-Executors realisiert. Dieser kann entweder als eigenständiger Dienst laufen oder aber über den inetd oder xinetd angebunden werden. Für Solaris Systeme und andere Unix Systeme bei denen kein NRPE-Daemon verfügbar ist, sollte man auf die zweite Methode zugreifen. Die dritte Methode ist als Ergänzung zum Nagiosserver gedacht, um z.b. einzelne Subnetze separat zu überwachen und die Ergebnisse der Tests global zu veröffentlichen. Martin Steinbach 19 von 30

20 3.1 Nagios Remote Plugin Executor Der Nagios Remote Plugin Executor (NRPE) läuft als Dienst auf dem zu überwachenden Rechner. Er lässt sich sehr einfach als Paket über die Debian Repositories installieren: # aptitude install nagios-nrpe-server nagios-plugins-standard C nagios-plugins-basic Für die Server, die noch unter SUSE 9.3 laufen, gibt es leider kein online Repository mehr. Die RPM Pakete stehen allerdings auf dem institutseigenen Webserver zur Verfügung 1 (32 und 64 Bit Pakete). Die Installation wird mittels rpm vorgenommen: # rpm -iv nagios-nrpe x86_64.rpm nagios-plugins x86_64.rpm Unter SUSE läuft der NRPE nicht als eigenständiger Dienst, sondern wird über inetd oder xinetd angesprochen. Aus Sicherheitsgründen setzt man im Institut den moderneren xinetd ein, siehe Der NRPE wird auf dem Client über die Datei /etc/nagios/nrpe.cfg konfiguriert. Einstellbar ist unter anderem auch der Port, auf dem der NRPE auf Anfragen des Nagios-Servers lauscht; standardmäßig wird im Institut der Port 5666 verwendet. Um lokale Ressourcen zu überwachen, muss man in nrpe.cfg ein Kommando definieren, welches dann vom Nagios-Server aufgerufen werden kann. Das Schema einer Kommandodefinition sieht folgendermaßen aus: command[kommandoname]=/pfad/zum/plugin -OPTION1 ARG1 -OPTION2 ARG2 Als Beispiel dient folgende Definition: command[check_zombie_procs]=/usr/lib/nagios/plugins/check_procs -w 0 -c C 1 -s Z Damit dieses Kommando auch ausgeführt werden kann, muss der Nagios-Server wissen, wie dieses Kommando heißt und auf welchem Rechner es ausgeführt werden soll. Mit Hilfe des check_nrpe Plugins muss man auf dem Nagios-Server ein neues Kommandoobjekt einrichten. define command{ command_name command_line -c $ARG1$ } check_nrpe /usr/lib/nagios/plugins/check_nrpe -u -H $HOSTADDRESS$ C Der NRPE benötigt für das Einlesen der Konfigurationsdateien einen Neustart. 1 Martin Steinbach 20 von 30

21 # /etc/init.d/nagios-nrpe-server restart Die Option -u definiert, dass NRPE ein UNKNOWN anstatt eines CRITICAL an Nagios zurück gibt, falls der Test ein timeout hervorruft. -H ist das Makro für die Hostadresse auf dem der NRPE läuft. Nach der Option -c wird der in der Datei /etc/nagios/nrpe.cfg auf dem Client definierte Kommandoname übergeben. Mit dessen Hilfe ist man nun in der Lage Serviceobjekte für die einzelnen Kommandos zu definieren: define service{ host_name service_description servicegroups check_command... } SERVER1,SERVER2,SERVER3 CHECK_TIME time check_nrpe!check_ntp_time Xinetd Der inetd ist ein relativ einfacher Dienst, der die Unix-Neztwerksockets abhört und Anfragen an das dazugehörige Programm weiterleitet. Die Dienste werden über eine Konfigurationsdatei mit ihren aufzurufenden Optionen angegeben. Im Gegensatz zum inetd bietet der xinetd noch weitere Einstellmöglichkeiten, z.b. Whitelist von IP-Adressen. Die Einstellungen für den NRPE werden in einer neu erstellten Datei im /etc/xinetd.d/ Verzeichnis vorgenommen. Eine gültige Konfigurationsdatei ist auf dem Webserver des Instituts hinterlegt 2. service nrpe { flags = REUSE socket_type = stream wait = no user = nobody group = nogroup server = /usr/bin/nrpe server_args = -c /etc/nagios/nrpe.cfg -i log_on_failure += USERID disable = no only_from = } Für eine schnelle Konfiguration muss die xinetd Konfigurationsdatei erstellt, der Dienst dem System bekannt gemacht und der xinetd neu gestartet werden. 2 Martin Steinbach 21 von 30

22 # wget -O /etc/xinetd.d/nrpe # echo nnrpe 5666/tcp»> /etc/services # /etc/init.d/xinetd restart 3.2 Secure Shell Auf den Solaris Servern des Instituts zwingen unterschiedliche Versionen und Patchstände zur Ausführung der Plugins über SSH anstatt NRPE. Für diesen Fall bietet Nagios das check_by_ssh Plugin an. Es wird direkt auf dem Nagios-Server ausgeführt. Zur Vorbereitung werden auf dem einzurichtenden Client ein neuer Benutzeraccount und ein SSH-Schlüssel benötigt. Den öffentlichen SSH-Schlüssel findet man im /home/nagios/.ssh Verzeichnis auf dem Nagios-Server inf-stat.informatik.uni-halle.de. Einen neuen Benutzeraccount legt man unter Solaris mittels useradd an. Auf allen Solaris Servern des Instituts wurde außerdem noch eine Gruppe mit dem Namen nagios angelegt, GID und UID tragen den Wert 413. # groupadd -g 413 nagios # useradd -d /home_local/nagios -m -g nagios -k /etc/skel -u 413 nagios Sind Benutzer und Homeverzeichnis angelegt, kopiert man den öffentlichen Schlüssel des Nagios-Servers (/home/nagios/.ssh/id_rsa.pub) auf den Client in die Datei /home_local/nagios/.ssh/authorized_keys. Damit diese Authentifizierungsmethode auch unter Solaris funktioniert, nimmt man eine Änderung in der /etc/shadow vor. Anstelle eines Passworthashes des Nagiosusers muss ein Stern eingefügt werden. nagios:*:::::: Nun kann sich der Benutzer nagios vom Nagios-Server ohne Passworteingabe als Benutzer nagios auf dem Client einloggen. Da es für Solaris keine Binärpakete gibt, muss man die Plugins aus den Quellen heraus übersetzen. Im Institut wird die stabile Version der Plugins verwendet und kann vom institutseigenen Webserver heruntergeladen werden 3. Die Installation aus den Quellen gestaltet sich relativ einfach: # tar xzf nagios-plugins tar.gz # cd nagios-plugins #./configure # make && make install 3 Martin Steinbach 22 von 30

23 Das configure Skript erkennt automatisch die Installation von Openssl. Dieses sollte auf dem System verfügbar sein, damit eine verschlüsselte Übertragung der Testergebnisse möglich ist. Auch eine Perl Installation sollte vorhanden sein. Make übersetzt die Plugins und make install installiert die Plugins in das /usr/local/nagios/libexec/ Verzeichnis. Auf dem Nagios-Server muss für jedes auszuführende Plugin ein eigenes Kommandoobjekt erstellt werden. Diesem Kommando ordnet man dann durch Serviceobjekte Argumente zu. Das Plugin check_by_ssh kümmert sich um die Ausführung des Plugins auf dem entfernten Host, dazu benötigt es den Pfad zum privaten Schlüssel -i und ein Kommando, welches Remote ausgeführt werden soll -C. define command{ command_name check_by_ssh_load command_line /usr/lib/nagios/plugins/check_by_ssh -H $HOSTADDRESS$ -i C /home/nagios/.ssh/id_rsa -C "/usr/local/nagios/libexec/check_load -w $ARG1$ -c C $ARG2$ " } Die einzelnen Argumente werden im Serviceobjekt durch Ausrufezeichen getrennt angegeben.... check_command... check_by_ssh_load!10,8,7!15,12,10 Martin Steinbach 23 von 30

24 4 Webinterface Das Webinterface ist erreichbar unter: Die Abbildung 4.1 zeigt die Startseite, auf dieser erhält man einen schnellen und detaillierten Überblick über den Status der Server und deren Services. Am linken Rand befindet sich die Navigationsleiste und rechts die aktuell angezeigte Informationsseite. Die Aktualisierung der Informationsseite wird standardmäßig alle 90 Sekunden vorgenommen. Auf fast jeder Seite wird im oberen Bereich ein Gesamtstatus über alle überwachten Hosts und Services angezeigt. Somit kann man schnell erkennen, wieviele Services oder Hosts zur Zeit welchen Status besitzen. Im unteren Bereich der Startseite befindet sich eine Übersicht aller Server, geordnet nach ihren Hostgruppen. Neben dem Status des Servers (Up, Down), wird in der Spalte Services auch die Anzahl der getesteten Services und ihr Status (Ok, Warning, Critical, Pending) dargestellt. Abbildung 4.1: Startseite Über einen Klick auf einen Hostnamen, ein Betriebssystemsymbol, die Serviceanzahl oder eines der beiden ersten Symbole aus der Actions-Spalte erreicht man eine detailierte Ansicht. Martin Steinbach 24 von 30

25 4.1 Detailansichten Die detailierte Hostansicht (Abbildung 4.2) erreicht man, indem man dem Link eines Hostnamens oder des dazugehörigen Betriebssystemsymbols folgt. In der Informationsbox sind die wichtigsten Daten zum überwachten Host zu finden. Es ist ersichtlich, in welchem Status er sich befindet und wann der letzte Test durchgeführt wurde. Ebenso werden Performancedaten über den Hostcheck angezeigt. In der rechten Box befinden sich Kommandoschaltflächen, welche nur für den Nutzer nagiosadmin ausführbar sind. Mit Hilfe der Kommandos kann man für alle Services dieses Hosts Benachrichtigungen ausschalten, aktive Tests unterbinden und den nächsten Zeitpunkt aller Servicetests festlegen. Analog zu den Servicechecks ist dies auch für den Host möglich. Zudem kann man eine Benachrichtigung für den Host versenden und besondere Funktionalitäten wie Obsessing, Event-Handler oder Flap-Detection ein- oder ausschalten. Eine geplante Downtime kann ebenfalls angegeben werden, in dieser Zeit wird von einem Hostcheck abgesehen. Ähnlich stellt sich auch die Detailansicht eines Services dar (Abbildung 4.3). Abbildung 4.2: Host im Detail Abbildung 4.3: Service im Detail Martin Steinbach 25 von 30

26 4.2 Monitoring-Ansichten Unter dem Monitoring-Abschnitt der Navigationsleiste finden sich eine Reihe weiterer Ansichten. Tactical Overview bietet einen sehr groben quantitativen Überblick über den Status von Hosts und Services. Einen wesentlich genaueren Überblick verschafft die Ansicht Service Detail: Abbildung 4.4: Servicedetail-Ansicht Neben dem Menüpunkt Service Detail existiert auch der Menüpunkt Host Detail. Die Hostgroup-Seiten arrangieren die Testergebnisse immer in Abhängigkeit zur jeweiligen Serviceoder Hostgruppe. Das Beispiel zeigt Hostgroup Summary: Abbildung 4.5: Hostgroup Summary Auf den Seiten Service- und Host-Problems bekommt man eine Zusammenfassung aller derzeitigen Probleme, jeweils für Service- oder Hostchecks, geliefert (Abb. 4.6). Abbildung 4.6: Problems Martin Steinbach 26 von 30

27 4.3 Prozessansichten Das Webinterface bietet neben dem Abrufen von Informationen über Service- und Hostchecks auch die Möglichkeit, Daten über den Nagiosprozess in Erfahrung zu bringen und diesem Kommandos zu erteilen. Man erreicht diese Schnittstelle über den Process Info-Verweis in der Navigationsleiste. Neben Programmversion, Laufzeit und Process-ID findet man auch eine Übersicht über aktivierte Extrafunktionalitäten von Nagios. Diese speziellen Funktionen können neben allgemeinen Funktionen, wie dem Versenden von Nachrichten, in der Kommandobox deaktiviert oder aktiviert werden. Es ist sogar möglich, den Nagios-Prozess herunterzufahren oder einem Neustart zu unterziehen. Abbildung 4.7: Prozessinfo Unter dem Link Scheduling Queue der Navigationsleiste wird eine Tabelle generiert. Diese Tabelle zeigt aufsteigend nach Zeit, die nächsten durchzuführenden Tests an. Die Tests können durch den Nagiosadmin abgebrochen oder zu einem selbstdefinerten Zeitpunkt ausgeführt werden. Abbildung 4.8: Scheduling Martin Steinbach 27 von 30

28 4.4 Reporting Nagios bietet die Möglichkeit historische Testergebnisse grafisch aufzuwerten, diese können dann für Analysen genutzt werden. Der Report-Generator Trends erstellt ein Diagramm, auf dem man genau nachvollziehen kann, wie lange ein Host oder Service einen in einem bestimmten Status verweilte. Die folgende Abbildung zeigt einen Report, der den Zeitraum einer Woche betrachtet und in dem alle möglichen Zustände auftauchen. Abbildung 4.9: Trend Die Verfügbarkeit von Servern wird durch den Report-Generator Availability rekonstruiert: Abbildung 4.10: Verfügbarkeit Histogramme werden durch Alert Histogram erzeugt: Abbildung 4.11: Histogramm Neben den grafischen Möglichkeiten zur Analyse ist es möglich, über die Webschnittstelle auf verschiedene Logdateien zuzugreifen. Alert History und Alert Summary zeigt alle Statusänderungen an, die nicht zu einer Benachrichtigung geführt haben. Notifications hingegen führt nur Benachrichtigungen auf und Event Log beherbergt alle Logeinträge. Martin Steinbach 28 von 30

29 4.5 Legende Abbildung 4.12: Acknowledged Abbildung 4.13: Comment Diese beiden Symbole erscheinen dann in den Host- bzw. Serviceansichten, wenn der Nagiosadmin dem System mitteilt, dass ein vorhandenes Problem bestätigt wurde (engl: acknowledged). Sobald ein Problem als acknowledged gekennzeichnet wurde, werden keine Benachrichtigungen mehr versandt. Für Hosts und Services kann auch ein einzelner Kommentar (Abb. 4.13) gesetzt werden. dieser hat keinen Einfluss auf das System und dient nur zur Information anderer Nutzer. Abbildung 4.14: Disabled Abbildung 4.15: Passivecheck Deaktiviert man Host- oder Servicechecks, so wird dies durch Abbildung 4.14 in der jeweiligen Ansicht sichtbar. Werden nur aktive Servicechecks deaktiviert, erscheint ein Hinweis, dass nur noch passive Tests angenommen werden (Abb. 4.15). Abbildung 4.16: No Notifications Abbildung 4.17: Downtime Abbildung 4.18: Statusbox Das Abschalten von Benachrichtigungen wird durch Abbildung 4.16 kenntlich gemacht. Benachrichtigungen können auch global abgeschaltet werden. Dieser Zustand ist nicht für jeden Check einzeln vermerkt, sondern lediglich in der Infobox Current Network Status (Abb. 4.18) dargestellt. Angekündigte oder aktive Downtimes werden in der Hostansicht durch Abbildung 4.17 signalisiert. Martin Steinbach 29 von 30