Einleitung

Nagios kann so konfiguriert werden, dass es auch eine verteilte Überwachung von Netzwerk Komponenten und Diensten unterstützt. Ich werde versuchen kurz zu beschreiben wie dies realisiert werden kann.

Ziele

Referenz Diagramm

Das folgende Diagramm sollte eine ungefähre Idee davon vermitteln, wie Nagios verteilte Überwachung realisiert. Im folgenden wird Bezug auf das hier dargestellte Szenario und die darin enthaltenen Komponenten genommen.

Zentraler Server / Verteilte Server

Wenn man eine Umgebung für verteilte Überwachung mit Nagios realisiert, werden der zentrale und die verteilten Überwachungsserver verschieden konfiguriert. Ich werde zeigen wie beide Servertypen konfiguriert werden und erläutern welchen Effekt die unterschiedlichen Konfigurationen auf die gesamte Überwachung haben werden. Für Anfänger, fangen wir mit dem Zweck der unterschiedlichen Server an...

Die Aufgabe eines verteilten Servers ist, die aktiven Prüfungen für die definierten Dienste für eine Gruppe von Netzwerkkomponenten auszuführen. Mit dieser Gruppe ist hier eine willkürliche Gruppierung von Netzwerkkomponenten gemeint. Je nach Netzwerktopografie können an einer Lokation mehrere Gruppen nötig sein oder jede Gruppe kann durch ein WAN, eine Firewall getrennt sein. Das Wichtigste ist, das für jede dieser Gruppen (was auch immer man damit meint) ein eigener verteilter Nagios Überwachungsserver installiert werden muss, der die Dienste in dieser Gruppe überwacht. Ein verteilter Server ist normalerweise eine nackte Basis Installation von Nagios. Es wird weder die Web Schnittstelle, noch eine Alarmierung, noch Ereignis gesteuerte Skripte benötigt wenn dies nicht gewünscht ist. Ausser der Dienst Überwachung wird nnichts benötigt. Eine detailliertere Beschreibung wie ein verteilter Server zu konfigurieren ist folgt später...

Beschaffen von Dienst Überprüfungs Ergebnissen von den verteilten Servern

Bevor wir anfangen uns die Konfigurationsdetails anzusehen müssen wir wissen wie die Ergebnisse der Dienst Prüfungen von den verteilten zu dem zentralen Server gesendet werden. Ich habe bereits erläutert wie das Ergebnis passiver Dienst Prüfungen an Nagios auf dem gleichen Server geschickt werden. (Siehe Abschnitt Passive Prüfungen) Aber dort sind keine Informationen darüber wie diese übers Netzwerk and andere Server geschickt werden können.

Um das Versenden von Ergebnissen der passiven Prüfungen an einen anderen Server zu ermöglichen, habe ich die nsca Erweiterung (ncsa addon) geschrieben. Diese Erweiterung besteht aus zwei Teilen. Der eine ist ein Client (send_nsca) welches auf dem entfernten Computer ausgeführt wird und welches dazu benutzt wird die Ergebnisse zu versenden. Der andere Teil ist der nsca daemon (Dienst) der entweder selbstständig oder unter inetd läuft und auf Verbindung von Clients (nsca_send). Wird eine Verbindung zu ihm aufgebaut, so sendet der daemon das empfangene Ergebnis an Nagios (auf dem zentralen Server) indem er einen PROCESS_SVC_CHECK_RESULT Befehl in die externe Befehls Datei zusammen mit dem Ergebnis der Prüfung einfügt. Wenn Nagios das nächste Mal externe Befehle ausführt findet es das Ergenis der Prüfung das vom verteilten Server geschickt wurde und verarbeitet es. Leicht, oder?

Konfiguration der verteilten Server

Also, wie muss Nagios auf einem verteilten Server konfiguriert werden? Im Grunde ist es nur eine nackte Nagios Basis-Installation. Sie brauchen weder die Web Schnittstelle noch Benachrichtungen weil dies alles vom zentralen Server erledigt wird.

Hauptanpassungen der Konfiguration:

• Nur die Dienste und Netzwerkkomponenten die dirket vom verteilten Server überwacht werden sollen werden in der Objekt Konfigurations Datei eingetragen.
• Auf dem verteilten Server wird die Option enable_notifications auf den Wert 0 gesetzt. Dies verhindert das Meldungen verschickt werden.
• Die Option obsess over services. wird auf 1 gesetzt und damit aktiviert.
• Auf dem verteilten Server wird ebenfalls die Option ocsp command gesetzt. (Wie weiter unten beschrieben)

