Azure Monitor : diagnostiquer une tempête d'alertes après déploiement

Une tempête d’alertes après déploiement met l’équipe dans une mauvaise position : les canaux de garde se remplissent, les dashboards changent d’état, et la tentation immédiate est de désactiver l’action group ou de relever les seuils. C’est parfois nécessaire pour reprendre la main, mais ce n’est pas encore un diagnostic.

Le cas d’usage est un service Azure qui vient d’être déployé ou reconfiguré : App Service, Functions, APIM, Application Gateway, job d’automatisation, composant réseau ou workload interne. Quelques minutes plus tard, Azure Monitor déclenche en masse. L’objectif du runbook est de distinguer incident réel, bruit de monitoring, effet de warm-up, seuil mal calibré, dimension trop large ou changement applicatif à rollback.

Lire la tempête comme une chaîne de signal

Une alerte n’est pas un fait brut. C’est le résultat d’une chaîne : métrique ou log, requête, dimension, fenêtre d’agrégation, seuil, règle, action group, notification, runbook. Quand plusieurs alertes partent en même temps, il faut remonter cette chaîne avant de décider.

Signal source
Metrique Azure Monitor, log Application Insights, diagnostic resource ou table custom
Horodatage, ressource, region, environnement, dimension

Regle
Query ou metric alert
Fenetre d'evaluation
Frequence
Seuil statique ou dynamique
Dimension ou split by

Notification
Action group appele
Canal touche: mail, Teams, webhook, ITSM, automation
Nombre d'evenements et deduplication

Contexte de changement
Deploiement applicatif
Changement infra ou reseau
Modification de regle d'alerte
Changement de trafic ou de dependance

Decision
Incident reel
Bruit temporaire
Mauvaise regle
Rollback applicatif ou infra
Suspension controlee de notification

Cette lecture évite de traiter toutes les alertes comme un seul bruit. Une règle peut être bruyante parce qu’elle signale correctement une régression, ou parce qu’elle observe un comportement normal de démarrage sans contexte.

Stabiliser sans perdre les preuves

Si le canal d’astreinte devient inutilisable, il faut réduire le bruit de façon contrôlée. Le piège est de couper la seule preuve qui permettra de comprendre l’incident.

Objectif immediat
Garder un canal lisible
Preserver les traces
Ne pas masquer l'impact utilisateur

Actions acceptables
Regrouper les notifications si le canal le permet
Mettre une regle en snooze court avec ticket et heure de fin
Basculer une notification non critique vers un canal secondaire
Garder les logs et metriques actifs
Conserver au moins une alerte de symptome utilisateur

Actions dangereuses
Desactiver tout l'action group sans horodatage de retour
Modifier les seuils sans conserver l'ancienne valeur
Supprimer la regle avant export ou capture
Considerer que le bruit prouve l'absence d'incident

La stabilisation doit être visible dans le ticket d’incident : règle touchée, durée, raison, personne responsable, condition de retour.

Séparer les alertes par symptôme

La première analyse consiste à grouper les alertes par symptôme plutôt que par canal. Une vague peut mélanger latence, erreurs 5xx, exceptions, saturation de dépendance et échec de job. Ce regroupement montre si le problème est central ou périphérique.

let Window = 2h;
let DeploymentTime = datetime(2026-06-18T07:30:00Z);
AlertsManagementResources
| where todatetime(properties.essentials.startDateTime) > ago(Window)
| extend firedAt = todatetime(properties.essentials.startDateTime)
| extend alertName = tostring(properties.essentials.alertRule)
| extend severity = tostring(properties.essentials.severity)
| extend monitorCondition = tostring(properties.essentials.monitorCondition)
| extend target = tostring(properties.essentials.targetResource)
| extend targetType = tostring(properties.essentials.targetResourceType)
| extend minutesAfterDeployment = datetime_diff('minute', firedAt, DeploymentTime)
| summarize alerts=count(),
          firstSeen=min(firedAt),
          lastSeen=max(firedAt),
          targets=dcount(target),
          sampleTargets=make_set(target, 5)
by alertName, severity, monitorCondition, targetType
| order by alerts desc

La table exacte dépend de la configuration Azure Monitor et Log Analytics. Si vos alertes sont exportées autrement, gardez le même principe : nom de règle, cible, sévérité, première occurrence, dernière occurrence, nombre de ressources touchées.

Comparer avec le déploiement

Une alerte après déploiement n’est pas toujours causée par le déploiement. Elle peut révéler une dépendance lente, une baseline trop basse ou une règle qui n’avait jamais été exposée à ce trafic. La comparaison doit donc croiser temps, composant et changement.

