[comment]: # ({bbb0e074-bbb0e074})
# 5 Escalation
[comment]: # ({/bbb0e074-bbb0e074})
[comment]: # ({5d89a227-3bb564c1})
#### Panoramica
Con le escalation è possibile creare scenari personalizzati per l'invio di
notifiche o l'esecuzione di comandi remoti.
In termini pratici, ciò significa che:
- Gli utenti possono essere informati immediatamente dei nuovi problemi.
- Le notifiche possono essere ripetute finché il problema non viene risolto.
- L'invio di una notifica può essere ritardato.
- Le notifiche possono essere escalate a un altro gruppo di utenti di livello "superiore".
- I comandi remoti possono essere eseguiti immediatamente oppure quando un problema non viene risolto
per un lungo periodo.
Le azioni vengono escalate in base al **passo di escalation**. Ogni passo ha una
durata temporale.
È possibile definire sia la durata predefinita sia una durata personalizzata di un
singolo passo. La durata minima di un passo di escalation è di 60
secondi.
È possibile avviare azioni, come l'invio di notifiche o l'esecuzione di
comandi, da qualsiasi passo. Il primo passo è destinato alle azioni immediate. Se si desidera
ritardare un'azione, è possibile assegnarla a un passo successivo. Per ogni passo,
possono essere definite diverse azioni.
Il numero di passi di escalation non è limitato.
Le escalation vengono definite durante la [configurazione di un'operazione](operation#configuring-an-operation). Le escalation sono
supportate solo per le operazioni sui problemi, non per il ripristino.
[comment]: # ({/5d89a227-3bb564c1})
[comment]: # ({8493a88c-362c7cc2})
##### Aspetti vari del comportamento dell'escalation
Consideriamo cosa accade in diverse circostanze se un'azione
contiene diversi passaggi di escalation.
|Situation|Behavior|
|---------|--------|
|*The host in question goes into maintenance after the initial problem notification is sent*|Depending on the *Pause operations for suppressed problems* setting in action [configuration](/manual/config/notifications/action/operation#configuring-an-operation), all remaining escalation steps are executed either with a delay caused by the maintenance period or without delay. A maintenance period does not cancel operations.|
|*The time period defined in the **Time period** action condition ends after the initial notification is sent*|All remaining escalation steps are executed. The *Time period* condition cannot stop operations; it has effect with regard to when actions are started/not started, not operations.|
|*A problem starts during maintenance and continues (is not resolved) after maintenance ends*|Depending on the *Pause operations for suppressed problems* setting in action [configuration](/manual/config/notifications/action/operation#configuring-an-operation), all escalation steps are executed either from the moment maintenance ends or immediately.|
|*A problem starts during a no-data maintenance and continues (is not resolved) after maintenance ends*|It must wait for the trigger to fire, before all escalation steps are executed.|
|*Different escalations follow in close succession and overlap*|The execution of each new escalation supersedes the previous escalation, but for at least one escalation step that is always executed on the previous escalation. This behavior is relevant in actions upon events that are created with EVERY problem evaluation of the trigger.|
|*During an escalation in progress (like a message being sent), based on any type of event:
- the action is disabled
Based on trigger event:
- the trigger is disabled
- the host or item is disabled
Based on internal event about triggers:
- the trigger is disabled
Based on internal event about items/low-level discovery rules:
- the item is disabled
- the host is disabled*|The message in progress is sent and then one more message on the escalation is sent. The follow-up message will have the cancellation text at the beginning of the message body (*NOTE: Escalation canceled*) naming the reason (for example, *NOTE: Escalation canceled: action '' disabled*). This way the recipient is informed that the escalation is canceled and no more steps will be executed. This message is sent to all who received the notifications before. The reason of cancellation is also logged to the server log file (starting from [Debug Level](/manual/appendix/config/zabbix_server) 3=Warning).
Note that the *Escalation canceled* message is also sent if operations are finished, but recovery operations are configured and are not executed yet.|
|*During an escalation in progress (like a message being sent) the action is deleted*|No more messages are sent. The information is logged to the server log file (starting from [Debug Level](/manual/appendix/config/zabbix_server) 3=Warning), for example: `escalation canceled: action id:334 deleted`|
[comment]: # ({/8493a88c-362c7cc2})
[comment]: # ({187988b1-187988b1})
#### Esempi di escalation
[comment]: # ({/187988b1-187988b1})
[comment]: # ({4d3a4940-0e2a0e62})
##### 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.
{width="600"}
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.
::: noteclassic
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.
:::
[comment]: # ({/4d3a4940-0e2a0e62})
[comment]: # ({514a38fa-9f5d0fb5})
##### 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".
{width="600"}
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".
[comment]: # ({/514a38fa-9f5d0fb5})
[comment]: # ({d6340061-2f4800fa})
##### 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.
{width="600"}
Dettagli dell'operazione 2:
{width="600"}
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.
[comment]: # ({/d6340061-2f4800fa})
[comment]: # ({aba91a40-aba91a40})
##### 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.
{width="600"}
[comment]: # ({/aba91a40-aba91a40})
[comment]: # ({939c3ed9-919f413f})
##### 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.
{width="600"}
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](/manual/config/notifications/action/operation#operation-details) 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).
[comment]: # ({/939c3ed9-919f413f})