Infrastructure
Azure Monitor Action Groups : diagnostiquer une notification manquante avant de modifier les alertes
Un runbook de production pour qualifier une alerte Azure Monitor déclenchée sans notification, avec Action Groups, receivers, règles de traitement, webhooks, preuves, validation et rollback.
Une alerte Azure Monitor peut se déclencher correctement et échouer côté exploitation. La condition est vraie, l’instance d’alerte existe, la ressource est dégradée, mais personne ne reçoit l’email, le webhook, le SMS, l’appel vocal, le ticket ITSM ou le déclencheur d’automatisation qui devait lancer la réponse. Sous pression, le réflexe courant consiste à modifier la règle, abaisser le seuil ou ajouter un receiver. Cela peut créer des notifications en double sans expliquer pourquoi le chemin initial n’a pas fonctionné.
Le cas d’usage est une alerte de production qui doit prévenir une équipe d’astreinte via un Action Group. L’objectif du runbook est de décider si la règle d’alerte est saine, si l’Action Group a dérivé, si un receiver a échoué, si une règle de traitement a supprimé la notification, si une intégration a rejeté le payload, ou s’il faut rollbacker vers le dernier chemin de notification connu comme fonctionnel.
Figer le contrat de notification attendu
Commencez par le contrat, pas par la capture d’écran du portail. Un chemin de notification est une interface d’exploitation : condition, périmètre, Action Group, receiver, intégration, escalade et acquittement.
Incident
Regle d'alerte: prod-api-high-error-rate
Perimetre ressource: rg-prod-app / app-prod-api
Heure de declenchement: 2026-07-04T05:42:00Z
Action Group attendu: ag-platform-oncall-prod
Receivers attendus: email, webhook, ITSM ou automation
Owner attendu: platform-oncall
Delai d'escalade attendu: 5 minutes
Derniere notification connue comme fonctionnelle
Questions avant modification
La regle d'alerte s'est-elle vraiment declenchee ?
Quelle version d'Action Group etait attachee au moment du tir ?
Une regle de traitement des alertes etait-elle active ?
Quel receiver devait livrer en premier ?
L'endpoint d'integration est-il sain et authentifie ?
Un rollback existe-t-il vers un receiver fonctionnel ?Si l’équipe ne sait pas nommer le receiver attendu et le chemin d’escalade, modifier la règle ne fera qu’ajouter de l’incertitude.
Prouver que l’alerte s’est déclenchée une seule fois
Séparez le signal de détection du signal de livraison. Prouvez d’abord l’instance d’alerte, son état, sa sévérité, sa cible et la référence à l’Action Group.
SUBSCRIPTION="00000000-0000-0000-0000-000000000000"
ALERT_RULE="prod-api-high-error-rate"
RG="rg-monitoring-prod"
az account set --subscription "$SUBSCRIPTION"
az monitor metrics alert show --resource-group "$RG" --name "$ALERT_RULE" --query "{enabled:enabled,severity:severity,scopes:scopes,actions:actions,criteria:criteria}" --output json
az monitor activity-log alert list --resource-group "$RG" --query "[?name=='$ALERT_RULE'].{enabled:enabled,scopes:scopes,actions:actions}" --output jsonUtilisez la commande adaptée au type d’alerte. Les alertes métriques, scheduled query rules, activity log alerts et smart detection alerts n’exposent pas les mêmes champs. Le but reste le même : prouver que la règle déclenchée référençait l’Action Group attendu au moment de l’incident.
Contrôler les membres de l’Action Group et la dérive
Les Action Groups dérivent comme toute configuration de production. Un receiver peut être désactivé, renommé, déplacé vers un autre groupe, changé de common alert schema vers un payload spécifique, ou modifié sans test du chemin complet.
RG="rg-monitoring-prod"
ACTION_GROUP="ag-platform-oncall-prod"
az monitor action-group show --resource-group "$RG" --name "$ACTION_GROUP" --query "{enabled:enabled,groupShortName:groupShortName,emailReceivers:emailReceivers,webhookReceivers:webhookReceivers,azureFunctionReceivers:azureFunctionReceivers,logicAppReceivers:logicAppReceivers,armRoleReceivers:armRoleReceivers}" --output json
az monitor action-group list --resource-group "$RG" --query "[].{name:name,enabled:enabled,receivers:length(emailReceivers)+length(webhookReceivers)+length(azureFunctionReceivers)+length(logicAppReceivers)}" --output tableBloquez les modifications à l’aveugle si l’Action Group a changé près de la fenêtre d’incident. Restaurez ou testez le dernier receiver fonctionnel avant d’ajouter d’autres destinations.
Chercher les règles de traitement et la suppression
Une notification manquante ne vient pas toujours d’un Action Group cassé. Les alert processing rules peuvent supprimer ou rediriger les notifications pendant une maintenance, un déploiement, un incident ou une période bruyante. Ces règles sont utiles, mais elles doivent apparaître dans la décision.
Verifier suppression et routage
Regles de traitement actives pendant l'incident
Recouvrement de perimetre avec la ressource touchee
Filtres de severite
Filtres de service Monitor
Fuseau horaire et recurrence du schedule
Regles de remplacement d'Action Group
Fenetre de maintenance ou gel de deploiement
Bloquer les changements quand
Une regle de suppression matche sans owner
Le fuseau horaire du schedule est ambigu
La regle route vers un autre Action Group sans preuve
La maintenance est terminee mais la suppression reste active
La regle d'alerte est modifiee avant de comprendre la suppressionLa suppression n’est pas un échec quand elle est intentionnelle, bornée et documentée. Elle devient un incident quand personne ne peut expliquer pourquoi la notification a été coupée.
Corréler alerte, Action Group et receiver
La chaîne de preuve utile est : règle déclenchée, Action Group sélectionné, receiver appelé, intégration acceptée ou rejetée, workflow d’astreinte créé ou échoué. Ne vous arrêtez pas au premier statut vert.
let StartTime = datetime(2026-07-04T05:35:00Z);
let EndTime = datetime(2026-07-04T06:10:00Z);
AzureActivity
| where TimeGenerated between (StartTime .. EndTime)
| where OperationNameValue has_any ("alert", "actionGroups", "metricAlerts", "scheduledQueryRules")
| project TimeGenerated,
OperationNameValue,
ActivityStatusValue,
Caller,
ResourceGroup,
ResourceId,
CorrelationId,
Properties
| order by TimeGenerated ascSi le receiver est un webhook, une Logic App, une Function, un connecteur ITSM ou une API interne, corrélez les logs backend sur la même fenêtre. Un 200 côté Azure Monitor ne suffit pas si le système aval rejette le payload ou ne peut plus authentifier la requête.
Valider les modes d’échec par receiver
Chaque receiver échoue différemment. Traitez-le comme une dépendance de production, pas comme une simple adresse de notification.
Receiver email
Adresse encore portee par le groupe d'astreinte
Mailbox, liste de distribution et policy antispam saines
Etat de confirmation Azure Monitor valide si requis
Receiver webhook
Endpoint joignable depuis Azure Monitor
Secret ou header d'authentification encore valide
Common alert schema attendu par le receiver
Taille et debit de payload acceptes
Logs backend avec identifiant de correlation
Receiver Logic App ou Function
Trigger actif
Identite managée ou connexion encore valide
Connecteur ticketing ou chat aval sain
Run history avec succes ou echec explicite
ITSM ou outil d'incident
Token d'integration valide
Routing key toujours associee au bon service
Deduplication n'a pas fusionne avec un incident ferme
Politique d'escalade activeLe bon correctif peut être hors d’Azure Monitor. Si le secret du webhook a expiré, abaisser le seuil de l’alerte n’améliore ni la détection ni la réponse.
Lancer un test de notification contrôlé
Testez le chemin de notification avec un signal contrôlé, pas en affaiblissant l’alerte de production. Utilisez une règle temporaire ou un payload de test documenté, et rattachez le test au même Action Group et au même receiver.
test_plan:
purpose: prove_action_group_delivery
target_action_group: ag-platform-oncall-prod
receiver_under_test: webhook_primary_incident_tool
method:
- create_temporary_test_alert_or_use_safe_test_payload
- include correlation_id in payload or incident note
- keep severity and receiver path close to production
- verify downstream incident creation and acknowledgement
success:
- alert instance created
- action group invoked
- receiver backend accepted payload
- on-call workflow visible
- test artifact closed with evidence
cleanup:
- remove temporary test rule
- revert test routing if changed
- attach result to incident recordUn test qui envoie seulement un email à un ingénieur ne valide pas un chemin d’astreinte basé sur webhook. Le test doit suivre le chemin qui a échoué.
Décider correction, rollback ou changement de règle
La décision doit rester explicite. L’échec peut demander une correction d’Action Group, une réparation de receiver, un rollback de suppression, un rollback d’intégration ou, seulement après preuve, une modification de règle d’alerte.
Corriger l'Action Group
L'alerte s'est declenchee et referencait le bon groupe
Le receiver manque, est desactive ou a derive
Le dernier receiver fonctionnel peut etre restaure
Un test controle valide la livraison
Reparer le receiver ou l'integration
Azure Monitor a tente la livraison
Le backend a rejete authentification, schema ou routing key
Les logs d'integration prouvent le rejet
Le payload de test passe apres correction
Rollbacker suppression ou routage
Une alert processing rule a matche par erreur
Le schedule de maintenance ou le filtre est faux
L'owner confirme que la notification aurait du partir
Le rollback restaure l'Action Group attendu
Modifier la regle d'alerte seulement quand
La condition ne s'est pas declenchee pour le vrai symptome
Le scope ou la dimension est incorrect
La severite ou l'attachement Action Group est faux
Le chemin receiver a deja ete prouve sain
Bloquer les changements
Personne ne peut prouver quel receiver devait tirer
Les logs aval sont indisponibles
Plusieurs Action Groups ont ete modifies pendant l'incident
Un test notifierait la production sans approbationL’ordre compte. Réparer la livraison avant de modifier la détection garde le signal exploitable.
Garder un chemin de notification rollbackable
Les changements de notification ont besoin d’un rollback comme les changements de déploiement. Un bon rollback n’est pas un deuxième Action Group bruyant à vie. C’est un receiver connu comme fonctionnel, restaurable pendant que l’intégration principale est réparée.
Chemin de rollback
Restaurer la derniere version fonctionnelle de l'Action Group
Reactiver l'ancien receiver seulement pour la severite et le perimetre touches
Donner un owner et une date d'expiration au fallback temporaire
Valider une notification controlee
Documenter pourquoi le receiver principal a echoue
Supprimer le fallback quand le chemin principal repasse le test
Rollback incomplet quand
Le fallback devient permanent sans owner
Les doublons de notification sont consideres normaux
La suppression reste inexpliquee
L'outil d'incident recoit les alertes mais l'escalade ne part pas
La regle d'alerte a ete affaiblie pour compenser un probleme de livraisonUn fallback qui n’expire jamais devient une nouvelle source de dérive. Donnez-lui un owner et une condition de retrait.
Conclusion
Une notification Azure Monitor manquante ne se corrige pas en ajoutant du bruit. Elle se corrige en prouvant la chaîne : alerte déclenchée, Action Group sélectionné, suppression évaluée, receiver invoqué, intégration acceptée, workflow d’astreinte visible.
La décision sûre consiste à réparer le maillon défaillant ou à rollbacker vers un chemin de notification connu comme fonctionnel avant de modifier la règle d’alerte. Détection et livraison sont deux responsabilités différentes ; les garder séparées rend le prochain incident diagnostiquable.