Azure Workbooks: diagnostiquer une dérive d'observabilité avant de changer les alertes

Un Azure Workbook devient vite une surface de décision. Une équipe regarde un graphique, voit une chute de trafic, une hausse d’erreurs ou une latence qui disparaît, puis veut corriger une alerte, changer une requête KQL ou modifier un seuil. Le risque est de traiter le tableau de bord comme la source de vérité alors qu’il n’est qu’une vue composée: workspace Log Analytics, Application Insights, filtres, variables, dimensions, latence d’ingestion, permissions et requêtes.

Le cas d’usage est volontairement opérationnel. Une application vient d’être déployée. Le Workbook de production montre une baisse brutale du nombre de requêtes sur une API, mais les utilisateurs ne signalent pas encore d’incident. Avant de désactiver une alerte, d’augmenter un seuil ou de retoucher tous les panneaux du Workbook, l’équipe doit qualifier la dérive: problème réel, trou d’ingestion, filtre cassé, dimension renommée, changement de sampling ou erreur de requête.

L’objectif n’est pas de rendre le Workbook parfait. L’objectif est de produire assez de preuves pour décider: corriger la requête, réparer la collecte, ajuster l’alerte, revenir sur le dernier changement ou ne rien toucher.

Fixer le symptôme observable

Commencez par nommer le symptôme sans l’interpréter. Une courbe vide ne veut pas dire que le service ne reçoit plus de trafic. Une alerte silencieuse ne veut pas dire que l’incident est terminé. Un Workbook peut mentir par omission quand une variable, une plage de temps ou une source change.

incident:
surface: azure_workbook
workbook: prod-api-observability
panel: requests_by_region
first_seen_utc: 2026-07-22T08:15:00Z
reported_by: on_call

symptom:
observed: request_count_dropped_to_zero
expected: stable_business_hours_traffic
affected_view:
  - requests
  - failures
  - latency_p95
not_yet_proven:
  - user_impact
  - application_regression
  - ingestion_failure
  - kql_regression

decision_blocked_until:
- raw_signal_checked
- ingestion_latency_checked
- filters_and_parameters_checked
- alert_rule_compared
- rollback_path_known

Cette fiche évite une réaction trop rapide. L’équipe qualifie une dérive d’observabilité avant de toucher à la production ou aux alertes qui protègent la production.

Revenir au signal brut

Le premier contrôle consiste à sortir du Workbook. Lancez une requête minimale dans le workspace cible, sur la même fenêtre de temps, avec le minimum de filtres. Si le signal brut est présent, le problème est probablement dans le Workbook. Si le signal brut manque aussi, il faut basculer vers la collecte, l’agent, Application Insights, Diagnostic Settings ou la Data Collection Rule.

let Window = 2h;
requests
| where timestamp > ago(Window)
| summarize total=count(),
          failed=countif(success == false),
          p95_ms=percentile(duration, 95)
by bin(timestamp, 5m), cloud_RoleName
| order by timestamp asc

Ne commencez pas par réécrire la requête complète du Workbook. Comparez d’abord une requête brute, stable et lisible. Si elle montre du trafic, le chemin d’ingestion fonctionne au moins partiellement.

Vérifier le workspace, la ressource et les permissions

Un Workbook peut pointer vers plusieurs sources. Une variable d’abonnement, de resource group, de workspace ou d’application suffit à produire une vue vide. Les permissions peuvent aussi différer entre l’auteur du Workbook, le compte d’exploitation et l’identité utilisée par un affichage partagé.

Controle de source
Workspace Log Analytics attendu
Application Insights attendu
Abonnement et resource group corrects
Perimetre de temps identique entre panneaux
Variables du Workbook resolues explicitement

Controle d'acces
Lecteur capable d'interroger le workspace
Pas de panneau masque par permission partielle
Identite ou compte partage documente
Changement RBAC recent verifie

Indice de derive
Un panneau fonctionne et un autre est vide
La requete brute fonctionne hors Workbook
Le meme KQL echoue seulement avec les parametres du Workbook

Si plusieurs environnements partagent le même Workbook, forcez l’environnement dans les requêtes de diagnostic. Une dérive entre préproduction et production peut être seulement un mauvais paramètre par défaut.

Contrôler la latence d’ingestion avant les seuils

Une alerte qui semble fausse peut être une alerte correcte sur des données en retard. Avant de modifier un seuil, mesurez la latence entre l’heure de l’événement et l’heure d’ingestion. Le but est de savoir si le tableau de bord observe le présent ou un passé incomplet.

let Window = 3h;
requests
| where timestamp > ago(Window)
| extend ingestion_delay = ingestion_time() - timestamp
| summarize events=count(),
          p50_delay=percentile(ingestion_delay, 50),
          p95_delay=percentile(ingestion_delay, 95),
          max_delay=max(ingestion_delay)
by bin(timestamp, 10m), cloud_RoleName
| order by timestamp asc

