Infrastructure
Azure Monitor : diagnostiquer un Action Group avant de couper les alertes
Un runbook de production pour qualifier un Action Group Azure Monitor en séparant règles, canaux, webhooks, escalades, preuves KQL, validation et rollback avant de réduire les notifications.
Quand une équipe reçoit trop d’alertes, le réflexe le plus rapide est souvent de désactiver l’Action Group, de retirer un destinataire ou de couper le webhook qui réveille l’astreinte. C’est compréhensible pendant un incident, mais c’est aussi une manière très efficace de perdre le seul signal encore exploitable.
Le cas d’usage est une plateforme Azure où plusieurs règles Azure Monitor partagent un Action Group : mail, Teams, webhook ITSM, Logic App, automation ou connecteur d’incident. Une vague d’alertes arrive, certaines notifications ne partent plus, d’autres doublonnent, et l’équipe ne sait plus si le problème est la règle, le canal, le routage d’escalade ou le service surveillé. L’objectif du runbook est de décider quoi modifier, quoi conserver et comment revenir en arrière sans rendre l’incident invisible.
Geler le contrat de notification
Avant de toucher à l’Action Group, écrivez ce qu’il est censé faire. Un Action Group n’est pas seulement une liste d’e-mails. C’est un contrat d’exploitation : quelles règles l’appellent, quels canaux sont critiques, qui reçoit quoi, quels webhooks créent des tickets et quelles notifications peuvent être temporairement ralenties.
action_group:
name: ag-prod-critical
scope: production platform alerts
owner: platform-operations
critical_channels:
- type: webhook
target: incident-management
purpose: create_or_update_incident
- type: sms_or_voice
target: on-call-primary
purpose: wake_up_for_sev1
secondary_channels:
- type: email
target: platform-watch
purpose: context_and_followup
- type: teams
target: operations-channel
purpose: shared_visibility
change_rules:
require_ticket: true
maximum_silence: 30m
preserve_one_user_impact_signal: true
rollback_owner: incident-commanderSi ce contrat n’existe pas, commencez par le reconstruire depuis la configuration réelle. La modification sera sinon jugée à l’impression du moment : “trop de bruit”, “pas assez d’alertes”, “le webhook a l’air cassé”.
Cartographier les règles qui appellent le groupe
Un Action Group bruyant n’est pas toujours le problème. Il peut simplement relayer correctement une règle trop large, une dimension mal choisie ou un seuil devenu obsolète après un changement de trafic. Listez les règles qui l’utilisent avant de modifier le groupe lui-même.
ACTION_GROUP_ID="/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-monitoring/providers/microsoft.insights/actionGroups/ag-prod-critical"
az monitor metrics alert list --query "[?contains(to_string(actions), '$ACTION_GROUP_ID')].{name:name,resourceGroup:resourceGroup,enabled:enabled,severity:severity,scopes:scopes}" --output table
az monitor scheduled-query list --query "[?contains(to_string(actions), '$ACTION_GROUP_ID')].{name:name,resourceGroup:resourceGroup,enabled:enabled,severity:severity,scopes:scopes}" --output tableLa sortie doit permettre de répondre à trois questions : quelles règles sont réellement connectées, lesquelles sont critiques pour l’impact utilisateur, et lesquelles peuvent être ajustées sans masquer un incident de production.
Séparer panne de canal et bruit de règle
Ne confondez pas un canal cassé avec une règle bruyante. Si le webhook ITSM ne crée plus de ticket, couper la règle ne résout rien. Si la règle génère mille événements valides mais inutilisables, changer le webhook ne réduit pas le bruit.
Symptome: beaucoup de notifications, tickets coherents
Hypothese principale: regle trop large, dimension bruyante ou seuil obsolete
Action candidate: ajuster la regle, pas l'Action Group entier
Symptome: alertes visibles dans Azure Monitor, aucune notification externe
Hypothese principale: canal, webhook, receiver desactive ou erreur d'integration
Action candidate: tester le receiver et garder la regle active
Symptome: notifications en double sur plusieurs canaux
Hypothese principale: plusieurs regles ou plusieurs receivers pour le meme symptome
Action candidate: dedoublonner l'escalade, pas supprimer le signal
Symptome: notification tardive apres resolution
Hypothese principale: fenetre d'evaluation, frequence, latence webhook ou backlog ITSM
Action candidate: qualifier la latence avant de changer la severiteCette matrice évite une erreur classique : désactiver le groupe complet alors qu’une seule règle ou un seul receiver pose problème.
Lire les preuves d’alerte avant silence
Azure Monitor doit montrer quelles règles tirent, quand, sur quelles ressources et avec quelle sévérité. Gardez une preuve avant tout silence, même temporaire.
let StartTime = datetime(2026-07-17T08:00:00Z);
let EndTime = datetime(2026-07-17T09:00:00Z);
AlertsManagementResources
| where todatetime(properties.essentials.startDateTime) between (StartTime .. EndTime)
| extend alertRule = 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)
| summarize fired=count(),
firstSeen=min(todatetime(properties.essentials.startDateTime)),
lastSeen=max(todatetime(properties.essentials.startDateTime)),
targets=dcount(target),
sampleTargets=make_set(target, 5)
by alertRule, severity, monitorCondition, targetType
| order by fired descLa requête ne prouve pas que l’Action Group a notifié, mais elle prouve la pression exercée par les règles. C’est la base pour décider si la réduction doit porter sur la règle, le receiver, le canal d’escalade ou le service surveillé.
Tester chaque receiver comme une dépendance de production
Un receiver webhook ou Logic App est une dépendance. Il peut avoir son propre secret, son IP attendue, son throttling, son format de payload et ses erreurs. Traitez-le comme une intégration de production, pas comme un simple champ de configuration.
Verifier par receiver
Receiver active dans l'Action Group
Nom et destination attendus
Dernier changement de configuration
Secret, token ou endpoint encore valide
Reponse du webhook ou connecteur d'incident
Correlation entre alerte Azure et ticket externe
Comportement en cas de duplicate ou resolved alert
Bloquer la desactivation globale quand
Un seul receiver echoue
Les alertes critiques continuent d'etre justes
L'integration externe throttle mais finit par accepter
Aucun test de retour n'a ete preparePour un webhook, rejouez avec une alerte de test ou une règle non critique. Pour un canal humain, vérifiez la réception réelle avec une personne d’astreinte, pas seulement l’état “enabled” dans Azure.
Réduire le bruit sans rendre l’incident muet
La bonne réduction est bornée, documentée et réversible. Elle garde au moins un signal d’impact utilisateur et évite de modifier plusieurs couches à la fois.
silence_plan:
incident: INC-20260717-014
action_group: ag-prod-critical
reason: notification storm from one non-user-impact rule
start: 2026-07-17T08:40:00Z
end: 2026-07-17T09:10:00Z
changes:
- target: rule
name: queue-depth-warning
action: disable_notification_only_or_snooze
keep_metrics: true
- target: action_group
name: ag-prod-critical
action: keep_critical_webhook_and_oncall_enabled
preserved_signals:
- api_5xx_rate_sev2
- customer_login_failure_sev1
rollback:
owner: incident-commander
condition: end_time_reached_or_user_impact_confirmed
expected_state: all_critical_receivers_enabledSi l’outil ne permet pas de suspendre proprement un receiver ou une règle, conservez l’état précédent dans le ticket et prévoyez la commande de retour avant d’appliquer la modification.
Valider le retour du signal
La fin d’un silence est un test de production. Ne vous contentez pas de réactiver la configuration. Vérifiez que le signal repart au bon endroit, avec le bon niveau et sans doublon.
Validation apres retour
La regle critique declenche toujours dans Azure Monitor
L'Action Group appelle le receiver attendu
Le webhook cree ou met a jour le bon incident
Le canal humain recoit une seule notification exploitable
Les notifications resolues ne rouvrent pas un incident clos
Le ticket contient preuve avant, changement, preuve apres et rollbackCette validation doit être exécutée avec un signal contrôlé ou une alerte non destructive. L’objectif n’est pas de provoquer une panne, mais de prouver que la chaîne notificationnelle est revenue dans un état opérable.
Décider : corriger la règle, réparer le receiver ou rollbacker
La décision finale doit pointer la couche responsable.
Corriger la regle
Trop d'alertes viennent d'une requete, dimension ou severite mal calibree
Les receivers fonctionnent correctement
Un signal d'impact utilisateur reste disponible
Reparer le receiver
Azure Monitor declenche correctement
Un canal externe ne recoit pas ou transforme mal l'alerte
Les autres receivers restent utiles
Rollbacker la modification Action Group
La reduction masque un symptome utilisateur
Le canal critique ne recoit plus de signal de test
La fenetre de silence arrive a expiration
L'equipe ne peut plus expliquer qui est notifie et pourquoiUn Action Group doit rester un outil d’exploitation, pas un interrupteur de panique. La bonne sortie du runbook est une chaîne d’alerte explicable : une règle ajustée si elle était bruyante, un receiver réparé s’il était cassé, ou un rollback rapide si la réduction a rendu la production moins observable.