Azure Monitor : diagnostiquer une suppression de notifications avant de modifier l'alerte

Une alerte de disponibilité est visible comme déclenchée dans Azure Monitor, mais l’astreinte ne reçoit ni appel, ni e-mail, ni webhook. Le réflexe consiste souvent à modifier la règle d’alerte ou à recréer l’action group. Pourtant, le signal a bien été évalué : une règle de traitement des alertes peut avoir retiré toutes les action groups au moment du déclenchement.

Le cas d’usage est une règle créée pour une maintenance planifiée, puis restée active sur un scope trop large ou un horaire mal interprété. Ce runbook sépare la production du signal, le traitement de l’alerte et la livraison de la notification. La sortie attendue est une décision bornée : conserver la suppression, en réduire le scope, désactiver la règle de traitement, corriger l’action group ou rollbacker le dernier changement d’observabilité.

Figer une alerte déclenchée sans notification

Commencez par un exemplaire précis. Conservez son identifiant, son heure UTC, la ressource cible, la règle qui l’a produit, la sévérité et les action groups attendues. Ne désactivez pas plusieurs composants à la fois : vous perdriez la capacité d’attribuer la reprise.

incident:
started_at_utc: 2026-08-29T14:10:00Z
fired_alert_id: <alert-instance-id>
alert_rule_id: <alert-rule-resource-id>
target_resource_id: <monitored-resource-id>
severity: Sev1
expected_action_group_ids:
  - <on-call-action-group-id>

observed:
alert_visible_in_azure_monitor: true
notification_received: false
action_group_test_status: <not-run>

last_changes:
- planned maintenance window
- alert processing rule deployment
- scope or filter update
- time-zone or recurrence update
- action group receiver update

stop_conditions:
- no alert instance can be identified
- the monitored signal did not breach
- suppression scope includes unrelated production resources
- no alternate paging path protects the service

Une règle de traitement ne remplace pas la règle d’alerte. La première modifie les actions appliquées à une alerte au moment où elle se déclenche ; la seconde évalue le signal et crée l’alerte. Une suppression retire toutes les action groups de l’alerte concernée, mais l’alerte reste visible dans le portail, l’API et Azure Resource Graph. C’est précisément le symptôme à reconnaître.

Prouver les trois étages séparément

Le diagnostic doit répondre à trois questions dans l’ordre :

• le signal a-t-il franchi la condition pendant la fenêtre attendue ;
• une instance d’alerte a-t-elle été créée avec le bon scope et la bonne sévérité ;
• quelles règles de traitement pouvaient modifier ses actions à cet instant.

Si aucune alerte n’a été créée, restez sur la requête, la métrique, la fréquence d’évaluation, la fenêtre, les dimensions ou l’état de la règle d’alerte. Si l’alerte existe, ne changez pas son seuil pour réparer une notification. Reconstituez plutôt la chaîne alerte, règle de traitement et action group.

SUBSCRIPTION_ID="<subscription-id>"

az account set --subscription "$SUBSCRIPTION_ID"

az monitor alert-processing-rule list \
--query "[].{name:name, resourceGroup:resourceGroup, enabled:properties.enabled, scopes:properties.scopes, actions:properties.actions, conditions:properties.conditions, schedule:properties.schedule}" \
--output json

az resource list \
--resource-type "Microsoft.AlertsManagement/actionRules" \
--query "[].{name:name, resourceGroup:resourceGroup, id:id, location:location}" \
--output table

Le nom historique du type de ressource reste Microsoft.AlertsManagement/actionRules. L’inventaire par type permet donc de retrouver des règles créées par IaC même lorsque les équipes les appellent désormais règles de traitement. La commande Azure CLI appartient à l’extension alertsmanagement : fixez sa version dans l’automatisation et conservez sa sortie brute avec l’incident.

Calculer le scope réellement applicable

Une règle peut cibler une ressource, plusieurs ressources, un resource group ou une souscription entière. Elle ne s’applique qu’aux alertes déclenchées sur des ressources comprises dans ce scope, dans la même souscription. Les filtres réduisent ensuite ce périmètre selon le nom ou l’identifiant de règle, la sévérité, le service de supervision, la ressource ou le contenu du contexte.

Construisez une matrice au lieu de lire uniquement le nom de la règle.

Fired alert
target resource ID: <exact-resource-id>
alert rule ID: <exact-alert-rule-id>
alert rule name: <display-name>
severity: Sev1
monitor service: <service>
fired at UTC: <timestamp>

Candidate processing rule
enabled: true-or-false
action: RemoveAllActionGroups-or-AddActionGroups
scope contains target: true-or-false
filters match alert: true-or-false
schedule active at fired time: true-or-false
deployment propagation complete: true-or-false

Applicable only when
enabled AND scope contains target AND every filter matches
AND schedule is active AND propagation is complete

Vérifiez les identifiants complets, pas seulement les display names. Une règle nommée maintenance-app1 peut contenir un resource group partagé. Un filtre vide n’est pas un filtre protecteur. Plusieurs valeurs d’une même condition peuvent élargir la correspondance ; plusieurs conditions doivent être relues comme un contrat, pas comme une phrase.

Rejouer l’horaire dans son fuseau

Les suppressions de maintenance échouent souvent aux frontières : heure locale enregistrée comme UTC, récurrence hebdomadaire qui traverse minuit, règle ponctuelle jamais retirée ou calendrier conservé après un changement d’heure. Comparez toujours l’heure de l’alerte en UTC avec la définition de la règle et son fuseau.

RULE_RG="rg-monitoring-prod"
RULE_NAME="suppress-maintenance-app1"

