Donnerstag, 24. Mai 2012

Artikel

Juli 2006 | Artikel

Nagios: Netzwerküberwachung Open Source Fortsetzung, Teil 3

Teil 1   Teil 2   Teil 3   Teil 4   

Kontakte pflegen
Auf die Frage nach der Uhrzeit gilt es nun zu definieren, wer denn im Ernstfall überhaupt benachrichtigt werden soll. KONTAKTE | KONTAKTDATEN führt im NagiosQL-Menü zur Konfiguration der zu benachrichtigenden Personen. In einem ersten Beispiel reicht eine Benachrichtigung per E-Mail bei allen Zustandsänderungen (d=down, u=unknown, r=recover, w=warning, c=critical, f=flapping) aus. Diese Zustände lassen sich bei der Service- bzw. Hostkonfiguration je nach überwachtem Dienst ein- oder ausschalten.
Unter KONTAKTE | KONTAKTGRUPPEN wird nun eine erste Kontaktgruppe (z. B. Linux-Admins) mit dem vorher angelegten Kontaktmitglied erstellt. Nach Änderungen unterhalb der Menüpunkte muss der Button KONFIGDATEI SCHREIBEN angeklickt werden, damit NagiosQL die Konfigurationsdateien aus der Datenbank generiert und im /etc/nagios-Verzeichnis ablegt.
Zeit für den ersten Host
Für eine erste Hostüberwachung bietet sich der localhost an, einige fertige Plug-ins helfen dabei, schnell die grundlegenden Systemparameter abzufragen. Unter ÜBERWACHUNG | HOSTS wird die lokale Hostkonfiguration angelegt. Wie schon bei der Zeitdefinition erwähnt, wird hier der Unterschied zwischen der Prüfperiode und der Alarm-Zeitperiode verdeutlicht. In der Regel will man einen Rechner 24 Stunden bei sieben Tagen die Woche überwachen lassen, aber nicht unbedingt auch bei jedem Rechner die ganze Zeit benachrichtigt werden. Gerade bei Druckern, die z.B. über Nacht ausgeschaltet werden, ist die Definition einer zusätzlichen Zeitperiode sinnvoll.
Sollte ein Prozess oder System Probleme bekommen, dann löst Nagios vorerst einen so genannten Soft-State aus. Nach einer definierbaren Anzahl von Soft-States wechselt Nagios dann den Zustand in Hard-State und schickt Benachrichtigungen los. Demnach werden erst bei Hard-States Benachrichtigungen verschickt, obwohl im Webinterface auch die Soft-States bereits mit Warnungen angezeigt werden. Wann von Soft auf Hard geschaltet wird, entscheidet der Wert bei den "Max. Prüfungen". Dieser Wert bezeichnet die Anzahl der Soft-States, bis ein Hard-State erreicht ist (aufgrund von möglichen Netzwerkschwankungen oder Performanceproblemen sollte dieser Wert immer größer 1 gesetzt sein). Das Prüfintervall bezeichnet den Abstand von einem positiven Check-Resultat zum nächsten.
Der Prüfbefehl bezeichnet den Basis-Check je Host und steht normalerweise auf check_host_alive, einer einfachen Ping-Überprüfung auf die angegebene IP-Adresse. Eine Zeile unter dem Prüfbefehl wird die Syntax des Befehls check_host_alive dargestellt. Die Variable steht als Platzhalter für den Plug-in-Pfad (/usr/lib/nagios/plugins) und kann über die Konfigurationsdatei resource.cfg angepasst werden.
Die Alarmierungseinstellungen definieren die Benachrichtigung bezogen auf den Prüfbefehl. Die Wiederholungszeit definiert dabei die Anzahl der Minuten, nach denen eine weitere Alarmierung ausgelöst werden soll. Soll nur eine Alarm-Meldung an die Administratoren gehen, dann muss der Wert auf Null gesetzt werden. Für die Abbildung echter Service Level Agreements (SLA) mit verschiedenen Eskalationsstufen ist hier die erste Stufe der Eskalation zu definieren, nach einer definierbaren Anzahl von Meldungen ohne Rückmeldung an das System könnte dann die nächste Eskalationsstufe greifen (die Einrichtung von Eskalationsstufen ist ebenfalls über NagiosQL möglich: SPEZIALITÄTEN | HOST-/SERVICEESKALATIONEN).
NRPE-Installation
Für die NRPE-Installation aus dem Sourcecode kann die gewohnte "./configure-Zeile" von der Nagios-Installation erneut verwendet werden, für die Aktivierung der Parameterübergabe muss diese allerdings noch um --enable-command-args erweitert werden. Weitere Informatio-nen zu Vorteilen der Parameterübergabe folgen bei der Erklärung der NRPE-Konfigurationsdatei. Auf die Parameterübergabe sollte allerdings aus Sicherheitsgründen in Hochsicherheits-Netzwerken verzichtet werden. Ein abschließendes make all erstellt alle benötigten Binaries im src/ und ein paar Beispielkonfigurationen im sample-config/-Verzeichnis. Das nrpe-Binary sollte nach /usr/sbin kopiert werden und die NRPE-Konfigurationsdatei in das Nagios-Konfigurationsverzeichnis. Bei der Konfigurationsdatei müssen noch die Berechtigungen angepasst werden (ggf. muss auf dem Zielsystem noch ein User nagios mit der Gruppe nagios erstellt werden): 
linux: # cp src/nrpe /usr/sbin/
linux: # cp sample-config/nrpe.cfg /etc/nagios/
linux: # chown nagios.nagios /etc/nagios/nrpe.cfg
Das NRPE-Plug-in wurde ebenfalls gleich mit kompiliert (src/check_nrpe) und sollte auf den Nagios-Server in das Plug-ins-Verzeichnis (/usr/lib/nagios/plugins/) kopiert werden. Generell müssen sich alle zu benutzenden Plug-ins natürlich auf dem Client befinden. Sofern die Dienste auf dem entfernten Host nicht alle paar Sekunden überprüft werden, bietet sich auf dem Client eine NRPE-Installation über den tcp-Wrapper xinetd an. Beispiel einer NRPE-xinetd-Konfiguration: 
service nrpe
{
        flags                = REUSE
        socket_type     = stream
        wait                 = no
        user                = nagios
        group              = nagios
        server             = /usr/sbin/nrpe
        server_args     = -c /etc/nagios/nrpe.cfg --inetd
        log_on_failure  += USERID
        disable            = no
        only_from       = NagiosServerIP
}
Vor dem Restart des Wrappers muss der Service noch in die /etc/services eingetragen werden: linux: # echo "nrpe 5666/tcp # Nagios NRPE" >> /etc/services Nach dem Restart des xinetd sollte der NRPE-Service laufen. NRPE-Konfiguration
Bei einer NRPE über xinetd-Konfiguration kann die NRPE-Konfigurationsdatei jederzeit angepasst werden, ohne dass der xinetd neu gestartet werden muss. Beispiel einer einfachen NRPE-Konfigurationsdatei bei Nutzung von xinetd-/etc/nagios/nrpe.cfg: 
## PID-File 
pid_file=/var/run/nrpe.pid

