[comment]: # translation:outdated
[comment]: # ({bbb0e074-bbb0e074})
# 5 Eskalationen
[comment]: # ({/bbb0e074-bbb0e074})
[comment]: # ({5d89a227-3bb564c1})
#### Ü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 basierend auf dem **Eskalationsschritt** 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 von jedem Schritt aus 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](operation#configuring-an-operation) definiert. Eskalationen werden nur für Problemoperationen unterstützt, nicht für Wiederherstellungen.
[comment]: # ({/5d89a227-3bb564c1})
[comment]: # ({8493a88c-362c7cc2})
##### 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](/manual/config/notifications/action/operation#configuring-an-operation) 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](/manual/config/notifications/action/operation#configuring-an-operation) werden alle Eskalationsschritte entweder ab dem Zeitpunkt ausgeführt, an dem die Wartung endet, oder sofort.|
|*Ein Problem beginnt während einer Wartung ohne Daten 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 Nachrichtentexts den Abbruchtext (*HINWEIS: Eskalation abgebrochen*) mit Angabe des Grundes (zum Beispiel *HINWEIS: Eskalation abgebrochen: Aktion '' 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 außerdem in die Server-Logdatei geschrieben (ab [Debug Level](/manual/appendix/config/zabbix_server) 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](/manual/appendix/config/zabbix_server) 3=Warning), zum Beispiel: `escalation canceled: action id:334 deleted`|
[comment]: # ({/8493a88c-362c7cc2})
[comment]: # ({187988b1-187988b1})
#### Eskalationsbeispiele
[comment]: # ({/187988b1-187988b1})
[comment]: # ({4d3a4940-0e2a0e62})
##### 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.
{width="600"}
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.
::: noteclassic
Wenn der Auslöser, der eine aktive Eskalation erzeugt hat,
deaktiviert wird, sendet Zabbix eine entsprechende Informationsnachricht an alle, die
bereits Benachrichtigungen erhalten haben.
:::
[comment]: # ({/4d3a4940-0e2a0e62})
[comment]: # ({514a38fa-9f5d0fb5})
##### 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“.
{width="600"}
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.
[comment]: # ({/514a38fa-9f5d0fb5})
[comment]: # ({d6340061-2f4800fa})
##### 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.
{width="600"}
Details zu Operation 2:
{width="600"}
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.
[comment]: # ({/d6340061-2f4800fa})
[comment]: # ({aba91a40-aba91a40})
##### 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.
{width="600"}
[comment]: # ({/aba91a40-aba91a40})
[comment]: # ({939c3ed9-919f413f})
##### Beispiel 5
Eine Eskalation mit mehreren Operationen, die sich überschneidende Schrittbereiche und benutzerdefinierte Intervalle haben. Die standardmäßige Operations-Schrittdauer beträgt 30 Minuten.
{width="600"}
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](/manual/config/notifications/action/operation#operation-details) 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).
[comment]: # ({/939c3ed9-919f413f})