Redundante und ausfallsichere Überwachung

Einleitung

Dieser Abschnitt beschreibt einige Szenarien um redundante Überwachungs-Server in diversen Netzwerk-Layouts zu implementieren. Mit redundanten Servern hat man die Möglichkeit auch dann das Netzwerk zu überwachen, wenn der primäre Nagios-Server ausfällt oder auch weitreichende Teile des Netzwerks unerreichbar geworden sind.

Hinweis: Falls Sie gerade erst lernen wie man Nagios richtig einsetzt, würden wir vorschlagen keine redundante Umgebung zu installieren, bis Sie sich mit den Vorraussetzungen vertraut gemacht haben. Redundanz ist ein relativ kompliziert zu beschreibendes Thema und umso schwieriger zu diese richtig zu implementieren.

Index

Vorraussetzungen
Beispiel Skripte
Szenario 1 - redundante Überwachung
Szenario 2 - ausfallsichere Überwachung

Vorraussetzungen

Bevor man überhaupt an die Implementierung einer redundanten Nagios-Installation denken sollte, sollte man mit den folgenden Themen gut umgehen können...

Implementierung von Event Handlern für Hosts und Dienste
Übergabe von externen Befehlen an Nagios via Shell-Skripte
Ausführung von Plugins auf entfernten Hosts, entweder durch das nrpe-Addon oder eine andere Methode
Überwachung des Status des Nagios-Prozess mit dem check_nagios-Plugin

Beispiel Skripte

Alle Beispiel-Skripte die in dieser Dokumentation benutzt werden, können auch in dem eventhandlers/-Unterverzeichnis der Nagios-Quellcodes gefunden werden. Sie werden diese aber u.U. modifizieren müssen, damit sie auf Ihrem System richtig funktionieren...

Szenario 1 - redundante Überwachung

Einleitung

Dies ist eine einfache (und naive) Methode um redundante Überwachungs-Server in einem Netzwerk zu implementieren und sie bietet auch nur Schutz gegen eine limitierte Anzahl von möglichen Fehlern. Komplexere Setups sind nötig um eine höhere Redundanz, auch über verschiedene Netzwerk-Segmente hinweg, zu ermöglichen.

Ziele

Das Ziel dieser Implementierung ist simpel. Sowohl der "Master" als auch der "Slave"- Server überwachen die selben Hosts und Dienste im Netzwerk. Unter normalen Umständen sendet nur der "Master"-Server Benachrichtigungen über Probleme an die Kontakte. Wir wollen das der "Slave"-Nagios-Server die Benachrichtigungen übernimmt, sobald eines der folgenden Probleme auftritt:

der "Master"-Host auf dem Nagios läuft ist down oder...
der Nagios-Prozess auf dem "Master"-Host läuft aus einem unbestimmten Grund nicht (mehr)

Netzwerk Layout Diagramm

Das folgende Diagram zeigt ein sehr einfaches Netzwerk-Setup. In diesem Szenario nehmen wir an, dass auf Host A und E Nagios läuft und beide Server alle gezeigten Hosts überwachen. Host A wird als "Master"-Host bezeichnet und Host E als "Slave"-Server.

Initiale Programm-Einstellungen

Der Slave-Host (Host E) hat die enable_notifications-Directive initial deaktiviert, um zu verhindern das er Benachrichtigungen über Hosts und Dienste verschickt. Man sollte ausserdem sicherstellen, das die check_external_commands-Directive des Slave-Hosts aktiviert ist.

Initiale Konfiguration

Als nächstes muss der Unterschied zwischen den Objekt Konfigurations-Dateien auf dem Master und Slave Host berücksichtigt werden...

Wir nehmen an, das der Master-Host (Host A) so aufgesetzt wurde, um die Dienste auf allen gezeigten Hosts zu überwachen. Der Slave-Host (Host E) sollte für die gleichen Dienste und Hosts konfiguriert werden, mit folgenden zusätzlichen Einstellungen...

In der Host-Definition für Host A (in den Konfiguration-Dateien von Host E) sollte einen Host-Event Handler enthalten. Wir nehmen an, dass der Name des Host-Event Handlers handle-master-host-event lautet.
Die Konfigurations-Datei auf Host E sollte einen Dienst definiert haben, der den Status des Nagios-Prozesses auf Host A überwacht. Nehmen wir an das definiert wurde, dass für diese Überwachung das check_nagios-Plugin auf Host A ausgeführt wird. Dies kann durch eine in dieser FAQ beschriebenen Methode gemacht werden.
Die Dienst-Definition für die Überwachung des Nagios-Prozesses auf Host A sollten einen Event Handler enthalten. Als Namen für diesen Event Handler nehmen wir handle-master-proc-event an.

