[comment]: # ({bbb0e074-bbb0e074})
# 5 Escalades
[comment]: # ({/bbb0e074-bbb0e074})
[comment]: # ({5d89a227-3bb564c1})
#### Aperçu
Avec les escalades, vous pouvez créer des scénarios personnalisés pour l'envoi de notifications ou l'exécution de commandes à distance.
En pratique, cela signifie que :
- Les utilisateurs peuvent être informés immédiatement des nouveaux problèmes.
- Les notifications peuvent être répétées jusqu'à la résolution du problème.
- L'envoi d'une notification peut être différé.
- Les notifications peuvent être escaladées vers un autre groupe d'utilisateurs de niveau « supérieur ».
- Des commandes à distance peuvent être exécutées immédiatement ou lorsqu'un problème n'est pas résolu pendant une longue période.
Les actions sont escaladées en fonction de l'**étape d'escalade**. Chaque étape a une durée.
Vous pouvez définir à la fois la durée par défaut et une durée personnalisée pour une étape individuelle. La durée minimale d'une étape d'escalade est de 60 secondes.
Vous pouvez démarrer des actions, telles que l'envoi de notifications ou l'exécution de commandes, à partir de n'importe quelle étape. L'étape 1 est destinée aux actions immédiates. Si vous souhaitez différer une action, vous pouvez l'affecter à une étape ultérieure. Pour chaque étape, plusieurs actions peuvent être définies.
Le nombre d'étapes d'escalade n'est pas limité.
Les escalades sont définies lors de la [configuration d'une opération](operation#configuring-an-operation). Les escalades sont prises en charge uniquement pour les opérations de problème, pas pour la récupération.
[comment]: # ({/5d89a227-3bb564c1})
[comment]: # ({8493a88c-362c7cc2})
##### Aspects divers du comportement de l'escalade
Examinons ce qui se passe dans différentes circonstances si une action
contient plusieurs étapes d'escalade.
|Situation|Comportement|
|---------|--------|
|*L'hôte concerné passe en maintenance après l'envoi de la notification initiale du problème*|Selon le paramètre *Pause operations for suppressed problems* dans la [configuration](/manual/config/notifications/action/operation#configuring-an-operation) de l'action, toutes les étapes d'escalade restantes sont exécutées soit avec un délai causé par la période de maintenance, soit sans délai. Une période de maintenance n'annule pas les opérations.|
|*La période définie dans la condition d'action **Time period** se termine après l'envoi de la notification initiale*|Toutes les étapes d'escalade restantes sont exécutées. La condition *Time period* ne peut pas arrêter les opérations ; elle a un effet sur le moment où les actions sont démarrées ou non, pas sur les opérations.|
|*Un problème commence pendant une maintenance et se poursuit (n'est pas résolu) après la fin de la maintenance*|Selon le paramètre *Pause operations for suppressed problems* dans la [configuration](/manual/config/notifications/action/operation#configuring-an-operation) de l'action, toutes les étapes d'escalade sont exécutées soit à partir du moment où la maintenance se termine, soit immédiatement.|
|*Un problème commence pendant une maintenance sans données et se poursuit (n'est pas résolu) après la fin de la maintenance*|Il doit attendre que le déclencheur se déclenche avant que toutes les étapes d'escalade soient exécutées.|
|*Différentes escalades se succèdent rapidement et se chevauchent*|L'exécution de chaque nouvelle escalade remplace l'escalade précédente, mais au moins une étape d'escalade est toujours exécutée sur l'escalade précédente. Ce comportement est pertinent dans les actions sur des événements créés à chaque évaluation du problème du déclencheur.|
|*Pendant une escalade en cours (par exemple, un message est en cours d'envoi), selon tout type d'événement:
- l'action est désactivée
Selon un événement de déclencheur:
- le déclencheur est désactivé
- l'hôte ou l'élément est désactivé
Selon un événement interne concernant des déclencheurs:
- le déclencheur est désactivé
Selon un événement interne concernant des éléments/règles de découverte de bas niveau:
- l'élément est désactivé
- l'hôte est désactivé*|Le message en cours est envoyé, puis un autre message est envoyé dans le cadre de l'escalade. Le message de suivi contiendra le texte d'annulation au début du corps du message (*NOTE: Escalation canceled*) indiquant la raison (par exemple, *NOTE: Escalation canceled: action '' disabled*). De cette façon, le destinataire est informé que l'escalade est annulée et qu'aucune autre étape ne sera exécutée. Ce message est envoyé à tous ceux qui ont reçu les notifications précédentes. La raison de l'annulation est également consignée dans le fichier journal du serveur (à partir du [Debug Level](/manual/appendix/config/zabbix_server) 3=Warning).
Notez que le message *Escalation canceled* est également envoyé si les opérations sont terminées, mais que des opérations de rétablissement sont configurées et n'ont pas encore été exécutées.|
|*Pendant une escalade en cours (par exemple, un message est en cours d'envoi), l'action est supprimée*|Aucun autre message n'est envoyé. L'information est consignée dans le fichier journal du serveur (à partir du [Debug Level](/manual/appendix/config/zabbix_server) 3=Warning), par exemple : `escalation canceled: action id:334 deleted`|
[comment]: # ({/8493a88c-362c7cc2})
[comment]: # ({187988b1-187988b1})
#### Exemples d'escalade
[comment]: # ({/187988b1-187988b1})
[comment]: # ({4d3a4940-0e2a0e62})
##### Exemple 1
Envoi d’une notification répétée toutes les 30 minutes (5 fois au total)
à un groupe « MySQL Administrators ». Pour configurer cela :
- Dans l’onglet *Operations*, définissez *Default operation step duration* sur « 30m » (30 minutes).
- Définissez les *Steps* de l’escalade de « 1 » à « 5 ».
- Sélectionnez le groupe « MySQL Administrators » comme destinataires du message.
{width="600"}
Les notifications seront envoyées à 0:00, 0:30, 1:00, 1:30 et 2:00 après
le début du problème (sauf si, bien sûr, le problème est résolu plus tôt).
Si le problème est résolu et qu’un message de rétablissement est configuré, il
sera envoyé à ceux qui ont reçu au moins un message de problème dans ce
scénario d’escalade.
::: noteclassic
Si le déclencheur qui a généré une escalade active est
désactivé, Zabbix envoie un message d’information à toutes les personnes qui
ont déjà reçu des notifications.
:::
[comment]: # ({/4d3a4940-0e2a0e62})
[comment]: # ({514a38fa-9f5d0fb5})
##### Exemple 2
Envoi d'une notification différée concernant un problème de longue durée. Pour
configurer :
- Dans l'onglet *Operations*, définissez *Default operation step duration* sur « 10h » (10 heures).
- Définissez les *Steps* de l'escalade de « 2 » à « 2 ».
{width="600"}
Une notification ne sera envoyée qu'à l'étape 2 du scénario d'escalade,
soit 10 heures après le début du problème.
Vous pouvez personnaliser le texte du message avec quelque chose comme « Le problème dure depuis plus de 10 heures ».
[comment]: # ({/514a38fa-9f5d0fb5})
[comment]: # ({d6340061-2f4800fa})
##### Exemple 3
Escalade du problème vers le responsable.
Dans le premier exemple ci-dessus, nous avons configuré l’envoi périodique de messages
aux administrateurs MySQL. Dans ce cas, les administrateurs recevront quatre
messages avant que le problème ne soit escaladé au responsable de la base de données.
Notez que le responsable ne recevra un message que si le problème n’a pas encore
été acquitté, ce qui signifie vraisemblablement que personne ne s’en occupe.
{width="600"}
Détails de l’opération 2 :
{width="600"}
Notez l’utilisation de la macro {ESC.HISTORY} dans le message personnalisé. La macro
contiendra des informations sur toutes les étapes précédemment exécutées de cette
escalade, telles que les notifications envoyées et les commandes exécutées.
[comment]: # ({/d6340061-2f4800fa})
[comment]: # ({aba91a40-aba91a40})
##### Exemple 4
Un scénario plus complexe. Après plusieurs messages aux administrateurs MySQL et une escalade vers le responsable, Zabbix essaiera de redémarrer la base de données MySQL. Cela se produira si le problème existe depuis 2h30 et qu'il n'a pas été acquitté.
Si le problème persiste, après 30 minutes supplémentaires, Zabbix enverra un message à tous les utilisateurs invités.
Si cela ne résout pas le problème, après une heure supplémentaire, Zabbix redémarrera le serveur avec la base de données MySQL (deuxième commande à distance) à l'aide des commandes IPMI.
{width="600"}
[comment]: # ({/aba91a40-aba91a40})
[comment]: # ({939c3ed9-919f413f})
##### Exemple 5
Une escalade avec plusieurs opérations ayant des plages d’étapes qui se chevauchent et des intervalles personnalisés. La durée d’étape par défaut de l’opération est de 30 minutes.
{width="600"}
Les notifications seront envoyées comme suit :
- Aux administrateurs MySQL à 0:00, 0:30, 1:00 et 1:30 après le début du problème.
- Au responsable de la base de données à 2:00 et 2:10 (la durée d’étape personnalisée plus courte de 10 minutes définie dans l’opération suivante remplace la durée d’étape plus longue d’1 heure configurée ici, comme indiqué dans [Détails de l’opération](/manual/config/notifications/action/operation#operation-details) pour *Durée d’étape* lorsque les étapes se chevauchent).
- Aux administrateurs Zabbix à 2:00, 2:10 et 2:20 après le début du problème (la durée d’étape personnalisée de 10 minutes est appliquée).
- Aux utilisateurs invités à 4:00 après le début du problème (la durée d’étape par défaut de 30 minutes s’applique entre les étapes 8 et 11).
[comment]: # ({/939c3ed9-919f413f})