Acheminement des alertes : regroupement, inhibition, mises en sourdine et politiques d'escalade

Objectif

Livrer chaque alerte à la seule personne ou au seul canal capable d'agir dessus, sous la forme d'une notification par incident plutôt qu'une par instance, avec un chemin défini lorsque personne ne répond.

Prérequis

Des alertes portant des étiquettes de gravité, d'équipe et de service ; un composant d'acheminement (la documentation d'Alertmanager décrit la déduplication, le regroupement, l'acheminement vers des destinataires, la mise en sourdine et l'inhibition) ; et un service d'astreinte avec des politiques d'escalade.

Étapes

1. Fixer d'abord le contrat d'étiquettes : severity (alerte téléphonique, ticket), team, service. L'acheminement se fait par correspondance sur les étiquettes, donc une alerte qui en est dépourvue atterrit dans le destinataire par défaut et n'appartient à personne.
2. Construire l'arbre d'acheminement : un destinataire racine pour le reliquat non apparié, des routes filles par équipe, et à l'intérieur un destinataire d'alerte téléphonique pour severity=page et un destinataire de ticket ou de discussion pour le reste. N'utiliser continue: true que là où une alerte doit délibérément atteindre deux destinataires.
3. Regrouper par alertname et service (ou cluster) afin qu'une panne touchant cinquante instances produise une seule notification qui les liste toutes les cinquante. Fixer group_wait proche de l'exemple documenté (30 s) : trop court, avertit la documentation, envoie une première notification incomplète et laisse passer des alertes qu'une alerte source arrivée en retard aurait inhibées ; trop long retarde la première notification. Fixer group_interval pour les mises à jour d'un groupe existant et repeat_interval (l'exemple documenté utilise 4 h) pour le renvoi d'un groupe non résolu.
4. Écrire des règles d'inhibition pour les paires cause-symptôme connues : quand l'alerte de cluster injoignable se déclenche, mettre en sourdine toute alerte concernant ce cluster ; l'alerte source doit porter la même valeur dans les étiquettes de correspondance.
5. Utiliser les mises en sourdine (silences), avec une expiration et un commentaire, pour les maintenances planifiées, et des intervalles de temps sur les routes pour les plages calmes récurrentes des alertes de niveau ticket ; ne jamais mettre en sourdine une alerte de niveau alerte téléphonique sans un ticket qui en explique la raison.
6. Définir la politique d'escalade dans le service d'astreinte : la première règle notifie la personne d'astreinte, un délai d'escalade lui laisse un nombre fixe de minutes pour accuser réception, résoudre ou réassigner, puis la règle suivante notifie la personne secondaire, en répétant éventuellement la politique. Accuser réception arrête l'escalade ; seule la résolution clôt l'incident.
7. Tester de bout en bout avec une alerte synthétique par route chaque trimestre et après chaque changement de l'arbre : bon destinataire, une seule notification, escalade atteignant la personne secondaire lorsque la primaire l'ignore.

Résultat attendu

Une alerte téléphonique nomme un service et liste ses instances affectées, parvient à la personne d'astreinte responsable dans le délai de group_wait, et atteint automatiquement une deuxième personne si la première n'accuse pas réception.

Limites et base de vérification

Les durées indiquées ici sont des valeurs et des exemples par défaut documentés, pas des valeurs ajustées ; chaque équipe fixe les siennes en partant du délai d'escalade. L'inhibition ne fonctionne que lorsque les étiquettes sont cohérentes entre les sources d'alertes. Un arbre d'acheminement est une configuration qui dérive : elle a besoin de la même relecture que du code.