Es ist wichtig zu beachten, dass Host A (der Master-Host) keine Kenntnis von Host E (der Slave-Host) hat. In diesem Szenario ist dies einfach nicht nötig. Natürlich kann man auch die Dienste auf Host E von Host A aus überwachen kann, dies hat aber nichts zu tun mit der Implementierung der Redundanz...

Event Handler Befehls-Definition

An dieser Stelle müssen wir kurz stoppen und die Befehls-Definition für die Event Handler auf dem Slave-Host erklären. Hier ist ein Beispiel:

define command{
	command_name	handle-master-host-event
	command_line	/usr/local/nagios/libexec/eventhandlers/handle-master-host-event $HOSTSTATE$ $STATETYPE$
	}

define command{
	command_name	handle-master-proc-event
	command_line	/usr/local/nagios/libexec/eventhandlers/handle-master-proc-event $SERVICESTATE$ $STATETYPE$
	}

Dieses Beispiel geht davon aus, dass die Event Handler-Skripte in dem /usr/local/nagios/libexec/eventhandlers-Verzeichnis platziert wurden. Die Skripte können natürlich überall auf dem System abgelegt werden, dann muss allerdings dieses Beispiel verändert werden.

Event Handler Skripte

Ok, nun werfen wir einen Blick auf die Event Handler Skripte selbst...

Host Event Handler (handle-master-host-event):


#!/bin/sh

# Nur Aktionen bei einem harten Status ausführen...
case "$2" in
HARD)
	case "$1" in
	DOWN)
		# Der Master Server ist down!
		# Wir sollten nun der Master Server werden und die Verantwortung
		# für die Überwachung des Netzwerks übernehmen und deshalb auch
		# die Benachrichtigung versenden...
		/usr/local/nagios/libexec/eventhandlers/enable_notifications
		;;
	UP)
		# Der Master Server ist wieder da!
		# Wir sollten wieder Slave-Host werden und dem Master die
		# Überwachung überlassen und deshalb die Benachrichtigungen
		# deaktivieren...
		/usr/local/nagios/libexec/eventhandlers/disable_notifications
		;;
	esac
	;;
esac
exit 0

Service Event Handler (handle-master-proc-event):


#!/bin/sh

# Nur Aktionen bei einem harten Status ausführen...
case "$2" in
HARD)
	case "$1" in
	CRITICAL)
		# Der Nagios-Prozess des Master Servers läuft nicht!
		# Wir sollten nun der Master Server werden und die Verantwortung
		# für die Überwachung des Netzwerks übernehmen und deshalb auch
		# die Benachrichtigung versenden...
		/usr/local/nagios/libexec/eventhandlers/enable_notifications
		;;
	WARNING)
	UNKNOWN)
		# Der Nagios-Prozess des Master-Servers läuft oder läuft nicht...
		# Wir wissen hier nichts, aber um auf der sicheren Seite zu seien
		# könnte man hier entscheiden, dass der Slave-Host Master wird...
		;;
	OK)
		# Der Nagios-Prozess auf dem Master-Server ist wieder da!
		# Wir sollten wieder Slave-Host werden und dem Master die
		# Überwachung überlassen und deshalb die Benachrichtigungen
		# deaktivieren...
		/usr/local/nagios/libexec/eventhandlers/disable_notifications
		;;
	esac
	;;
esac
exit 0

Was dies für uns tut

Der Slave-Host (Host E) hat initial die Benachrichtigungen deaktiviert, so das er keine Host- oder Dienst-Benachrichtigungen versendet während der Nagios-Prozess auf dem Master-Host (Host A) noch läuft.

Der Nagios Prozess auf dem Slave-Host (Host E) wird Master, wenn...

Der Master-Host (Host A) nicht mehr erreichbar ist und der handle-master-host-event Host-Event Handler ausgeführt wird.
Der Nagios-Prozess auf dem Master-Host (Host A) nicht mehr läuft und der handle-master-proc-event Dienst-Event Handler ausgeführt wird.

Wurden dem Nagios Prozess auf dem Slave Host (Host E) die Benachrichtigungen aktiviert, wird dieser Benachrichtigungen über alle Dienst- oder Host-Probleme und -Entwarnungen versenden. An diesem Punkt hat Host E die Verantwortung über die Überwachung des Netzwerkes und die Benachrichtigung der Kontakte übernommen!