Um ein einwandfreies Zusammenspiel zu ermöglichen, wollen wir, das der verteilte Server die Ergebnisse aller Dienst Prüfungen. an Nagios sendet. Dafür könnten wir Ereignis Verarbeiter (event handler) um Änderingen an dem Status eines Dienstes mitzuteilen, benutzen, aber das alleine reicht noch nicht. Um den verteilten Server dazu zu bringen alle Ergebnisse von Dienst Prüfungen weiterzuleiten, müssen Sie noch die Option obsess_over_services in der Hauptkonfigurationsdatei aktivieren und aktivieren das ein ocsp_command nach jeder Dienst Prüfung ausgeführt wird. Wir benutzen den ocsp Befehl um das Ergebnis an den zentralen Server zu senden, dabei wird der nsca_send Client und der nsca daemon benutzt um die Verbindung herzustellen.

Um dies zu bewerkstelligen müssen Sie einen ocsp Befehl wie folgt definieren:

ocsp_command=submit_check_result

Die Befehlsdefinition für den submit_check_result Befehl sieht ungefähr so aus:

define command{
	command_name	submit_check_result
	command_line	/usr/local/nagios/libexec/eventhandlers/submit_check_result $HOSTNAME$ '$SERVICEDESC$' $SERVICESTATE$ '$OUTPUT$'
	}

Das submit_check_result Shell Skript sieht ungefähr so aus (ersetzen Sie central_server durch die IP-Adresse des zentralen Servers):

	#!/bin/sh

	# Arguments:
	#  $1 = host_name (Kurzname der Netzwerkkomponente zu der der Dienst gehört
	#  $2 = svc_description (Beschreibung des Dienstes)
	#  $3 = state_string (Eine Zeichenkette die den Status des Dienstes wiederspiegelt
	#        - "OK", "WARNING", "CRITICAL" or "UNKNOWN")
	#  $4 = plugin_output (Ein Text der als Ausgabe des plugins für die Dienst
	#       Pruefung fungiert)
	#

	# Umsetzen der Status Zeichenkette in eine Status Code
	return_code=-1

	case "$3" in
    	    OK)
        	        return_code=0
            	    ;;
	        WARNING)
    	            return_code=1
        	        ;;
	        CRITICAL)
    	            return_code=2
        	        ;;
	        UNKNOWN)
    	            return_code=-1
        	        ;;
	esac

	# Die Ausgabe an das send_nsca Programm weiterleiten, welches
	# daraufhin die Daten an den nsca daemon auf dem zentralen Server 
	# uebertraegt

	/bin/echo -e "$1\t$2\t$return_code\t$4\n" | /usr/local/nagios/bin/send_nsca central_server -c /usr/local/nagios/etc/send_nsca.cfg

Das Skript setzt voraus das Sie das send_nsca Programm und dessen Konfigurationsdatei (send_msca.cfg) in das Verzeichnis /usr/local/nagios/bin/ und /usr/local/nagios/etc/ kopiert haben.

Das wars! Wir haben erfolgreich einen Server so konfiguriert das er als verteilter Server fungieren kann. Schauen wir nun was genau mit dem verteilten Server passiert und wie er Ergebnisse von Dienst Prüfungen an Nagios verschickt. (Die Nummerierung der folgenden Aufzählung bezieht sich auf das Referenz Diagramm oben auf dieser Seite)

1. Nachdem der verteilte Server eine Prüfung beendet hat führt er den Befehl aus den Sie mit der Option ocsp_command definiert haben. In unserem Beispiel ist dies das >/usr/local/nagios/libexec/eventhandlers/submit_check_result Skript. Registrieren Sie das die Definition für den submit_check_result Befehl vier Einzelinformationen an das Skript übergeben hat: Den Namen der Netzwerkkomponente zu dem der Service gehört, die Beschreibung des Dienstes, den Status Code der Prüfung und die Ausgabe des plugins der Dienstprüfung.
2. Das submit_check_result Skript leitet die Informationen zur Dienstprüfung an das send_nsca Programm weiter.
3. Das send_nsca Programm überträgt diese Informationen and den nsca daemon auf dem zentralen Server.
4. Der nsca daemon auf dem zentralen Server nimmt diese Informationen und schreibt sie in die externe Befehlsdatei damit Nagios diese später verarbeiten kann.
5. Der Nagios Prozess auf dem zentralen Server list die externe Befehls Datei ein und bearbeitet die Informationen zur passiven Dienstprüfung die ursprünglich vom verteilten Server kommen.

