Azure Monitor : diagnostiquer une perte de logs avant de modifier les alertes

Une alerte qui ne se déclenche plus n’est pas toujours une règle mal écrite. En production Azure, le problème vient souvent plus bas : un Diagnostic Setting supprimé, une Data Collection Rule modifiée, une table qui n’ingère plus, un workspace déplacé, un filtre trop agressif, une rétention changée ou un coût d’ingestion que quelqu’un a voulu réduire trop vite. Le symptôme est dangereux parce qu’il ressemble à du calme : les dashboards deviennent propres, les alertes cessent de bruiter, mais l’exploitation perd une partie de sa preuve.

Le cas d’usage est une application Azure exploitée avec Application Insights, Log Analytics, Diagnostic Settings sur les ressources managées, quelques DCR pour les VM ou agents, et des alertes KQL utilisées pendant les incidents. Après un déploiement ou une opération de rationalisation des logs, une équipe remarque que certaines erreurs ne remontent plus. L’objectif du runbook est de diagnostiquer la chaîne d’observabilité avant de modifier les seuils, de recréer des alertes ou de supposer que le service va mieux.

Décrire le signal attendu

Avant de chercher dans KQL, écrivez le signal qui devrait exister. Une perte de logs se diagnostique comme un chemin de production : producteur, configuration de collecte, destination, table, transformation, alerte et usage opérationnel.

Signal attendu
Ressource source: app-orders-prod / Application Gateway / Key Vault / VM worker
Evenement attendu: erreur applicative, blocage WAF, refus Key Vault, exception runtime
Destination: workspace log-prod-euw
Table attendue: AppRequests, AzureDiagnostics, AppExceptions, KeyVaultAuditEvents
Fenetre de comparaison: 24h avant changement / 2h apres changement
Consommateurs: alerte SLO, dashboard incident, runbook rollback, post-incident

Questions avant correction
Le service produit-il encore l'evenement ?
La collecte est-elle encore active ?
La destination a-t-elle change ?
La table attendue recoit-elle des donnees ?
Une transformation filtre-t-elle le signal ?
L'alerte lit-elle la bonne table et la bonne fenetre ?

Ce contrat évite de commencer par la règle d’alerte. Si la table ne reçoit plus rien, changer un seuil ne répare pas l’observabilité ; cela masque seulement la panne de collecte.

Comparer avant et après le changement

La première requête doit vérifier la présence du signal, pas sa qualité métier. Il faut comparer le même périmètre, la même table et la même granularité avant et après la fenêtre suspecte.

let changeStart = datetime(2026-06-27T07:30:00Z);
let beforeWindow = 24h;
let afterWindow = 4h;
let serviceName = "orders-api";
AppRequests
| where TimeGenerated between ((changeStart - beforeWindow) .. (changeStart + afterWindow))
| where AppRoleName == serviceName
| summarize
  rows = count(),
  failed = countif(Success == false),
  operations = dcount(OperationName)
by phase = iff(TimeGenerated < changeStart, "before", "after"), bin(TimeGenerated, 30m)
| order by TimeGenerated asc

Si le volume tombe brutalement à zéro, le diagnostic descend vers l’ingestion. Si le volume reste stable mais que les erreurs disparaissent, il faut vérifier le service, la définition de succès, les transformations et les dimensions filtrées.

Vérifier les Diagnostic Settings

Pour beaucoup de ressources Azure, les logs arrivent via Diagnostic Settings. Un changement d’infrastructure peut supprimer une catégorie, changer le workspace, désactiver les métriques ou envoyer les logs vers un compte Storage au lieu de Log Analytics.

RESOURCE_ID="/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-prod/providers/Microsoft.Network/applicationGateways/agw-prod"

az monitor diagnostic-settings list --resource "$RESOURCE_ID" --query "[].{name:name,workspace:workspaceId,logs:logs[].{category:category,enabled:enabled},metrics:metrics[].{category:category,enabled:enabled}}" --output json

az monitor diagnostic-settings categories list --resource "$RESOURCE_ID" --query "value[].{name:name,type:categoryType}" --output table

Capturez cet état dans le ticket. Un rollback propre doit pouvoir restaurer le nom du Diagnostic Setting, les catégories activées, la destination et les métriques collectées.

Contrôler DCR, agents et transformations

Les Data Collection Rules ajoutent une couche utile mais parfois moins visible : association à la ressource, data sources, destinations, transformations KQL et streams. Une transformation peut être correcte syntaxiquement et supprimer le signal utile.

az monitor data-collection rule association list-by-resource --resource "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-prod/providers/Microsoft.Compute/virtualMachines/vm-worker-01" --query "[].{name:name,rule:dataCollectionRuleId,description:description}" --output table

az monitor data-collection rule show --resource-group rg-observability-prod --name dcr-linux-workers-prod --query "{destinations:destinations,streams:streamDeclarations,dataFlows:dataFlows}" --output json

Regardez en priorité les associations manquantes, les destinations qui ne pointent plus vers le workspace attendu et les transformations qui filtrent Severity, Facility, Category, ResultType ou des champs applicatifs.

Lire l’état d’ingestion comme une preuve

Une alerte peut être silencieuse parce que le service est sain, parce que la collecte est cassée, ou parce que l’ingestion est en retard. Il faut donc lire les tables de santé d’ingestion et comparer plusieurs sources.

let window = 6h;
union withsource = TableName
AppRequests,
AppExceptions,
AppDependencies,
AzureDiagnostics
| where TimeGenerated > ago(window)
| summarize
  rows = count(),
  firstSeen = min(TimeGenerated),
  lastSeen = max(TimeGenerated)