## Parameterübergabe aktivieren
dont_blame_nrpe=1

## Debug nach Syslog aus
debug=0

## Timeout in Sekunden
command_timeout=60

## Plugins
command[check_disk]=/usr/lib/nagios/plugins/check_disk -w $ARG1$ -
 c $ARG2$ -p $ARG3$
Um die NRPE-Client-Installation zu testen, sollte man vom Server die Verbindung überprüfen: linux:# /usr/lib/nagios/plugins/check_nrpe –H CLIENT_IP –c check_disk –a "20 10 /"
Zustände sind das hier
Nagios kennt drei unterschiedliche Host-Zustände: "Up" (r), "Down" (d), "Unreachable" (u) sowie den flatternden bzw. schnell wechselnden Zustand, genannt "Flapping" (f). Anfänger interpretieren das "u" leicht mit einem Up, bei Nagios steht das "u" allerdings für "Unreachable" (unerreichbar), was einen nicht definierbaren Zustand beschreibt. Das "r" steht hier für "Recovering" und stellt quasi das Up dar. Den Unterschied von Unreachable und Down macht Abbildung 4 deutlich: Unreachable ist der Zustand der Hosts, die von einem als Down gekennzeichneten Host abhängen.
Ein Servicecheck liefert normalerweise immer einen Rückgabewert zurück, der zwischen 0 und 3 liegt (0=ok, 1=Warning, 2=Critical, 3=Unknown). Auch hier lässt sich ein Flapping-Zustand definieren und über selbigen benachrichtigen ("f"). Da die Zustände fast selbsterklärend sind, sei nur der Zustand "Unknown" kurz erklärt. Ein Plug-in sollte den Zustand Unknown zurückschicken, wenn bestimmte Vorgaben nicht geleistet sind, wie z.B. ein fehlender Parameter, ein unerlaubter Zugriff auf einen anderen Host, eine nicht vorhandene OID bei SNMP-Checks usw. Allerdings ist diese Definition nicht mehr als eine Vorgabe für sauberes Programmieren von Nagios-Plug-ins, leider halten sich nicht alle Entwickler an diese Richtlinie und liefern den Zustand "Critical" anstatt Unknown bei solchen Fehlern zurück.

Teil 1   Teil 2   Teil 3   Teil 4   

Kommentare

+ Neuen Kommentar verfassen