Si la latence d’ingestion explose, la bonne action n’est pas de rendre le Workbook plus optimiste. Il faut qualifier la collecte et, si nécessaire, annoter l’incident d’observabilité.

Détecter les dimensions cassées

Beaucoup de Workbooks reposent sur des dimensions applicatives: région, tenant, route, version, feature, operation, backend. Un déploiement peut renommer une dimension ou changer son format. Les données existent encore, mais le panneau les filtre mal.

let Window = 24h;
requests
| where timestamp > ago(Window)
| extend region = tostring(customDimensions["region"])
| extend version = tostring(customDimensions["appVersion"])
| summarize total=count(),
          empty_region=countif(isempty(region)),
          versions=make_set(version, 20)
by bin(timestamp, 1h), cloud_RoleName
| extend empty_region_rate = todouble(empty_region) / todouble(total)
| order by timestamp asc

Une dimension vide après déploiement ne justifie pas forcément un rollback applicatif. Elle justifie une décision: restaurer la dimension, adapter la requête, ou accepter la nouvelle convention avec une mise à jour contrôlée du Workbook et des alertes dépendantes.

Comparer Workbook et règle d’alerte

Un piège classique consiste à corriger le panneau visible sans vérifier l’alerte. Si le Workbook et l’alerte ne portent pas exactement la même logique, l’équipe peut croire avoir réparé l’observabilité alors que le signal de réveil reste cassé.

Comparer explicitement
Table source
Fenetre temporelle
Granularite
Filtres d'environnement
Dimensions et exclusions
Definition de l'echec
Seuil et nombre d'evaluations
Traitement des donnees manquantes

Decision
Si Workbook faux mais alerte correcte: corriger le Workbook
Si alerte fausse mais Workbook correct: corriger l'alerte avec preuve
Si les deux sont faux: corriger la source ou le contrat de telemetrie
Si le signal manque: traiter l'ingestion avant les vues

Cette comparaison doit être jointe à la demande de changement. Une modification d’alerte sans preuve devient difficile à défendre au prochain incident.

Valider avec une sonde de bout en bout

Quand le doute persiste, injectez un signal contrôlable. Une sonde synthétique, une requête connue ou un parcours utilisateur de test permet de vérifier que l’événement arrive dans la bonne table, avec les bonnes dimensions, puis apparaît dans le Workbook et dans l’alerte.

probe:
name: prod-api-health-readonly
action: GET /health/dependencies
expected_status: 200
expected_dimensions:
  environment: production
  region: westeurope
  component: public-api

validation:
raw_table: requests
workbook_panel: requests_by_region
alert_rule: prod-api-failure-rate
max_ingestion_delay: 10m
evidence:
  - probe_timestamp
  - operation_id
  - raw_kql_result
  - workbook_screenshot_or_export
  - alert_rule_query_snapshot

La sonde doit rester non destructive. Elle sert à tester l’observabilité, pas à générer artificiellement un incident.

Décider sans casser la chaîne d’exploitation

À la fin du diagnostic, la décision doit être petite, réversible et reliée au signal qualifié. Évitez les corrections globales: supprimer un filtre partout, augmenter plusieurs seuils, désactiver une alerte bruyante ou changer une Data Collection Rule sans validation.

Corriger le Workbook
Signal brut present
Alerte correcte
Variable ou dimension du panneau defectueuse
Validation visuelle et KQL disponible

Corriger l'alerte
Requete d'alerte differente du signal valide
Seuil ou traitement des donnees manquantes inadapte
Impact utilisateur ou risque de silence documente
Test de declenchement ou simulation relu

Corriger la telemetrie applicative
Dimension renommee ou absente apres deploiement
Contrat de logs casse
Workbook et alerte dependants du meme champ
Rollback ou hotfix applicatif compare

Traiter l'ingestion
Retard ou trou de collecte confirme
Diagnostic Settings, DCR, agent ou quota a qualifier
Alertes annotees mais pas silenciees sans fin de vie

Ne pas changer
Signal coherent
Pas d'impact utilisateur
Workbook seulement mal interprete
Reevaluation planifiee

Le rollback doit être défini avant le changement: version précédente du Workbook, requête d’alerte précédente, paramètre restauré, ou retour au contrat de télémétrie antérieur.

Conclusion

Un Azure Workbook utile n’est pas seulement un tableau de bord agréable. C’est une interface de décision qui doit rester raccordée aux données brutes, aux alertes et aux contrats de télémétrie. Quand une vue dérive, la bonne réaction n’est pas de retoucher immédiatement les seuils. C’est de séparer signal brut, ingestion, source, permissions, dimensions, KQL et règle d’alerte.

Avec ce runbook, l’équipe peut décider calmement entre corriger le Workbook, corriger l’alerte, réparer la télémétrie, traiter l’ingestion, rollbacker le dernier changement ou simplement ne rien changer. La valeur est là: conserver une chaîne d’exploitation fiable au lieu de maquiller un symptôme dans le panneau le plus visible.