Azure Managed Grafana : diagnostiquer un dashboard ou une alerte avant de changer le KQL

Un dashboard Grafana qui devient vide ou une alerte qui cesse de déclencher ressemble vite à un problème de requête KQL. En production, c’est rarement le premier changement à faire. La panne peut venir de la datasource Azure Monitor, d’une identité managée qui a perdu un rôle, d’un workspace Log Analytics remplacé, d’une variable de dashboard, d’une fenêtre temporelle trop courte ou d’une règle d’alerte qui n’exécute plus la même requête que le panneau visible.

Le cas d’usage est une instance Azure Managed Grafana utilisée par l’équipe d’exploitation pour suivre une application critique. Les panels lisent Azure Monitor et Log Analytics, certaines alertes Grafana notifient l’astreinte, et les dashboards servent de preuve pendant les déploiements. Le runbook doit décider s’il faut corriger l’accès, restaurer une datasource, ajuster une variable, rollbacker un dashboard ou seulement ensuite modifier le KQL.

Figer le symptôme observé

Avant de toucher à la requête, décris précisément ce qui a changé. Un panel vide, une valeur plate à zéro et une alerte silencieuse n’ont pas le même diagnostic.

Symptome
Instance Grafana: grafana-ops-prod
Dashboard: api-production-overview
Panel ou regle: 5xx rate / api-prod-high-error-rate
Datasource attendue: Azure Monitor - prod
Workspace attendu: law-observability-prod
Premiere detection: 2026-07-07 09:20 UTC
Dernier changement connu: dashboard import, role assignment, workspace migration ou release applicative

Questions avant correction
Le probleme touche-t-il un panel, tout le dashboard ou toutes les alertes ?
La requete retourne-t-elle des donnees dans Log Analytics hors Grafana ?
La datasource Grafana pointe-t-elle vers le bon tenant, abonnement et workspace ?
L'identite utilisee par Grafana a-t-elle encore les droits de lecture ?
Existe-t-il une version precedente du dashboard ou de la regle d'alerte ?

Cette fiche évite le réflexe classique : réécrire une requête KQL qui fonctionne encore, alors que Grafana ne peut plus interroger la bonne source.

Séparer datasource, workspace et identité

Azure Managed Grafana peut lire Azure Monitor avec une identité managée ou une application Entra ID. Le diagnostic doit prouver quelle identité exécute réellement la requête et sur quel scope elle est autorisée.

GRAFANA_NAME="grafana-ops-prod"
RESOURCE_GROUP="rg-observability-prod"
WORKSPACE_ID="/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-logs-prod/providers/Microsoft.OperationalInsights/workspaces/law-observability-prod"

az grafana show --name "$GRAFANA_NAME" --resource-group "$RESOURCE_GROUP" --query "{name:name,identity:identity,endpoint:properties.endpoint,provisioningState:properties.provisioningState}" --output json

PRINCIPAL_ID="$(az grafana show --name "$GRAFANA_NAME" --resource-group "$RESOURCE_GROUP" --query "identity.principalId" --output tsv)"

az role assignment list --assignee "$PRINCIPAL_ID" --scope "$WORKSPACE_ID" --query "[].{role:roleDefinitionName,scope:scope}" --output table

Pour Log Analytics, l’identité doit au minimum pouvoir lire les données nécessaires. Si le rôle a été donné sur un ancien workspace, sur le mauvais abonnement ou seulement sur un resource group qui ne contient pas le workspace effectif, Grafana affichera un symptôme applicatif alors que la cause est un accès observabilité.

Rejouer la requête hors Grafana

Le test suivant consiste à sortir Grafana de l’équation. Si la requête retourne des données directement depuis Log Analytics, le problème est probablement dans la datasource, les variables, les permissions Grafana ou le rendu du panel. Si elle ne retourne rien, le diagnostic repart vers ingestion, Diagnostic Settings, table ou fenêtre temporelle.

let ServiceName = "api-prod";
let Window = 30m;
AppRequests
| where TimeGenerated > ago(Window)
| where AppRoleName == ServiceName
| summarize Requests = count(), Failures = countif(ResultCode startswith "5") by bin(TimeGenerated, 5m)
| extend FailureRate = todouble(Failures) / todouble(Requests)
| project TimeGenerated, Requests, Failures, FailureRate
| order by TimeGenerated asc

