5 Escalade

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.

Concrètement, cela signifie que :

Les utilisateurs peuvent être informés des nouveaux problèmes immédiatement
Les notifications peuvent être répétées jusqu'à ce que le problème soit résolu
L'envoi d'une notification peut être retardé
Les notifications peuvent être transmises à un autre groupe d'utilisateurs "supérieur"
Les 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 dans le temps.

Vous pouvez définir à la fois la durée par défaut et la durée personnalisée de chaque étape. La durée minimale d'une étape d'escalade est de 60 secondes.

Vous pouvez lancer des actions, telles que l’envoi de notifications ou l’exécution de commandes, à partir de n’importe quelle étape. La première étape concerne les actions immédiates. Si vous souhaitez retarder 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. Les escalades sont prises en charge uniquement pour les opérations de problème, pas pour la récupération.

Divers aspects du comportement de l'escalade

Examinons ce qui se produit dans différentes circonstances si une action contient plusieurs étapes d'escalade.

Situation	Comportement
L'hôte en question passe en maintenance après l'envoi de la notification du problème initial	Selon le paramètre Suspendre les opérations des problèmes supprimés dans la configuration des actions, toutes les étapes d'escalade encore restantes sont exécutées avec un retard causé par la période de maintenance ou sans retard. Une période de maintenance n'annule pas les opérations.
La période définie dans la condition d'action Période* se termine après l'envoi de la notification initiale*	Toutes les étapes d'escalade restantes sont exécutées. La condition Période ne peut pas arrêter les opérations ; cela a un effet sur le moment où les actions sont démarrées/non démarrées, pas les opérations.
Un problème commence pendant la maintenance et continue (n'est pas résolu) après la fin de la maintenance	Selon le paramètre Suspendre les opérations des problèmes supprimés dans la configuration des actions, toutes les étapes d'escalade progressive sont exécutées à partir du moment où la maintenance prend fin ou immédiatement.
Un problème commence lors d'une maintenance sans collecte de données et continue (n'est pas résolu) après la fin de la maintenance	Il doit attendre que le déclencheur s'active avant que toutes les étapes d'escalade ne soient exécutées.
Différentes escalades se succèdent et se chevauchent	L'exécution de chaque nouvelle escalade remplace l'escalade précédente, mais pour au moins une étape d'escalade toujours exécutée lors de l'escalade précédente. Ce comportement est pertinent dans les actions sur les événements qui sont créés pour TOUTES les évaluations de problème du déclencheur.
Lors d'une escalade en cours (comme un message en cours d'envoi), en fonction de tout type d'événement : - l'action est désactivée - l'événement est supprimé Basé sur l'événement déclencheur : - le déclencheur est désactivé ou supprimé - l'hôte ou l'élément est désactivé Basé sur un événement interne concernant les déclencheurs : - le déclencheur est désactivé ou supprimé Basé sur un événement interne relatif aux éléments ou aux règles de découverte d'éléments : - l'élément est désactivé ou supprimé - l'hôte est désactivé	Le message en cours est envoyé et ensuite un autre message de l'escalade est envoyé. Le message de suivi comportera le texte d'annulation au début du corps du message (REMARQUE : Escalade annulée) en indiquant la raison (par exemple, REMARQUE : Escalade annulée : action '<nom de l'action>' désactivée). De cette manière, le destinataire est informé que l'escalade est annulée et aucune autre étape ne sera exécutée. Ce message est envoyé à tous les destinataires des notifications précédentes. La raison de l'annulation est également loggée dans le fichier journal du serveur (à partir du Niveau de debug 3=Avertissement). Notez que le message // Escalade annulée// est également envoyé si les opérations sont terminées, mais que les opérations de récupération sont configurées et ne sont pas encore exécutées (à partir de Zabbix 4.0.6).
Pendant une escalade en cours (comme l'envoi d'un message), l'action est supprimée	Aucun autre message n'est envoyé. Les informations sont consignées dans le fichier journal du serveur (à partir du Niveau de debug 3=Avertissement), par exemple : `Escalade annulée : action id:334 supprimée`

Exemples d'escalade

Exemple 1

Envoi d'une notification répétée une fois toutes les 30 minutes (5 fois au total) à un groupe 'Zabbix administrators'. Configurez :

Dans l'onglet Opérations, définissez Durée de l'étape d'opération par défaut sur '30m' (30 minutes).
Définissez les étapes d'escalade de '1' à '5'
Sélectionnez le groupe 'Zabbix administrators' en tant que destinataire du message.

Tous les champs de saisie obligatoires sont marqués d'un astérisque rouge.

Les notifications seront envoyées à 0:00, 0:30, 1:00, 1:30, 2:00 heures après le début du problème (sauf si le problème est résolu plus tôt).

Si le problème est résolu et qu'un message de récupération est configuré, il sera envoyé à ceux qui ont reçu au moins un message de problème dans ce scénario d'escalade.

Si le déclencheur qui a généré une escalade active est désactivé, Zabbix envoie un message informatif à ce sujet à tous ceux qui ont déjà reçu des notifications.

Exemple 2

Envoi d'une notification retardée concernant un problème de longue date. Configurez :

Dans l'onglet Opérations, définissez la Durée de l'étape d'opération par défaut sur '10h' (10 heures).
Définissez les étapes d'escalade de '2' à '2'

Une notification ne sera envoyée qu'à l'étape 2 du scénario d'escalade, ou 10 heures après le début du problème.

Vous pouvez personnaliser le texte du message en indiquant 'Le problème date de plus de 10 heures'.

Exemple 3

Escalader le problème au responsable.

Dans le premier exemple ci-dessus, nous avons configuré l'envoi périodique de messages aux administrateurs Zabbix. Dans ce cas, les administrateurs recevront quatre messages avant que le problème ne soit connu par la hiérarchie. Notez que le responsable recevra un message uniquement si le problème n'est pas encore reconnu, supposément personne ne travaille dessus.

Notez l'utilisation de la macro {ESC.HISTORY} dans le message. La macro contiendra des informations sur toutes les étapes précédemment exécutées sur cette escalade, telles que les notifications envoyées et les commandes exécutées.

Exemple 4

Un scénario plus complexe. Après plusieurs messages aux administrateurs Zabbix et escalade au responsable, Zabbix essaiera de redémarrer la base de données MySQL. Cela se produira si le problème existe depuis 2h30 et que le problème 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, Zabbix redémarrera le serveur avec la base de données MySQL (deuxième commande à distance) après une heure supplémentaire à l’aide des commandes IPMI.

Exemple 5

Une escalade avec plusieurs opérations affectées à une étape et des intervalles personnalisés utilisés. La durée de l'étape d'opération par défaut est de 30 minutes.

Les notifications seront envoyées de la manière suivante :

aux administrateurs Zabbix 0:00, 0:30, 1:00, 1:30 après le début du problème
au responsable 2:00 et 2:10 (et non 3:00; vu que les étapes 5 et 6 se chevauchent avec l'opération suivante, la durée de l'étape personnalisée la plus courte (10 minutes dans l'opération suivante) annule la durée de l'étape la plus longue, de 1 heure positionnée ici)
aux Spécialistes sécurité 2h00, 2h10, 2h20 après le début du problème (la durée de l'étape personnalisée de 10 minutes)
aux utilisateurs invités 4:00 heures après le début du problème (durée par défaut de 30 minutes entre les étapes 8 et 11)

Documentation