Konfiguration des zentralen Servers

Wir haben bereits gesehen wie die verteilten Server konfiguriert werden, also kümmern wir uns jetzt um den zentralen Server. Er wird konfiguriert wie ein, als einziger Nagios Server im Netzwerk befindlicher, Server. Er wird wie folgt konfiguriert:

• Der zentrale Server hat die Web Schittstelle installiert (nicht notwendigerweise, wird aber empfohlen)
• Der zentrale Server hat die Option enable_notifications auf 1 gesetzt. Dies aktiviert Benachrichtigungen. (Nicht notwendig, aber empfohlen)
• Auf dem zentrale Server ist die Option active service checks deaktiviert. (Optional, aber empfohlen - siehe Hinweise unten)
• Auf dem zentrale Server ist die Option external command checks aktiviert (erforderlich)
• Auf dem zentrale Server ist die Option passive service checks aktiviert (erforderlich)

There are three other very important things that you need to keep in mind when configuring the central server:

• Der zentrale Server muss Dienst Definitionen für alle Dienste haben die von verteilten Servern überwacht werden. Nagios ignoriert Ergebnisse von passiven Dienst Prüfungen die nicht zu einem der definierten Dienste passen.
• Wenn Sie den zentralen Server nur dafür benutzen die Ergebnisse von Dienst Prüfungen zu verarbeiten die von verteilten Hosts ermittelt werden, können Sie einfach für alle aktiven Dienste Prüfungen unterbinden indem Sie die Option execute_service_checks auf den Wert 0 setzen. Wenn Sie den zentralen Server auch für die Überwachung einzelner Dienste einsetzen (ohne die Hilfe eines verteilten Servers) müssen Sie die Option enable_active_checks derjenigen Definitionen von Dienst Prüfungen auf den Wert 0 setzen die von den verteilten Servern überwacht werden. Dies verhindert das Nagios diese Dienste auch überwacht.

Es ist wichtig das Sie entweder alle Dienst Prüfung programmweit abschalten oder die Option enable_active_checks bei denjenigen Diensten deaktivieren (setzen auf 0) die von verteilten Servern überwacht werden. Dies stellt sicher das, im Normalfall, keine Prüfungen durchgeführt werden. Die Dienstprüfungen werden wie in den normalen Intervallen eingeplant (3 Minuten, 5 Minuten, etc...) aber sie werden nicht ausgeführt. Diese Einplanschleife läuft weiter so lange Nagios läuft. Warum dies geschieht erläutere ich gleich...

Das wars. Leicht, oder?

Probleme mit passiven Prüfungen

Für normale Zwecke kann man sagen das der zentrale Server sich komplett auf passive Prüfungen, zur Überwachung, verlässt. Das Hauptproblem mit dem ausschließlichen verlassen auf passive Prüfungen liegt darin, das Nagios sich auf etwas anderes zur Überwachung verlassen muss. Was ist wenn der Server der Ergebnisse von Prüfungen senden soll ausfällt oder nicht mehr erreichbar ist? Wenn Nagios nicht aktiv die Dienste prüft, woher weiss es dann das ein Problem vorliegt?

Glücklicherweise gibt es einen Weg um dieses Problem in den Griff zu bekommen.

Freshness Prüfung

Nagios unterstützt ein Feature welches eine "Freshness Prüfung" der Ergebnisse von Dienstprüfungen durchführt. Mehr Informationen über Freshness Prüfungen können unter gefunden werden. Dieses Feature schützt vor der Situation, das entfernte Rechner aufhören passive Dienst Prüfungen an den zentralen Überwachungssserver zu senden. Das Ziel der Freshness Prüfung ist es, sicherzustellen das Dienstprüfungen entweder regelmässig von den verteilten Servern zur Verfügung gestellt werden oder vom zentralen Überwachungsserver ausgeführt werdenm sollte dies nötig sein. Wenn die Ergebnisse der Dienstprüfungen der verteilten Überwachungsserver veraltet sind kann Nagios so konfiguriert werden, das es aktive Prüfungen des Dienstes vom zentralen Überwachungsserver aus macht.

Wie wird das gemacht? Auf dem zentralen Überwachungsrechner müssen die Dienste die von den verteilten Überwachungsservern überwacht werden, wie folgt konfiguriert werden...