Der Nagios Prozess auf Host E kehrt zu seinem Slave-Status zurück, wenn...

Host A wieder erreichbar wird und der handle-master-host-event Host-Event Handler ausgeführt wird.
Der Nagios Prozess auf Host A wieder läuft und der handle-master-proc-event Dienst-Event Handler ausgeführt wird.

Wurden im Nagios-Prozess auf Host E die Benachrichtigungen wieder deaktiviert, wird dieser keine Benachrichtigungen über Probleme oder Entwarnungen mehr versenden. An diesem Punkt hat der Host E die Verantwortung über die Überwachung des Netzwerkes und die Benachrichtigung der Kontakt wieder an den Nagios-Prozess auf Host A abgegeben. Alles läuft wieder so, wie es war als das Setup gestartet wurde!

Verzögerungen

Die Redundanz in Nagios ist natürlich nicht perfekt. Eines der mehr offentlichen Probleme sind die Verzögerungen zwischen dem Ausfall des Masters und der Übernahme des Slave-Hosts. Dies beeinträchtigt die folgenden Punkte...

Die Zeit zwischen einem Fehler der vom Master erkannt wurde und dem Zeitpunkt bis der Slave das Problem erkennt
Die Zeit die benötigt wird, um sicherzustellen das der Master wirklich ein Problem hat (durch die erneuten Versuche bei Dienst- oder Host-Überprüfungen durch den Slave-Server)
Die Zeit zwischen der Ausführung der Event Handler und dem Zeitpunkt zu dem Nagios das nächste Mal nach externen Befehlen schaut

Diese Verzögerungen können minimiert werden, indem...

man sicherstellt, das der Nagios-Prozess auf Host E die Dienste in einer hohen Frequenz (erneut) überprüft. Dies wird ermöglicht, indem man das check_interval- und das retry_interval-Argument in jeder Dienst-Definition erhöht.
man sicherstellt, dass die Anzahl der erneuten Überprüfungs-Versuche für Host A (von Host E aus) nicht zu hoch gesetzt wird, um Probleme auf Host A schnell zu erkennen. Dies wird durch die Benutzung des max_check_attempts-Arguments in der Host-Definition ermöglicht.
man die Frequenz der Überprüfung der external command auf Host E erhöht. Dies ist möglich durch eine Anpassung der command_check_interval-Option in der Haupt-Konfigurationsdatei.

Wenn Nagios auf Host A wieder läuft gibt es ausserdem eine Zeitverzögerung bevor Host E in den Slave-Status zurückfällt. Diese Verzögerung beeinflusst die folgenden Dinge...

Die Zeit zwischen der Entwarnung auf Host A und dem Zeitpunkt zu dem der Nagios-Prozess auf Host E die Entwarnung entdeckt.
Die Zeit zwischen der Ausführung des Event Handlers auf Host A und dem nächsten Zeitpunkt zu dem der Nagios-Prozess auf Host E die externen Befehle verarbeitet.

Die exakte Zeitverzögerung zwischen dem Transfer der Überwachungs-Verantwortung wird variieren, je nachdem wie viele Dienste definiert sind, dem Intervall in dem Dienste überprüft werden und einer Portion reines Glücks. Aber es definitiv besser als gar keine Redundanz...

Spezielle Fälle

Hier ist eine der Dinge, vor denen man sich in acht nehmen sollte...
Wenn Host A nicht mehr erreichbar ist, werden die Benachrichtigungen auf Host E aktiviert und der Slave-Server übernimmt die Verantwortung über die Netzwerk-Überwachung und die Kontakt-Benachrichtigungen. Kehrt Host A zurück, werden die Benachrichtigungen auf Host E deaktiviert.
Sollte - bei der Rückkehr von Host A - der Nagios-Prozess auf Host A nicht richtig starten, gibt es einen Zeitraum zu dem kein Host die Kontakte über Probleme benachrichtigt! Zum Glück nimmt sich die Logik für Dienst-Überprüfungen von Nagios diesem Problem an. Das nächste Mal, wenn der Nagios-Prozess auf Host E den Status des Nagios-Prozesses auf Host A überprüft wird er erkennen, dass dieser nicht läuft. Host E wird anschliessend wieder Master werden und die Benachrichtigungen von Host E aus versandt.

Der exakte Zeitraum in dem kein Host die Überwachung des Netzwerkes übernimmt, ist hart zu bestimmen. Allerdings kann man diesen Zeitraum minimieren, indem man die Frequenz der Dienst-Überprüfungen (von Host E aus) für den Nagios-Prozess auf Host A erhöht. Der Rest ist reine Glückssache aber der Zeitraum des "Totalausfalles" sollte nicht zu lang dauern und somit nicht zu schwerwiegend sein.