Compare ensuite trois choses : la requête du panel, la requête de la règle d’alerte et la requête exécutée dans Log Analytics. Une alerte Grafana copiée depuis un panel peut garder une ancienne variable, un ancien intervalle ou un seuil qui ne correspond plus au dashboard.

Contrôler les variables et la fenêtre temporelle

Un dashboard peut devenir vide sans incident de données. Une variable environment, service, cluster ou subscription peut ne plus avoir de valeur par défaut, pointer vers un label renommé ou être alimentée par une datasource différente du panel.

Variables a verifier
subscription: valeur par defaut et liste autorisee
workspace: correspondance avec la datasource Azure Monitor
environment: prod, production ou prd selon les logs reels
service: nom AppRoleName, cloud_RoleName ou tag applicatif
interval: resolution compatible avec la fenetre d'alerte
region: filtre non vide apres deploiement multi-region

Suspendre une modification KQL quand
La variable retourne une liste vide
Le panel utilise prod mais l'alerte utilise production
Le dashboard lit un workspace et l'alerte un autre
La fenetre d'alerte est plus courte que le delai d'ingestion observe

Ce contrôle est particulièrement utile après un import de dashboard, une migration de workspace ou une standardisation de tags. Le KQL peut être correct mais recevoir un filtre impossible.

Lire les traces d’exécution et d’alerte

La décision doit s’appuyer sur des preuves. Côté Azure Monitor, vérifie que les données arrivent. Côté Grafana, relève l’exécution de la règle, l’état NoData, Error ou OK, et le message de datasource.

let ChangeStart = datetime(2026-07-07 08:30:00);
let ChangeEnd = datetime(2026-07-07 10:00:00);
AppRequests
| where TimeGenerated between (ChangeStart .. ChangeEnd)
| summarize Requests = count(), Failures = countif(ResultCode startswith "5") by AppRoleName, bin(TimeGenerated, 5m)
| order by TimeGenerated desc

Si les données sont présentes dans Log Analytics mais absentes de Grafana, ne modifie pas encore les tables ni les Diagnostic Settings. Le prochain contrôle porte sur datasource, identité, variables et règle d’alerte. Si les données sont absentes partout, le problème est en amont : ingestion, SDK, Diagnostic Settings ou pipeline de logs.

Décider correction, rollback ou changement KQL

La décision doit rester réversible. Un changement KQL en urgence peut masquer la cause réelle et rendre l’incident suivant plus difficile à diagnostiquer.

Corriger l'acces
La requete fonctionne dans Log Analytics
Grafana pointe vers la bonne datasource
L'identite Grafana a perdu le role Reader ou Log Analytics Reader
La correction est un role assignment borne au workspace attendu

Restaurer datasource ou dashboard
Le workspace, tenant ou abonnement a change sans intention
Une variable de dashboard filtre toutes les series
La regle d'alerte ne correspond plus au panel valide
Une version precedente connue existe dans Git ou dans l'historique Grafana

Modifier le KQL
La table ou le schema a reellement change
La requete echoue aussi hors Grafana
Le nouveau filtre est documente et teste sur une fenetre representative
L'alerte et le dashboard sont mis a jour ensemble

Rollbacker
Le dashboard importé casse plusieurs panels critiques
Les alertes passent en NoData ou Error sans preuve applicative
Le role assignment requis ne peut pas etre valide pendant la fenetre
La version precedente redonne le signal attendu

Après rollback, rejoue la requête de preuve et vérifie au moins une exécution de règle d’alerte. Le retour à un dashboard visuel ne suffit pas si l’alerte reste muette.

Conclusion

Un incident Grafana n’est pas automatiquement un incident KQL. Dans Azure Managed Grafana, le chemin complet traverse datasource, identité, workspace, variables, requêtes, règles d’alerte et délais d’ingestion.

Le bon réflexe consiste à qualifier le signal avant de changer le code de la requête : rejouer hors Grafana, prouver l’identité, comparer panel et alerte, vérifier les variables, puis choisir entre correction d’accès, restauration de configuration, changement KQL ou rollback. Le dashboard redevient alors un outil d’exploitation fiable, pas seulement une interface qui semble verte.