• Die check_freshness Option in der Dienst Definition sollte auf 1 gesetzt werden. Dies ermöglicht die "freshness" Prüfung für diesen Dienst.
• Die freshness_threshold Option in der Dienst Definition sollte auf einen Wert gesetzt werden der abhängig davon ist wie frisch (fresh) die Ergebnisse des Dienstes (von verteilten Server) sein sollen.
• Die check_command Option in der Dienst Definition sollte ein check Kommando enthalten welches den Dienst vom zentralen Überwachungsserver prüfen kann.

Nagios überprüft periodisch die "freshness" der Ergebnisse für alle Dienste die freshness Prüfung aktiviert haben. Die Option freshness_threshold in jeder Dienst Definition wird dazu benutzt wie frisch (fresh) die Ergebnisse für jeden Dienst sein sollten. Ein Wert von 5 für einen Dienst zusammen mit einer interval_length von 60 bedeutet, das Nagios den Wert nach 5 Minuten als veraltet ansieht. Wenn Sie für die Option freshness_threshold keinen Wert angeben, berechnet Nagios einen Wert für diese Option, indem es entweder die Option normal_check_interval oder retry_check_interval auswertet, abhängig davon in welchem Statustyp der Dienst sich befindet. Wenn die Ergebnisse als veraltet angesehen werden, führt Nagios den unter der Option check_command in der Dienst Definition angegebenen Befehl aus und prüft damit selber aktiv den Dienst.

Erinnern Sie sich daran, das sie einen Befehl in der Option check_command in der Dienst Definition angeben müssen, damit der Status des Dienstes vom zentralen Überwachungsserver überprüft werden kann. Unter normalen Umständen wird dieser Befehl niemals ausgeführt (weil das aktive Überprüfen global ausgeschaltet wurde). Wenn freshness Prüfung aktiviert wurde führt Nagios diesen Befehl aus obwohl die aktive Überprüfung programmweit oder dienstspezifisch abgeschaltet wurde.

Wenn es Ihnen unmöglich ist einen Befehl anzugeben der eine aktive Überprüfung des Dienstes vom zentralen Überwachungsserver aus ermöglicht (oder wenn es sehr schwierig werden würde) können Sie einfach bei allen betreffenden Diensten ein check_command angeben welches ein Dummy Skript aufruft, welches den Status critical (kritisch) zurückgibt. Hier ist ein Beispiel... Nehmen wir an, das Sie einen Befehl 'service-ist-veraltet' definiert haben und das sie diesen Befehl in der check_command Option des Dienstes angegeben haben. Die Definition sieht wie wie folgt aus:

define command{
	command_name	service-ist-veraltet
	command_line	/usr/local/nagios/libexec/staleservice.sh
	}

Das staleservice.sh Skript im Verzeichnis /usr/local/nagios/libexec könnte so aussehen:

#!/bin/sh

/bin/echo "KRITISCH: Ergebnisse des Dienstes sind veraltet!"

exit 2

Wenn Nagios entdeckt das die Ergebnisse veraltet sind und den Befehl service-ist-veraltet ausführt, wird das /usr/local/nagios/libexec/staleservice.sh Skript ausgeführt und der Dienst geht in den Status kritisch über. Dies wird wahrscheinlich Benachrichtigungen auslösen so das Sie erfahren das ein Problem aufgetreten ist.

Durchführen von Host Prüfungen

An diesem Punkt wissen Sie bereits wie Sie die Ergebnisse von Prüfungen passiv von verteilten Servern erhalten können. Das bedeutet das der zentrale Server die Dienste nicht aktiv selbst überprüft. Aber was ist mit Host Prüfungen? Die müssen doch auch durchgeführt werden, also wie?

Obwohl Host Prüfungen normalerweise nur einen kleinen Teil der Überwachungsaktivitäten ausmachen (Sie werden nicht gemacht ausser sie sind absolut notwendig), empfehle ich das Sie Host Prüfungen aktiv vom zentralen Server aus durchführen. Das bedeutet das Sie die Host Prüfungen auf dem zentralen Server genau wie auf den verteilten Servern definieren (und genauso wie Sie es in einem normalen, nicht verteilten Szenario tun würden).

Es gibt auch Wege Host Prüfungen passiv durchzuführen, aber dies zu realisieren geht über das hinaus über das ich gerade schreiben will.