Questions de correlation
Les premieres alertes commencent-elles apres le deploiement ?
Le composant alerte correspond-il au composant deploye ?
Une dependance proche alerte-t-elle avant le workload ?
Le trafic a-t-il change en meme temps ?
Le seuil avait-il deja ete atteint sans notification ?
Une regle d'alerte ou un action group a-t-il ete modifie ?
La metrique mesure-t-elle un symptome utilisateur ou un signal interne ?

Un rollback applicatif est défendable quand le signal touche le composant livré, démarre dans la fenêtre de changement et se confirme par logs ou métriques utilisateur. Il est plus fragile si seules des règles internes bruyantes changent d’état sans impact visible.

Vérifier si la règle observe la bonne dimension

Les tempêtes viennent souvent de règles trop larges : split par instance, région, status code, opération, backend ou file. Une règle correcte sur une dimension peut devenir ingérable si elle notifie séparément chaque valeur.

Pour chaque regle bruyante
Ressource ciblee: service, groupe, abonnement ou workspace
Dimension: instance, operation, status code, hostname, backend, queue
Split by active ou non
Nombre de series declenchees
Valeur de seuil
Fenetre d'agregation
Frequence d'evaluation
Auto-mitigation ou resolution automatique
Action group appele

La correction n’est pas forcément de relever le seuil. Elle peut consister à changer la dimension, réduire le périmètre, regrouper les notifications ou créer deux règles : une règle de symptôme utilisateur et une règle de diagnostic moins urgente.

Lire les logs du service avant les seuils

Avant de toucher une alerte, il faut vérifier si le service signale réellement une régression. L’exemple suivant part d’Application Insights, mais la logique vaut pour des logs APIM, Application Gateway, Functions, Container Apps ou un composant interne.

let Window = 2h;
let DeploymentTime = datetime(2026-06-18T07:30:00Z);
requests
| where timestamp > ago(Window)
| summarize total=count(),
          failed=countif(success == false),
          p95=percentile(duration, 95)
by bin(timestamp, 5m), cloud_RoleName
| extend failureRate = todouble(failed) / todouble(total)
| extend period = iff(timestamp < DeploymentTime, "before", "after")
| order by timestamp asc

Une hausse d’alertes sans hausse d’erreurs, de latence ou d’impact métier pointe vers la règle. Une hausse alignée sur les erreurs utilisateur pointe vers le service. Une hausse uniquement sur une dépendance pointe vers le chemin d’appel, pas forcément vers le code déployé.

Décider entre correction, silence temporaire et rollback

La décision doit rester explicite. Modifier une règle d’alerte n’est pas un rollback du service. Rollbacker le service n’est pas une correction du monitoring. Les deux peuvent être nécessaires, mais ils ne répondent pas à la même preuve.

Constat prouve
Impact utilisateur confirme apres deploiement
  Decision: rollback applicatif ou infra selon le changement
  Validation: erreurs, latence ou symptome utilisateur reviennent au niveau attendu

Regle trop sensible sans impact service
  Decision: ajuster seuil, fenetre ou dimension avec historique conserve
  Validation: la regle reste capable de detecter le symptome utile

Action group ou deduplication mal configure
  Decision: corriger routage de notification ou groupement
  Validation: un test declenche une notification unique et lisible

Warm-up ou migration attendue
  Decision: silence temporaire borne ou seuil transitoire documente
  Validation: retour automatique et revue post-deploiement

Cause inconnue mais canal sature
  Decision: stabiliser notifications sans couper collecte
  Validation: preuves disponibles et alerte de symptome utilisateur conservee

La bonne décision est celle que l’équipe peut relire le lendemain sans deviner pourquoi elle a été prise.

Garder un rollback du monitoring

Une modification d’alerte doit être rollbackable comme un changement de production. Sinon la plateforme garde des seuils modifiés pendant des semaines et l’incident suivant arrive sans détection fiable.

Avant changement
Exporter ou capturer l'ancienne regle
Noter seuil, fenetre, dimensions, action group
Lier le changement au ticket incident
Fixer une heure de revue

Apres changement
Tester une notification controlee si possible
Verifier que les logs continuent d'arriver
Confirmer que la regle detecte encore le symptome cible
Revenir a l'ancien seuil si la modification etait seulement transitoire
Ajouter le scenario au runbook de deploiement

Ce rollback du monitoring est aussi important que le rollback applicatif. Sans lui, le système peut sembler calme parce qu’il n’écoute plus correctement.

Conclusion

Une tempête d’alertes après déploiement doit être traitée comme un incident d’observabilité et de production. Il faut stabiliser les notifications, préserver les preuves, grouper les symptômes, comparer avec le changement, vérifier les dimensions et lire les logs du service avant de toucher les seuils.

La décision finale doit être nette : rollback du service si l’impact est prouvé, correction de règle si le signal est mal configuré, silence temporaire s’il est borné et tracé, ou amélioration d’action group si le problème est la notification. L’objectif n’est pas d’obtenir le silence, mais de retrouver une alerte qui aide réellement à exploiter le système.