Einleitung

Der aktuelle Status eines Dienstes oder Hosts wird an Hand von zwei Komponenten erkannt: der Status des Hosts oder Dienstes (z.B. OK, WARNING, UP, DOWN, etc.) und der Typ des Status in dem sich der Host oder der Dienst befindet. Es gibt zwei Typen von Stati in Nagios - "soft" und "hard" Stati. Status Typen sind der kritische Teil von Nagios' Überwachungs-Logik. Sie werden benutzt um zu erkennen, wann "Event Handler" ausgeführt werden und wann Benachrichtigungen verschickt werden.

Wiederholung von Dienst- und Host-Überprüfungen

Um Fehlalarme zu verhindern, erlaubt es Nagios zu konfigurieren, wie oft eine Dienst- oder Host-Überprüfung erneut versucht wird, bevor der Dienst oder Host als problematisch eingestuft wird. Die Maximale Anzahl der Wiederholungen wird von der <max_check_attempts>-Option in der Dienst- bzw. Host-Definition gesteuert. Aufgrund dieser Definition wird erkannt in welchem Typ von Status sich der Dienst oder Host gerade befindet. Es gibt zwar ein paar Ausnahmen in der Logik der Dienst-Überwachung, aber diese werden für erstmal ignorieren.
Werfen wir einen Blick auf die unterschiedlichen Status-Typen von Diensten...

Softe Stati

"Softe Stati" treten bei Diensten und Hosts in den folgenden Situationen auf:

• Wenn die Überprüfung eines Dienstes oder Hosts in einem nicht-OK-Status endet und die Überprüfung noch nicht so oft wie in der <max_check_attempts>-Option angegeben wiederholt wurde, befindet sich der Dienst oder Host in einem "soften" Fehler-Status.
• Wenn ein Dienst oder Host aus einem "soften" Fehler-Status widerhergestellt wird, wird dies "soft recovery" genannt.

Softe Status Ereignisse

Was passiert, wenn sich ein Dienst oder Host in einem "soften" Fehler-Status befindet oder ein "soft recovery" passiert?

• Der softe Fehler oder Wiederherstellung wird mitgeschrieben, wenn die log_service_retries- oder log_host_retries-Optionen in der Haupt-Konfigurationsdatei aktiviert wurden.
• Event Handler werden ausgeführt (falls welche definiert wurden), um die soften Fehler oder Widerherstellungen für einen Dienst oder Host weiter zu bearbeiten. (Bevor allerdings ein Event Handler ausgeführt wird, wird das $STATETYPE$-Macro auf "SOFT" gesetzt).
• Nagios sendet keine Benachrichtigungen an die Kontaktpersonen, da (noch) kein "echtes" Problem für den Dienst oder Host erkannt wurde.

Wie man sehen kann, ist das einzige was wirklich in einem soften Status passiert, die Ausführung der Event Handler. Die Benutzung von Event Handlern kann z.B. dafür nützlich sein, um pro-aktiv ein Problem zu beheben (falls dieses durch einen automatisierbaren Vorgang möglich ist), bevor das Problem in einen "harten" Status fällt.
Weitere Informationen über Event Handler können hier gefunden werden.

Harte Stati

Harte Stati treten bei einem Dienst in den folgenden Situationen auf (harte Stati von Hosts werden später besprochen)...

• Wenn das Ergebnis einer Dienst-Überprüfung einen nicht-OK Status zurückgibt und die Dienst-Überprüfung bereits so oft wiederholt wurde, wie durch die <max_check_attempts>-Option in der Dienst-Definition angegeben. Dies ist dann ein harter Fehler-Status.
• Wenn ein Dienst aus einem harten Fehler-Status wiederhergestellt wird, dann ist dies eine "harte Wiederherstellung".
• Wenn das Ergebnis einer Dienst-Überprüfung einen nicht-OK Status zurückgibt und der zu dem Dienst korrespondierende Host entweder DOWN oder UNREACHABLE ist. Dies ist zwar eine Ausnahme zu der allgemeinen Überwachugs-Logik von Nagios, sie macht aber absolut Sinn. Wenn der Host nicht erreichbar ist, warum sollte man diesen Dienst erneut überprüfen wollen?

Harte Stati treten bei einem Host in den folgenden Situationen auf...

• Wenn das Ergebnis einer Host-Überprüfung einen nicht-OK Status zurückgibt und die Host-Überprüfung bereits so oft wiederholt wurde, wie durch die <max_check_attempts>-Option in der Host-Definition angegeben. Dies ist dann ein harter Fehler-Status.
• Wenn ein Host von aus einem harten Fehler-Status wiedehergestellt wird, dann ist dies eine "harte Wiederherstellung".

Harte Status-Änderungen

Bevor wir besprechen was passiert wenn sich ein Dienst oder Host in einem harten Status befindet, müssen wir über harte Status-Änderungen bescheid wissen. Harte Status-Änderungen treten auf wenn sich der Status eines Dienstes oder Hosts...

• von einem harten OK-Status in einen harten nicht-OK-Status ändert
• von einem harten nicht-OK-Status in einen harten OK-Status ändert
• von einem harten nicht-OK-Status in einen anderen harten nicht-OK-Status ändert
  (z.B. von einem harten WARNING-Status in einen harten UNKNOWN-Status)

Harte Status-Events

Was passiert, wenn sich ein Dienst oder Host in einem harten Fehler-Status befindet und eine harte Wiederherstelltung erfährt? Es kommt darauf an, ob ein harter Status-Wechsel (wie in dem Punkt zuvor beschrieben) passiert ist.

Falls eine harte Status-Änderung erfolgt ist und der Dienst oder Host sich weiterhin in einem nicht-OK-Status befindet, passieren die folgenden Aktionen:

• Das harte Dienst- oder Host-Problem wird protokolliert
• Event Handler werden - falls definiert - ausgeführt, um das harte Problem des Dienstes oder Hosts zu verarbeiten. (Bevor irgendein Event Handler ausgeführt wird, wird das $STATETYPE$-Macro auf "HARD" gesetzt).
• Die Kontaktpersonen werden über das Dienst- bzw. Host-Problem benachrichtigt (falls die Benachrichtigungs-Logik dies erlaubt).

Falls eine harte Status-Änderung erfolgt ist und der Dienst oder Host sich in einem OK-Status befindet, werden die folgenden Aktionen ausgelöst:

• Die "harte" Wiederherstellung des Dienstes oder Hosts wird protokolliert.
• Event Handler werden - falls definiert - ausgeführt, um die harte Wiederherstellung des Dienstes oder Hosts zu verarbeiten. (Bevor irgendein Event Handler ausgeführt wird, wird das $STATETYPE$-Macro auf "HARD" gesetzt).
• Die Kontaktpersonen werden über die Wiederherstellung des Dienst- bzw. Host-Problems benachrichtigt (falls die Benachrichtigungs-Logik dies erlaubt).

Falls eine harte Status-Änderung NICHT erfolgt is und der Dienst oder Host sich in einem nicht-OK-Status befindet, passieren die folgenden Aktionen:

• Die Kontaktpersonen werden über das Dienst- bzw. Host-Problem benachrichtigt (falls die Benachrichtigungs-Logik dies erlaubt).

Falls KEINE harte Status-Änderung erfolgt ist und der Dienst oder Host sich in einem OK-Status befindet, werden keinerlei Aktionen ausgeführt, da der Dienst oder Host sich in einem OK-Status befinden und dies auch bei der letzten Überprüfung der Fall war.