Szenario 2 - ausfallsichere Überwachung

Einleitung

Ausfallsichere Überwachung ist zwar auch nicht schwer, aber leicht unterschiedlich zu der redundanten Überwachung, die zuvor in Szenario 1 beschrieben wurde.

Ziele

Das Hauptziel einer ausfallsicheren Überwachung ist es, einen Nagios-Prozess auf dem Slave-Server zu haben, der sich solange im Leerlauf befindet, wie der Nagios-Prozess auf dem Master-Host läuft. Fällt der Nagios-Prozess auf dem Master-Server aus (oder der ganze Server wird unerreichbar), startet der Nagios-Prozess auf dem Slave-Server die komplette Netzwerk-Überwachung.

Während es die in Szenario 1 beschriebene Methode erlaubt auch weiterhin Benachrichtigungen zu empfangen, wenn der Master-Überwachungsserver ausfällt, hat dieses Szenario einige Stolperfallen. Das grösste Problem ist, dass der Slave-Host die gleichen Dienste und Hosts überwacht wie auch der Master-Server, alle Dienste und Hosts werden also doppelt überprüft!
Dies kann einige Probleme durch die Verdoppelung des Traffics und der Load auf den überwachten Maschinen bedeuten, falls eine Vielzahl von Diensten konfiguriert wurde. Durch folgendes Szenario kann man diese Probleme umgehen...

Initiale Programm-Einstellungen

Die aktiven Dienst-Überprüfungen und Benachrichtigungen werden auf dem Slave-Host durch die execute_service_checks- und die enable_notifications directives. This will prevent the slave host from monitoring hosts and services and sending out notifications while the Nagios process on the master host is still up and running. Make sure you also have the check_external_commands-Directive deaktiviert.

Master-Prozess-Überprüfung

Man konfiguriert einen Cron-Job auf dem Slave-Host, der periodisch (z.B. minütlich) ein Skript laufen lässt, das den Status des Nagios-Prozesses auf dem Master-Host (z.B. durch das check_nrpe-Plugin auf dem Slave-Host und dem nrpe-Daemon und das check_nagios-Plugin auf dem Master-Host) überprüft. Das Skript sollte den Return-Code des check_nrpe-Plugins überprüfen. Gibt das Plugin einen nicht-OK-Status zurück, muss das Skript die richtigen Befehle an die externe Befehlsdatei senden um die Benachrichtigungen und die aktiven Dienst-Überprüfungen zu aktivieren. Gibt das Plugin einen OK-Status zurück, sollte das Skript die Befehle an die externe Befehlsdatei schicken, um sowohl die Benachrichtigungen als auch die aktiven Dienst-Überprüfungen zu deaktivieren.

Durch diese Variante erhält man ein Setup, in dem nur ein Prozess die Hosts und Dienste überwacht, während der zweite Prozess pausiert, wodurch die Effektivität wesentlich gesteigert werden kann.

Als Hinweis sei erwähnt, dass man keinen Host- und Dienst-Event Handler (wie in Szenario 1) definieren muss, da die Überwachung der Redundanz hier anders gehandhabt wird.

Zusätzliche Themen

An diesem Punkt hat man ein sehr einfaches ausfallsicheres Überwachungs-Setup aufgebaut. Trotzdem gibt es natürlich noch einige Dinge die man beachten sollte, um die Abläufe zu optimieren.

Das grosse Problem damit wie die Redundanzen bisher aufgebaut wurden ist der Fakt, dass der Slave-Host nicht den aktuellen Status der Dienste hat, wenn er die Überwachungs des Netzwerkes vom Master-Server übernimmt. Ein Weg dieses Problem zu lösen ist die Aktivierung des ocsp Befehls auf dem Master Server und ihn mit dem nsca addon die Ergebnisse von allen Dienst-Überprüfungen an den Slave Host senden zu lassen.
Der Slave Host wird dann immer aktuelle Status-Informationen für alle Dienste bereithalten, auch wenn keine aktiven Überprüfungen von dem Slave-Host ausgeführt werden. Obwohl auf dem Slave-Server die aktiven Dienst-Überprüfungen deaktiviert wurden, wird der Server - falls nötig - Host-Überprüfungen vornehmen. Das heisst, dass sowohl der Master als auch der Slave-Host Host-Überprüfungen fahren, was allerdings keine grosse Beeinträchtigung bedeutet, da der Grossteil der Überprüfungen über Dienste läuft.