by TableName, bin(TimeGenerated, 30m)
| order by TableName asc, TimeGenerated asc

Ajoutez aussi les logs de plateforme disponibles dans votre environnement : activité Azure, changements de configuration, événements d’agent, métriques de workspace ou requêtes d’administration. L’idée est de prouver si le silence vient d’une absence d’événement ou d’une absence de collecte.

Rechercher les changements de configuration

La disparition de logs suit souvent une opération légitime : nettoyage Terraform, modification de policy, migration de workspace, réduction de coût, changement de DCR ou refonte d’alertes. Les journaux d’activité donnent le point d’entrée.

let changeWindow = 48h;
AzureActivity
| where TimeGenerated > ago(changeWindow)
| where OperationNameValue has_any (
  "MICROSOFT.INSIGHTS/DIAGNOSTICSETTINGS/WRITE",
  "MICROSOFT.INSIGHTS/DIAGNOSTICSETTINGS/DELETE",
  "MICROSOFT.INSIGHTS/DATACOLLECTIONRULES/WRITE",
  "MICROSOFT.INSIGHTS/SCHEDULEDQUERYRULES/WRITE",
  "MICROSOFT.OPERATIONALINSIGHTS/WORKSPACES/WRITE")
| project TimeGenerated,
        OperationNameValue,
        ActivityStatusValue,
        Caller,
        ResourceGroup,
        ResourceProviderValue,
        ResourceId,
        CorrelationId
| order by TimeGenerated desc

Si une opération correspond à la chute du volume, ne corrigez pas encore. Vérifiez d’abord si elle était volontaire, si elle touche toutes les ressources attendues, et si un rollback de configuration existe.

Séparer économie de logs et perte de preuve

Réduire l’ingestion peut être nécessaire. Mais l’économie doit être portée par une décision explicite, pas par une perte accidentelle de visibilité. Classez les signaux avant de couper.

A conserver sans discussion pendant incident
Erreurs utilisateur
Authentification et refus d'acces
WAF, gateway et API gateway
Deploiements, revisions et changements de configuration
Actions d'automatisation et identites d'execution

A reduire avec validation
Traces debug verbeuses
Evenements repetitifs sans correlation
Metriques deja couvertes ailleurs
Logs de dependances non critiques hors fenetre incident

A ne jamais supprimer sans alternative
Signal utilise par une alerte SLO
Signal utilise par un rollback
Signal necessaire a une preuve de securite
Signal qui relie utilisateur, operation et version

Cette classification permet de corriger sans revenir à une ingestion illimitée. Le but est de restaurer la preuve utile, pas de tout loguer par réflexe.

Décider : restaurer, corriger ou adapter l’alerte

La décision doit venir après la preuve de collecte. Une alerte silencieuse peut demander une restauration de Diagnostic Setting, un correctif DCR, un rollback Terraform ou une adaptation de requête. Ces actions n’ont pas le même risque.

Restaurer la configuration precedente
Diagnostic Setting supprime ou destination changee
DCR dissociee d'une ressource critique
Table vide alors que le service produit encore des evenements
Rollback connu et faible risque

Corriger en avant
Transformation trop large mais intention correcte
Categorie manquante sur un perimetre limite
Workspace cible correct mais flux incomplet
Test d'ingestion disponible immediatement

Adapter l'alerte
Les logs sont presents
Le schema ou la table a change volontairement
L'ancien signal a un remplacant documente
La requete est rejouee sur avant/apres avec resultat attendu

Ne pas agir tout de suite
Chute expliquee par absence reelle d'evenement
Fenetre trop courte pour conclure
Retard d'ingestion temporaire confirme
Aucun consommateur operationnel impacte

Ne modifiez pas l’alerte tant que la chaîne de collecte n’est pas prouvée. Sinon, vous risquez d’adapter l’alarme à un capteur cassé.

Valider après correction

La validation doit rejouer le signal de bout en bout : événement produit, ingestion visible, requête d’alerte active et preuve attachée au changement.

Validation minimale
Diagnostic Settings ou DCR correspondent a l'etat attendu
La table recoit de nouvelles lignes apres correction
La requete KQL retrouve le signal de test
L'alerte cible le bon workspace et la bonne table
Le dashboard incident redevient coherent
Les couts ou volumes attendus sont acceptes
Le rollback de la correction est documente

Preuve a conserver
Etat avant correction
Changement applique
Horodatage de retour des logs
Requete KQL de validation
Decision: restaurer, corriger en avant ou adapter l'alerte

Si le signal revient mais que la règle d’alerte reste silencieuse, le diagnostic se déplace vers la requête, la fenêtre d’évaluation, les dimensions, l’action group ou la fréquence. La collecte, elle, est de nouveau exploitable.

Conclusion

Une perte de logs Azure Monitor doit être traitée comme un incident d’observabilité, pas comme un simple réglage d’alerte. La bonne séquence consiste à décrire le signal attendu, comparer avant/après, vérifier Diagnostic Settings, DCR, destinations, transformations et ingestion, puis seulement décider quoi changer.

La décision saine est simple : restaurer si la collecte critique a disparu, corriger en avant si le défaut est borné, adapter l’alerte si le signal a changé volontairement, et ne rien modifier si le silence est réellement expliqué. C’est ce qui évite de rendre les incidents plus propres dans les dashboards mais plus opaques pour l’exploitation.