az monitor alert-processing-rule show \
--resource-group "$RULE_RG" \
--name "$RULE_NAME" \
--output json > alert-processing-rule.json

jq '{
id,
enabled: .properties.enabled,
scopes: .properties.scopes,
conditions: .properties.conditions,
schedule: .properties.schedule,
actions: .properties.actions,
description: .properties.description,
tags
}' alert-processing-rule.json

Une règle mise à jour peut demander jusqu’à trente minutes avant de traiter les nouvelles alertes. N’utilisez donc pas une alerte déclenchée pendant cette période comme preuve définitive. Notez l’heure du changement, attendez la propagation documentée, puis provoquez un nouveau signal de test borné.

Distinguer suppression et panne de l’action group

Une fois la règle de traitement qualifiée, testez l’action group séparément. Un test de receiver qui échoue oriente vers le canal, l’authentification du webhook, une adresse, un numéro, un rate limit ou une intégration en aval. Un test qui réussit ne prouve pas que l’action group était attachée à l’alerte déclenchée.

La séquence de preuve est la suivante :

1. l’alerte de production existe ;
2. une règle de traitement RemoveAllActionGroups lui est applicable ;
3. l’action group fonctionne lors d’un test indépendant ;
4. une nouvelle alerte contrôlée notifie après retrait ciblé de la suppression.

Si plusieurs règles de traitement s’appliquent, la suppression a priorité sur l’ajout d’action groups. Ajouter une seconde règle ne contourne donc pas une suppression existante. Il faut corriger la règle qui retire les actions.

Contenir sans rouvrir toutes les notifications

Face à un scope trop large, évitez de supprimer immédiatement la règle si elle protège une maintenance encore en cours. Choisissez la mitigation la plus étroite :

• désactiver la règle si sa fenêtre est terminée et si son owner confirme le retrait ;
• remplacer un scope de souscription par les ressources réellement en maintenance ;
• ajouter un filtre stable lié à la règle d’alerte ou à la ressource ciblée ;
• corriger le fuseau ou la récurrence avec une fenêtre explicite ;
• maintenir un canal d’urgence hors du périmètre de suppression jusqu’à validation.

RULE_RG="rg-monitoring-prod"
RULE_NAME="suppress-maintenance-app1"

# Mitigation reversible lorsque la suppression ne doit plus agir.
az monitor alert-processing-rule update \
--resource-group "$RULE_RG" \
--name "$RULE_NAME" \
--enabled false

az monitor alert-processing-rule show \
--resource-group "$RULE_RG" \
--name "$RULE_NAME" \
--query "{enabled:properties.enabled, scopes:properties.scopes, actions:properties.actions, schedule:properties.schedule}" \
--output json

La commande d’update convient à une désactivation réversible. Pour modifier scopes, filtres ou horaire, passez par le code IaC qui possède la ressource et faites relire le diff. Une correction manuelle non réconciliée sera probablement écrasée au prochain déploiement.

Valider avec une alerte synthétique bornée

Ne concluez pas parce que la configuration paraît correcte. Utilisez une règle de test ou une condition contrôlée qui vise une ressource non critique, avec une action group de validation et une fenêtre courte. Le test doit produire une nouvelle instance d’alerte après propagation ; une ancienne alerte ne rejoue pas ses notifications à la fin de la suppression.

candidate_change:
processing_rule: suppress-maintenance-app1
expected_state: disabled-or-narrowed
owner: platform-observability
propagation_wait: up-to-30-minutes

synthetic_validation:
target: <non-critical-test-resource>
alert_rule: <synthetic-alert-rule-id>
expected_action_group: <validation-action-group-id>
correlation_id: <change-or-incident-id>

promote_when:
- a new alert instance is visible
- the expected receiver gets exactly one notification
- unrelated maintenance alerts remain suppressed
- the production paging path passes its independent test

rollback_when:
- notification fan-out reaches an unintended scope
- duplicate notifications appear
- the maintenance perimeter is no longer protected
- rule applicability cannot be reconstructed

rollback:
- restore the previous versioned processing rule
- keep the emergency paging path active
- preserve alert IDs, rule definitions and test timestamps

Surveillez ensuite un cycle représentatif : alertes déclenchées, notifications livrées, doublons, suppressions attendues et changements de règles. Le critère n’est pas « plus de silence », mais une correspondance explicable entre chaque classe d’alerte et son action attendue.

Décider correction, maintien ou rollback

Conservez la suppression si son scope, ses filtres et son horaire correspondent encore à une maintenance approuvée et qu’un canal protège les incidents hors maintenance. Réduisez-la si elle couvre des ressources ou des sévérités non prévues. Désactivez-la si la fenêtre est terminée, si l’owner est absent ou si la règle masque une alerte critique sans contrôle compensatoire.

Corrigez l’action group uniquement lorsque l’alerte n’est pas supprimée et que son test de receiver échoue. Rollbackez le dernier changement d’observabilité lorsque la version précédente avait un périmètre connu et que la nouvelle définition ne peut pas être qualifiée rapidement.

Conclusion

Une alerte déclenchée sans notification n’est pas automatiquement une règle d’alerte défectueuse. Azure Monitor peut avoir produit le signal correctement puis retiré toutes ses action groups par une règle de traitement applicable.

La décision fiable vient d’une preuve par étage : instance d’alerte, scope et filtres, horaire, priorité des actions, puis test indépendant de l’action group. Corrigez la plus petite frontière, attendez la propagation, validez avec une nouvelle alerte synthétique et gardez la définition précédente comme rollback explicite.