5 Eskalationen
Übersicht
Mit Eskalationen können Sie benutzerdefinierte Szenarien zum Senden von Benachrichtigungen oder zum Ausführen von Remote-Befehlen erstellen.
In der Praxis bedeutet das:
- Benutzer können sofort über neue Probleme informiert werden.
- Benachrichtigungen können wiederholt werden, bis das Problem behoben ist.
- Das Senden einer Benachrichtigung kann verzögert werden.
- Benachrichtigungen können an eine andere, „höhere“ Benutzergruppe eskaliert werden.
- Remote-Befehle können sofort ausgeführt werden oder wenn ein Problem über einen längeren Zeitraum nicht behoben wird.
Aktionen werden anhand des Eskalationsschritts eskaliert. Jeder Schritt hat eine zeitliche Dauer.
Sie können sowohl die Standarddauer als auch eine benutzerdefinierte Dauer eines einzelnen Schritts festlegen. Die Mindestdauer eines Eskalationsschritts beträgt 60 Sekunden.
Sie können Aktionen wie das Senden von Benachrichtigungen oder das Ausführen von Befehlen ab jedem Schritt starten. Schritt eins ist für sofortige Aktionen vorgesehen. Wenn Sie eine Aktion verzögern möchten, können Sie sie einem späteren Schritt zuweisen. Für jeden Schritt können mehrere Aktionen definiert werden.
Die Anzahl der Eskalationsschritte ist nicht begrenzt.
Eskalationen werden beim Konfigurieren einer Operation definiert. Eskalationen werden nur für Problemoperationen unterstützt, nicht für die Wiederherstellung.
Verschiedene Aspekte des Eskalationsverhaltens
Betrachten wir, was unter verschiedenen Umständen passiert, wenn eine Aktion mehrere Eskalationsschritte enthält.
| Situation | Verhalten |
|---|---|
| Der betreffende Host geht in die Wartung, nachdem die erste Problembenachrichtigung gesendet wurde | Abhängig von der Einstellung Operationen für unterdrückte Probleme pausieren in der Aktions-Konfiguration werden alle verbleibenden Eskalationsschritte entweder mit einer durch den Wartungszeitraum verursachten Verzögerung oder ohne Verzögerung ausgeführt. Ein Wartungszeitraum bricht Operationen nicht ab. |
| Der in der Aktionsbedingung Zeitperiode definierte Zeitraum endet, nachdem die erste Benachrichtigung gesendet wurde | Alle verbleibenden Eskalationsschritte werden ausgeführt. Die Bedingung Zeitperiode kann Operationen nicht stoppen; sie wirkt sich darauf aus, wann Aktionen gestartet bzw. nicht gestartet werden, nicht auf Operationen. |
| Ein Problem beginnt während der Wartung und besteht nach dem Ende der Wartung weiter (wird nicht behoben) | Abhängig von der Einstellung Operationen für unterdrückte Probleme pausieren in der Aktions-Konfiguration werden alle Eskalationsschritte entweder ab dem Zeitpunkt ausgeführt, an dem die Wartung endet, oder sofort. |
| Ein Problem beginnt während einer Keine-Daten-Wartung und besteht nach dem Ende der Wartung weiter (wird nicht behoben) | Es muss gewartet werden, bis der Auslöser auslöst, bevor alle Eskalationsschritte ausgeführt werden. |
| Verschiedene Eskalationen folgen in kurzer Folge aufeinander und überlappen sich | Die Ausführung jeder neuen Eskalation ersetzt die vorherige Eskalation, jedoch wird bei der vorherigen Eskalation immer mindestens ein Eskalationsschritt ausgeführt. Dieses Verhalten ist relevant bei Aktionen für Ereignisse, die bei JEDER Problemauswertung des Auslösers erstellt werden. |
| Während einer laufenden Eskalation (z. B. beim Senden einer Nachricht), basierend auf einem beliebigen Ereignistyp: - die Aktion wird deaktiviert Basierend auf einem Auslöser-Ereignis: - der Auslöser wird deaktiviert - der Host oder der Datenpunkt wird deaktiviert Basierend auf einem internen Ereignis über Auslöser: - der Auslöser wird deaktiviert Basierend auf einem internen Ereignis über Datenpunkte/Low-Level-Discovery-Regeln: - der Datenpunkt wird deaktiviert - der Host wird deaktiviert |
Die gerade laufende Nachricht wird gesendet, und danach wird noch eine weitere Nachricht in der Eskalation gesendet. Die Folgenachricht enthält am Anfang des Nachrichtentextes den Abbruchtext (HINWEIS: Eskalation abgebrochen) mit Angabe des Grundes (zum Beispiel HINWEIS: Eskalation abgebrochen: Aktion '<Aktionsname>' deaktiviert). Auf diese Weise wird der Empfänger darüber informiert, dass die Eskalation abgebrochen wurde und keine weiteren Schritte ausgeführt werden. Diese Nachricht wird an alle gesendet, die zuvor Benachrichtigungen erhalten haben. Der Grund für den Abbruch wird auch in die Server-Logdatei geschrieben (ab Debug Level 3=Warning). Beachten Sie, dass die Nachricht Eskalation abgebrochen auch gesendet wird, wenn die Operationen abgeschlossen sind, aber Wiederherstellungsoperationen konfiguriert sind und noch nicht ausgeführt wurden. |
| Während einer laufenden Eskalation (z. B. beim Senden einer Nachricht) wird die Aktion gelöscht | Es werden keine weiteren Nachrichten gesendet. Die Information wird in die Server-Logdatei geschrieben (ab Debug Level 3=Warning), zum Beispiel: escalation canceled: action id:334 deleted |
Eskalationsbeispiele
Beispiel 1
Senden einer wiederholten Benachrichtigung einmal alle 30 Minuten (insgesamt 5-mal) an eine Gruppe „MySQL-Administratoren“. So konfigurieren Sie dies:
- Legen Sie auf der Registerkarte Operations die Default operation step duration auf „30m“ (30 Minuten) fest.
- Setzen Sie die Eskalations-Steps von „1“ bis „5“.
- Wählen Sie die Gruppe „MySQL-Administratoren“ als Empfänger der Nachricht aus.
Benachrichtigungen werden 0:00, 0:30, 1:00, 1:30 und 2:00 Stunden nach Beginn des Problems gesendet (es sei denn, das Problem wird natürlich früher behoben).
Wenn das Problem behoben wird und eine Wiederherstellungsnachricht konfiguriert ist, wird sie an diejenigen gesendet, die innerhalb dieses Eskalationsszenarios mindestens eine Problembenachrichtigung erhalten haben.
Wenn der Auslöser, der eine aktive Eskalation erzeugt hat, deaktiviert wird, sendet Zabbix eine entsprechende Informationsnachricht an alle, die bereits Benachrichtigungen erhalten haben.
Beispiel 2
Senden einer verzögerten Benachrichtigung über ein seit Langem bestehendes Problem. Zur Konfiguration:
- Setzen Sie im Reiter Operations die Default operation step duration auf „10h“ (10 Stunden).
- Setzen Sie die Eskalations-Steps von „2“ bis „2“.
Eine Benachrichtigung wird nur in Schritt 2 des Eskalationsszenarios gesendet, also 10 Stunden nach Beginn des Problems.
Sie können den Nachrichtentext beispielsweise in „Das Problem besteht seit mehr als 10 Stunden“ ändern.
Beispiel 3
Eskalation des Problems an den Vorgesetzten.
Im ersten obigen Beispiel haben wir den periodischen Versand von Nachrichten an MySQL-Administratoren konfiguriert. In diesem Fall erhalten die Administratoren vier Nachrichten, bevor das Problem an den Datenbankmanager eskaliert wird. Beachten Sie, dass der Manager nur dann eine Nachricht erhält, wenn das Problem noch nicht bestätigt wurde, also vermutlich noch niemand daran arbeitet.
Details zu Operation 2:
Beachten Sie die Verwendung des Makros {ESC.HISTORY} in der angepassten Nachricht. Das Makro enthält Informationen über alle zuvor ausgeführten Schritte dieser Eskalation, wie gesendete Benachrichtigungen und ausgeführte Befehle.
Beispiel 4
Ein komplexeres Szenario. Nach mehreren Nachrichten an die MySQL-Administratoren und einer Eskalation an den Manager wird Zabbix versuchen, die MySQL-Datenbank neu zu starten. Dies geschieht, wenn das Problem seit 2:30 Stunden besteht und nicht bestätigt wurde.
Wenn das Problem weiterhin besteht, sendet Zabbix nach weiteren 30 Minuten eine Nachricht an alle Gastbenutzer.
Wenn dies nicht hilft, startet Zabbix nach einer weiteren Stunde den Server mit der MySQL-Datenbank (zweiter Remote-Befehl) mithilfe von IPMI-Befehlen neu.
Beispiel 5
Eine Eskalation mit mehreren Operationen, die sich überschneidende Schrittbereiche und benutzerdefinierte Intervalle haben. Die standardmäßige Operations-Schrittdauer beträgt 30 Minuten.
Benachrichtigungen werden wie folgt gesendet:
- An MySQL-Administratoren um 0:00, 0:30, 1:00 und 1:30 nach Beginn des Problems.
- An den Datenbankmanager um 2:00 und 2:10 (die kürzere benutzerdefinierte Schrittdauer von 10 Minuten, die in der nachfolgenden Operation definiert ist, überschreibt die hier konfigurierte längere Schrittdauer von 1 Stunde, wie in Operationsdetails für Schrittdauer beschrieben, wenn sich Schritte überschneiden).
- An Zabbix-Administratoren um 2:00, 2:10 und 2:20 nach Beginn des Problems (die benutzerdefinierte Schrittdauer von 10 Minuten wird angewendet).
- An Gastbenutzer um 4:00 nach Beginn des Problems (die standardmäßige Schrittdauer von 30 Minuten gilt zwischen den Schritten 8 und 11).