5 Eskalacje
Overview
With escalations you can create custom scenarios for sending notifications or executing remote commands.
In practical terms it means that:
- Users can be informed about new problems immediately
- Notifications can be repeated until the problem is resolved
- Sending a notification can be delayed
- Notifications can be escalated to another "higher" user group
- Remote commands can be executed immediately or when a problem is not resolved for a lengthy period
Actions are escalated based on the escalation step. Each step has a duration in time.
You can define both the default duration and a custom duration of an individual step. The minimum duration of one escalation step is 60 seconds.
You can start actions, such as sending notifications or executing commands, from any step. Step one is for immediate actions. If you want to delay an action, you can assign it to a later step. For each step, several actions can be defined.
The number of escalation steps is not limited.
Escalations are defined when configuring an operation. Escalations are supported for problem operations only, not recovery.
Różne aspekty zachowania eskalacji
Rozważmy, co dzieje się w różnych okolicznościach, jeśli akcja zawiera kilka kroków eskalacji.
| Sytuacja | Zachowanie |
|---|---|
| Dany host przechodzi w tryb maintenance po wysłaniu początkowego powiadomienia o problemie | W zależności od ustawienia Pause operations for suppressed problems w konfiguracji akcji, wszystkie pozostałe kroki eskalacji są wykonywane albo z opóźnieniem spowodowanym okresem maintenance, albo bez opóźnienia. Okres maintenance nie anuluje operacji. |
| Okres czasu zdefiniowany w warunku akcji Time period kończy się po wysłaniu początkowego powiadomienia | Wszystkie pozostałe kroki eskalacji są wykonywane. Warunek Time period nie może zatrzymać operacji; wpływa on na to, kiedy akcje są uruchamiane lub nie są uruchamiane, a nie na operacje. |
| Problem rozpoczyna się podczas maintenance i trwa dalej (nie zostaje rozwiązany) po zakończeniu maintenance | W zależności od ustawienia Pause operations for suppressed problems w konfiguracji akcji, wszystkie kroki eskalacji są wykonywane albo od momentu zakończenia maintenance, albo natychmiast. |
| Problem rozpoczyna się podczas maintenance typu no-data i trwa dalej (nie zostaje rozwiązany) po zakończeniu maintenance | Należy poczekać, aż wyzwalacz zostanie uruchomiony, zanim zostaną wykonane wszystkie kroki eskalacji. |
| Różne eskalacje następują po sobie w krótkich odstępach czasu i nakładają się | Wykonanie każdej nowej eskalacji zastępuje poprzednią eskalację, ale co najmniej jeden krok eskalacji z poprzedniej eskalacji jest zawsze wykonywany. To zachowanie ma znaczenie w akcjach dla zdarzeń tworzonych przy KAŻDEJ ocenie problemu przez wyzwalacz. |
| W trakcie trwającej eskalacji (na przykład podczas wysyłania wiadomości), na podstawie dowolnego typu zdarzenia: - akcja zostaje wyłączona Na podstawie zdarzenia wyzwalacza: - wyzwalacz zostaje wyłączony - host lub pozycja zostaje wyłączony/wyłączona Na podstawie zdarzenia wewnętrznego dotyczącego wyzwalaczy: - wyzwalacz zostaje wyłączony Na podstawie zdarzenia wewnętrznego dotyczącego pozycji/reguł low-level discovery: - pozycja zostaje wyłączona - host zostaje wyłączony |
Wiadomość będąca w trakcie wysyłania zostaje wysłana, a następnie wysyłana jest jeszcze jedna wiadomość w ramach eskalacji. Wiadomość uzupełniająca będzie miała na początku treści komunikat anulowania (NOTE: Escalation canceled) z podaniem przyczyny (na przykład NOTE: Escalation canceled: action '<Nazwa akcji>' disabled). W ten sposób odbiorca zostaje poinformowany, że eskalacja została anulowana i żadne dalsze kroki nie zostaną wykonane. Ta wiadomość jest wysyłana do wszystkich, którzy wcześniej otrzymali powiadomienia. Przyczyna anulowania jest również zapisywana w pliku dziennika serwera (od Debug Level 3=Warning). Zwróć uwagę, że wiadomość Escalation canceled jest również wysyłana, jeśli operacje zostały zakończone, ale operacje odzyskiwania są skonfigurowane i nie zostały jeszcze wykonane. |
| W trakcie trwającej eskalacji (na przykład podczas wysyłania wiadomości) akcja zostaje usunięta | Żadne dalsze wiadomości nie są wysyłane. Informacja ta jest zapisywana w pliku dziennika serwera (od Debug Level 3=Warning), na przykład: escalation canceled: action id:334 deleted |
Przykłady eskalacji
Przykład 1
Wysyłanie powtarzanego powiadomienia co 30 minut (łącznie 5 razy) do grupy „MySQL Administrators”. Aby to skonfigurować:
- Na karcie Operations ustaw Default operation step duration na „30m” (30 minut).
- Ustaw Steps eskalacji od „1” do „5”.
- Wybierz grupę „MySQL Administrators” jako odbiorców wiadomości.
Powiadomienia będą wysyłane po 0:00, 0:30, 1:00, 1:30 i 2:00 godziny od wystąpienia problemu (chyba że problem zostanie oczywiście rozwiązany wcześniej).
Jeśli problem zostanie rozwiązany i skonfigurowano wiadomość o odzyskaniu, zostanie ona wysłana do tych, którzy otrzymali co najmniej jedną wiadomość o problemie w ramach tego scenariusza eskalacji.
Jeśli wyzwalacz, który wygenerował aktywną eskalację, zostanie wyłączony, Zabbix wyśle wszystkim osobom, które otrzymały już powiadomienia, wiadomość informacyjną na ten temat.
Przykład 2
Wysyłanie opóźnionego powiadomienia o długotrwałym problemie. Aby to skonfigurować:
- Na karcie Operations ustaw Default operation step duration na „10h” (10 godzin).
- Ustaw Steps eskalacji od „2” do „2”.
Powiadomienie zostanie wysłane dopiero w kroku 2 scenariusza eskalacji, czyli 10 godzin po wystąpieniu problemu.
Możesz dostosować treść wiadomości do czegoś w rodzaju „Problem trwa dłużej niż 10 godzin”.
Przykład 3
Eskalacja problemu do Szefa.
W pierwszym przykładzie powyżej skonfigurowaliśmy okresowe wysyłanie wiadomości do administratorów MySQL. W tym przypadku administratorzy otrzymają cztery wiadomości, zanim problem zostanie eskalowany do menedżera bazy danych. Należy pamiętać, że menedżer otrzyma wiadomość tylko wtedy, gdy problem nie został jeszcze potwierdzony, co oznacza, że prawdopodobnie nikt jeszcze nad nim nie pracuje.
Szczegóły operacji 2:
Zwróć uwagę na użycie makra {ESC.HISTORY} w dostosowanej wiadomości. Makro to będzie zawierać informacje o wszystkich wcześniej wykonanych krokach tej eskalacji, takich jak wysłane powiadomienia i wykonane polecenia.
Przykład 4
Bardziej złożony scenariusz. Po wysłaniu wielu wiadomości do administratorów MySQL i eskalacji do menedżera, Zabbix spróbuje ponownie uruchomić bazę danych MySQL. Stanie się to, jeśli problem będzie występował przez 2:30 godziny i nie zostanie potwierdzony.
Jeśli problem nadal będzie występował, po kolejnych 30 minutach Zabbix wyśle wiadomość do wszystkich użytkowników gościnnych.
Jeśli to nie pomoże, po kolejnej godzinie Zabbix zrestartuje serwer z bazą danych MySQL (drugie zdalne polecenie) przy użyciu poleceń IPMI.
Przykład 5
Eskalacja z kilkoma operacjami, które mają nakładające się zakresy kroków i niestandardowe interwały. Domyślny czas trwania kroku operacji wynosi 30 minut.
Powiadomienia będą wysyłane w następujący sposób:
- Do administratorów MySQL o 0:00, 0:30, 1:00 i 1:30 od momentu wystąpienia problemu.
- Do menedżera bazy danych o 2:00 i 2:10 (krótszy niestandardowy czas trwania kroku wynoszący 10 minut, zdefiniowany w kolejnej operacji, zastępuje dłuższy czas trwania kroku wynoszący 1 godzinę skonfigurowany tutaj, zgodnie z opisem w Szczegóły operacji dla Czas trwania kroku, gdy kroki nakładają się).
- Do administratorów Zabbix o 2:00, 2:10 i 2:20 od momentu wystąpienia problemu (zastosowany jest niestandardowy czas trwania kroku wynoszący 10 minut).
- Do użytkowników guest o 4:00 od momentu wystąpienia problemu (domyślny czas trwania kroku wynoszący 30 minut obowiązuje między krokami 8 i 11).