5 Escalation
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.
Vari aspetti del comportamento dell'escalation
Consideriamo cosa succede in diverse circostanze se un'azione contiene diversi passaggi di escalation.
| Situazione | Comportamento |
|---|---|
| L'host in questione entra in manutenzione dopo l'invio della notifica iniziale del problema | A seconda dell'impostazione Pause operations for suppressed problems nella configurazione dell'azione, tutti i restanti passaggi di escalation vengono eseguiti con un ritardo causato dal periodo di manutenzione oppure senza ritardo. Un periodo di manutenzione non annulla le operazioni. |
| Il periodo di tempo definito nella condizione dell'azione Time period termina dopo l'invio della notifica iniziale | Tutti i restanti passaggi di escalation vengono eseguiti. La condizione Time period non può interrompere le operazioni; ha effetto su quando le azioni vengono avviate o non avviate, non sulle operazioni. |
| Un problema inizia durante la manutenzione e continua (non viene risolto) dopo la fine della manutenzione | A seconda dell'impostazione Pause operations for suppressed problems nella configurazione dell'azione, tutti i passaggi di escalation vengono eseguiti o dal momento in cui termina la manutenzione oppure immediatamente. |
| Un problema inizia durante una manutenzione no-data e continua (non viene risolto) dopo la fine della manutenzione | È necessario attendere che il trigger si attivi prima che vengano eseguiti tutti i passaggi di escalation. |
| Diverse escalation si susseguono a breve distanza e si sovrappongono | L'esecuzione di ogni nuova escalation sostituisce la precedente, ma almeno un passaggio di escalation della precedente viene sempre eseguito. Questo comportamento è rilevante nelle azioni sugli eventi creati a OGNI valutazione del problema del trigger. |
| Durante un'escalation in corso (ad esempio, durante l'invio di un messaggio), in base a qualsiasi tipo di evento: - l'azione viene disabilitata In base a un evento trigger: - il trigger viene disabilitato - l'host o l'item vengono disabilitati In base a un evento interno relativo ai trigger: - il trigger viene disabilitato In base a un evento interno relativo a item/regole di low-level discovery: - l'item viene disabilitato - l'host viene disabilitato |
Il messaggio in corso viene inviato e poi viene inviato ancora un altro messaggio nell'escalation. Il messaggio successivo conterrà il testo di annullamento all'inizio del corpo del messaggio (NOTE: Escalation canceled), indicando il motivo (ad esempio, NOTE: Escalation canceled: action '<Action name>' disabled). In questo modo il destinatario viene informato che l'escalation è stata annullata e che non verranno eseguiti altri passaggi. Questo messaggio viene inviato a tutti coloro che hanno ricevuto le notifiche in precedenza. Il motivo dell'annullamento viene anche registrato nel file di log del server (a partire da Debug Level 3=Warning). Si noti che il messaggio Escalation canceled viene inviato anche se le operazioni sono terminate, ma sono configurate operazioni di ripristino che non sono ancora state eseguite. |
| Durante un'escalation in corso (ad esempio, durante l'invio di un messaggio) l'azione viene eliminata | Non vengono inviati altri messaggi. L'informazione viene registrata nel file di log del server (a partire da Debug Level 3=Warning), ad esempio: escalation canceled: action id:334 deleted |
Esempi di escalation
Esempio 1
Invio di una notifica ripetuta una volta ogni 30 minuti (5 volte in totale) a un gruppo "MySQL Administrators". Per configurarlo:
- Nella scheda Operations, impostare Default operation step duration su "30m" (30 minuti).
- Impostare i Steps dell'escalation da "1" a "5".
- Selezionare il gruppo "MySQL Administrators" come destinatario del messaggio.
Le notifiche verranno inviate a 0:00, 0:30, 1:00, 1:30, 2:00 ore dopo l'inizio del problema (a meno che, naturalmente, il problema non venga risolto prima).
Se il problema viene risolto ed è configurato un messaggio di ripristino, esso verrà inviato a coloro che hanno ricevuto almeno un messaggio di problema all'interno di questo scenario di escalation.
Se il trigger che ha generato un'escalation attiva viene disabilitato, Zabbix invia un messaggio informativo al riguardo a tutti coloro che hanno già ricevuto notifiche.
Esempio 2
Invio di una notifica ritardata relativa a un problema persistente. Per configurare:
- Nella scheda Operations, impostare Default operation step duration su "10h" (10 ore).
- Impostare gli Steps dell'escalation da "2" a "2".
Una notifica verrà inviata solo allo Step 2 dello scenario di escalation, ovvero 10 ore dopo l'inizio del problema.
È possibile personalizzare il testo del messaggio con qualcosa come "Il problema dura da più di 10 ore".
Esempio 3
Escalation del problema al responsabile.
Nel primo esempio sopra abbiamo configurato l'invio periodico di messaggi agli amministratori MySQL. In questo caso, gli amministratori riceveranno quattro messaggi prima che il problema venga escalato al responsabile del database. Si noti che il responsabile riceverà un messaggio solo nel caso in cui il problema non sia ancora stato confermato, presumibilmente perché nessuno ci sta ancora lavorando.
Dettagli dell'operazione 2:
Si noti l'uso della macro {ESC.HISTORY} nel messaggio personalizzato. La macro conterrà informazioni su tutti i passaggi eseguiti in precedenza in questa escalation, come le notifiche inviate e i comandi eseguiti.
Esempio 4
Uno scenario più complesso. Dopo più messaggi agli amministratori MySQL e l'escalation al manager, Zabbix proverà a riavviare il database MySQL. Ciò avverrà se il problema esiste da 2:30 ore e non è stato riconosciuto.
Se il problema esiste ancora, dopo altri 30 minuti Zabbix invierà un messaggio a tutti gli utenti guest.
Se questo non aiuta, dopo un'altra ora Zabbix riavvierà il server con il database MySQL (secondo comando remoto) utilizzando comandi IPMI.
Esempio 5
Un'escalation con diverse operazioni che hanno intervalli di step sovrapposti e intervalli personalizzati. La durata predefinita dello step dell'operazione è di 30 minuti.
Le notifiche verranno inviate come segue:
- Agli amministratori MySQL a 0:00, 0:30, 1:00 e 1:30 dopo l'inizio del problema.
- Al responsabile del database a 2:00 e 2:10 (la durata personalizzata dello step più breve di 10 minuti definita nell'operazione successiva prevale sulla durata dello step più lunga di 1 ora configurata qui, come descritto in Dettagli dell'operazione per Durata dello step quando gli step si sovrappongono).
- Agli amministratori Zabbix a 2:00, 2:10 e 2:20 dopo l'inizio del problema (viene applicata la durata personalizzata dello step di 10 minuti).
- Agli utenti guest a 4:00 dopo l'inizio del problema (la durata predefinita dello step di 30 minuti entra in vigore tra gli step 8 e 11).