08 · Instrumentation : Azure Monitor, Application Insights, monitoring GitHub, alertes et KQL

Version : 1.1 · Date : 2026-10-22 · Domaine 5 : Implement an instrumentation strategy (5 à 10 %)

En une phrase : AZ-400 attend que vous sachiez brancher la télémétrie (Application Insights avec OpenTelemetry, VM insights, Container insights, Storage et Network insights), la relier aux outils DevOps (annotations de release, check Query Azure Monitor alerts, audit Azure DevOps), surveiller GitHub (insights, charts, métriques Actions), alerter sur les pipelines, puis lire les chiffres : CPU, mémoire, disque, réseau, usage, performance, traces distribuées et requêtes KQL simples.

Ce que l'examen demande#

Texte officiel du guide d'étude AZ-400 (compétences au 27 juillet 2026) :

Ce chapitre reste au niveau DevOps. Pour aller plus loin sans répéter : KQL avancé, Log Analytics workspace et Data Collection Rules dans SC-500, chapitre 11 ; Container insights et Managed Prometheus dans AKS, chapitre 05 ; OpenTelemetry pour les applications d'IA dans AI-300, chapitre 06. Les métriques de flux (DORA, lead time) sont au chapitre 01.

1. Les bases à maîtriser avant tout#

1.1 Azure Monitor en une page#

Azure Monitor est la plateforme de supervision d'Azure. Tout ce que l'examen appelle Application Insights, VM insights, Container insights, Storage insights ou Network insights en fait partie : ce sont des expériences (collecte + vues prêtes à l'emploi) posées sur trois types de données.

Les host metrics (plateforme) arrivent sans rien configurer et sont gardées 93 jours. Tout le reste (journaux d'invité, traces, journaux de conteneurs, audit Azure DevOps) atterrit dans un Log Analytics workspace et se lit en KQL.

1.2 Les briques de collecte#

À l'examen, la question est souvent « où est la donnée et que faut-il activer ? ». Retenir : host metrics = rien à faire ; invité d'une VM = AMA + DCR ; application = Application Insights ; ressource PaaS = diagnostic settings.

1.3 Le parcours d'une alerte#

graph LR
    A[Signal<br/>metric, log, activity log] --> B[Alert rule<br/>condition + fréquence]
    B -->|déclenche| C[Alert<br/>état Fired]
    C --> D[Action group<br/>email, SMS, webhook, Logic App…]
    C -.->|bloque| E[Environment Azure Pipelines<br/>check Query Azure Monitor alerts]
    D --> F[Équipe d'astreinte<br/>Teams, ticket, work item]

2. Intégrer Azure Monitor aux outils DevOps#

Quatre points de contact sont au programme : marquer les déploiements dans la télémétrie, empêcher une promotion pendant un incident, envoyer l'audit Azure DevOps dans Azure Monitor Logs et transformer une alerte en ticket.

2.1 Les release annotations : voir le déploiement sur la courbe#

Une release annotation pose un marqueur sur les graphiques d'Application Insights (Metrics explorer, Performance, Failures, workbooks) au moment d'un déploiement. Une hausse d'erreurs juste après le marqueur désigne la release coupable.

• Automatique avec les tâches de déploiement Azure Pipelines (AzureWebApp, AzureFunctionApp, AzureRmWebAppDeployment en version 3 et plus…), si l'application a le paramètre APPLICATIONINSIGHTS_CONNECTION_STRING (ou l'ancien APPINSIGHTS_INSTRUMENTATIONKEY) et que la ressource Application Insights est dans le même abonnement.
• Manuel : script CreateReleaseAnnotation.ps1 fourni par Microsoft Learn, appelé en fin de pipeline (Azure Pipelines ou GitHub Actions) ; l'annotation a Category = Deployment.
• Les annotations sont aussi visibles dans les workbooks (Annotations coché dans un graphique de séries temporelles).

2.2 Bloquer un déploiement pendant un incident : le check Query Azure Monitor alerts#

Sur un environment (ou une service connection, un agent pool…) d'Azure Pipelines : Pipelines > Environments > prod > Approvals and checks > + > Query Azure Monitor alerts.

Le check réussit quand aucune alerte filtrée n'est active. Il fait partie des checks dynamiques : l'ordre d'évaluation est checks statiques (branch control, required template) → approbations « pre-check » → checks dynamiques (Azure Monitor, Invoke REST API, Invoke Azure Function) → approbations « post-check » → exclusive lock (détail : chapitre 04, § 10.2).

En pipeline classic, le même rôle est tenu par le gate Query Azure Monitor alerts ou la tâche AzureMonitor@1, utilisable seulement dans un agentless job (pool: server).

Le check ne surveille pas la release en cours : il regarde l'état des alertes avant d'autoriser le stage. Pour un déploiement progressif (« déployer, observer 30 minutes, continuer »), le combiner avec un délai entre stages ou une stratégie canary (chapitre 05).

2.3 L'audit d'Azure DevOps dans Azure Monitor Logs#

L'audit streaming envoie les événements d'audit de l'organisation (changements de permissions, de pipelines, de policies, création de PAT…) vers un outil externe : Organization settings > Auditing > Streams > New stream.

Le stream Azure Monitor Logs se crée avec le Resource ID du workspace et le Tenant ID, puis Sign in to Azure : aucune clé à copier. Un stream désactivé rattrape à sa réactivation les événements des 7 derniers jours.

// Qui a modifié quoi cette semaine dans Azure DevOps ?
AzureDevOpsAuditing
| where TimeGenerated > ago(7d)
| summarize Evenements = count() by OperationName, ActorUPN
| top 20 by Evenements desc

Une log search alert sur cette table (par exemple sur les opérations de suppression de pipeline ou de changement de policy) prévient la sécurité sans outil supplémentaire. Microsoft Sentinel peut lire la même table (voir SC-500).

2.4 Transformer une alerte en work item ou en message#

L'action group d'une alerte appelle un Logic App (ou un webhook, une Azure Function) qui crée un work item Azure Boards, une issue GitHub ou un message Teams. Microsoft Learn propose ce scénario « alerte → work item » ; il évite d'ouvrir les tickets à la main pendant un incident. Pour un outil ITSM (ServiceNow…), l'action ITSM existe aussi.

Dans l'autre sens, un service hook Azure DevOps peut envoyer une annotation Grafana à chaque déploiement terminé, pour marquer les tableaux de bord Azure Managed Grafana.

3. Collecter la télémétrie#

3.1 Application Insights et OpenTelemetry#

Application Insights est l'APM d'Azure Monitor : requêtes entrantes, dépendances (SQL, HTTP, Service Bus…), exceptions, traces de log, métriques, vues de page et événements. Une ressource Application Insights est workspace-based : ses données vivent dans un Log Analytics workspace (les ressources classic ont été retirées).

Trois façons d'envoyer la télémétrie :

Le lien entre l'application et la ressource est la connection string, passée par la variable d'environnement APPLICATIONINSIGHTS_CONNECTION_STRING (paramètre d'application App Service, secret du pipeline, Key Vault). Elle n'est pas un mot de passe, mais elle reste hors du code ; pour n'accepter que la télémétrie authentifiée, activer l'authentification Microsoft Entra de l'ingestion et désactiver l'authentification locale de la ressource.

Python (Microsoft OpenTelemetry Distro) :

# pip install microsoft-opentelemetry
# La connection string est lue dans APPLICATIONINSIGHTS_CONNECTION_STRING : rien en dur dans le code
from microsoft.opentelemetry import use_microsoft_opentelemetry
from opentelemetry import trace

use_microsoft_opentelemetry(enable_azure_monitor=True)  # requêtes, dépendances, logs et métriques collectés

tracer = trace.get_tracer(__name__)
with tracer.start_as_current_span("calcul-panier"):      # span personnalisé, visible dans la transaction
    pass

.NET (ASP.NET Core, Microsoft OpenTelemetry Distro) :

// Program.cs (dotnet add package Microsoft.OpenTelemetry) ; connection string lue dans APPLICATIONINSIGHTS_CONNECTION_STRING
using Microsoft.OpenTelemetry;

var builder = WebApplication.CreateBuilder(args);
builder.UseMicrosoftOpenTelemetry(o => o.Exporters = ExportTarget.AzureMonitor);
var app = builder.Build();
app.Run();

Pour une application console : OpenTelemetrySdk.Create(t => t.UseMicrosoftOpenTelemetry(…)), gardé en vie jusqu'à l'arrêt.

Java : ajouter l'agent au démarrage, sans changer le code.

java -javaagent:applicationinsights-agent-3.7.9.jar -jar app.jar

Réglages utiles à l'examen :

• Cloud role name : nom du nœud dans Application Map, tiré de service.name (et service.namespace) d'OpenTelemetry, par exemple OTEL_SERVICE_NAME=api ; l'instance vient de service.instance.id. Sans lui, deux services se confondent sur la carte.
• Sampling : réduit le volume (et le coût) en gardant des transactions complètes. Python : OTEL_TRACES_SAMPLER=microsoft.fixed_percentage et OTEL_TRACES_SAMPLER_ARG=0.1 (10 %) ; l'agent Java échantillonne par défaut à 5 requêtes par seconde. En KQL, compter avec sum(ItemCount) et non count() (§ 9).
• Tables (workspace) : AppRequests, AppDependencies, AppExceptions, AppTraces, AppMetrics, AppPageViews, AppEvents, AppAvailabilityResults. Dans la ressource Application Insights, les mêmes données s'appellent requests, dependencies, exceptions, traces, customMetrics, pageViews, customEvents, availabilityResults.
• Les anciens SDK « classic » Application Insights restent en maintenance : pour un nouveau projet, OpenTelemetry.

Créer la ressource (lab, abonnement de test ; nécessite l'extension CLI application-insights) :

# Ressource workspace-based, puis lecture de sa connection string pour l'injecter en paramètre d'application
az monitor app-insights component create --app appi-shop-dev --location francecentral \
  --resource-group rg-shop-dev --workspace "$LOG_ANALYTICS_WORKSPACE_ID"
az monitor app-insights component show --app appi-shop-dev --resource-group rg-shop-dev --query connectionString -o tsv

3.2 VM insights#

VM insights surveille les VM Azure et les serveurs Arc : performance de l'invité et, en option, processus et connexions.

Une nouvelle expérience basée sur les métriques (métriques d'invité OpenTelemetry vers un Azure Monitor workspace, préversion) coexiste avec l'expérience classique basée sur les logs. À l'examen, la réponse attendue reste : agent + DCR + InsightsMetrics.

Sans VM insights, la VM a déjà ses host metrics (Percentage CPU, Disk Read Bytes, Network In Total…) : elles voient la VM depuis l'hyperviseur, pas l'intérieur du système (espace disque libre, mémoire réellement utilisée par les processus).

3.3 Container insights#

Container insights collecte les journaux et l'inventaire d'AKS (et des clusters Arc-enabled Kubernetes) dans un Log Analytics workspace ; les métriques passent désormais par Managed Prometheus (Azure Monitor workspace) et se lisent dans Azure Managed Grafana.

# Lab (abonnement de test) : logs vers un workspace, métriques Prometheus vers un Azure Monitor workspace + Grafana
az aks enable-addons --addon monitoring --name aks-dev --resource-group rg-aks-dev \
  --workspace-resource-id "$LOG_ANALYTICS_WORKSPACE_ID"
az aks update --name aks-dev --resource-group rg-aks-dev --enable-azure-monitor-metrics \
  --azure-monitor-workspace-resource-id "$AZURE_MONITOR_WORKSPACE_ID" --grafana-resource-id "$GRAFANA_ID"

Détails d'exploitation (alertes Prometheus recommandées, tableaux Grafana, coûts) : AKS, chapitre 05.

3.4 Storage insights (Azure Monitor for Storage)#

Storage insights (Monitor > Insights > Storage accounts) donne, sans configuration, une vue unifiée de tous les storage accounts à partir de leurs metrics de plateforme :

• Performance : Success E2E Latency, Success Server Latency (l'écart entre les deux = réseau ou client lent) ;
• Failures : Transactions découpées par ResponseType (throttling, erreurs d'autorisation, erreurs réseau client…) ;
• Availability : pourcentage de requêtes réussies ;
• Capacity : Used capacity par service (Blob, File, Queue, Table).

Pour le détail requête par requête (qui a lu quel blob), activer les diagnostic settings du storage account vers un workspace (table StorageBlobLogs) : c'est payant et ce n'est pas fait par Storage insights.

3.5 Network insights (Azure Monitor for Networks)#

Network insights (Monitor > Insights > Networks) assemble, sans configuration, la santé et les metrics de toutes les ressources réseau déployées : Application Gateway, Load Balancer, VPN et ExpressRoute gateways, Azure Firewall, Front Door…

Rien de nouveau pour un titulaire de l'AZ-700 : à l'examen AZ-400, retenir seulement que la vue existe, qu'elle est gratuite et qu'elle centralise.

4. Surveiller dans GitHub#

4.1 Les insights d'un repository#

Onglet Insights d'un repository :

Pas d'activation : ces graphiques existent pour tout repository. Le dependency graph peut devoir être activé dans Settings > Code security sur un repo privé.

4.2 Les insights de GitHub Projects : créer et configurer des charts#

Un project (GitHub Projects) a un menu Insights qui construit des graphiques à partir de ses items.

• Current charts : l'état actuel (ex. nombre d'items par statut, par assigné, par itération).
• Historical charts : l'évolution dans le temps, axe X = Time ; le graphique par défaut est un Burn up.

Créer et configurer un chart : Insights > New chart, puis le panneau Configure :

Puis Save changes. Toute personne qui peut voir le project voit ses charts. C'est l'équivalent GitHub des widgets de tableau de bord d'Azure Boards (chapitre 01).

4.3 Les métriques de GitHub Actions#

Au niveau de l'organization (Insights) :

• Actions Usage Metrics : minutes consommées par workflow, job, repository, système d'exploitation et type de runner ; répond à « qui consomme nos minutes ? » ;
• Actions Performance Metrics : durée moyenne des runs, temps d'attente en file (manque de runners), taux d'échec par workflow ou job.

Accès : propriétaires de l'organisation, ou rôle personnalisé avec la permission View organization Actions metrics. Périodes : jusqu'à un an, plage personnalisée de 100 jours au plus. Ces vues font le lien avec la « santé des pipelines » du chapitre 06.

5. Alerter sur les événements de GitHub Actions et Azure Pipelines#

Trois familles d'alertes coexistent, chacune pour son type d'événement :

5.1 Azure Monitor : alert rules et action groups#

À retenir : une alert rule appelle jusqu'à 5 action groups ; une alerte reste visible 30 jours ; les alert processing rules suppriment les notifications pendant une maintenance planifiée ou ajoutent un action group à toute une portée.

# Lab (abonnement de test) : un action group email, puis une alerte CPU sur une VM qui l'appelle
az monitor action-group create --name ag-devops-oncall --resource-group rg-monitoring-dev \
  --short-name oncall --action email oncall "[email protected]"

az monitor metrics alert create --name alert-vm-cpu-high --resource-group rg-monitoring-dev \
  --scopes "$VM_ID" --condition "avg Percentage CPU > 90" \
  --window-size 5m --evaluation-frequency 1m --severity 2 \
  --action ag-devops-oncall --description "CPU de la VM au-dessus de 90 % sur 5 minutes"

Pour recevoir l'alerte dans Teams ou dans un outil maison : action Webhook (charge utile common alert schema recommandée) ou Secure webhook (authentifié par Microsoft Entra), ou Logic App (§ 2.4).

5.2 Azure Pipelines#

Notifications (User settings ou Project settings > Notifications) : abonnements personnels, d'équipe, de projet ou globaux (organisation) sur des événements comme Build fails, Build completes, Run stage waiting for approval, Run stage waiting for manual validation, ou, en classic release, Release deployment approval pending. Les abonnements par défaut préviennent déjà celui qui a déclenché un build en échec.

Apps de messagerie : l'app Azure Pipelines pour Microsoft Teams ou Slack abonne un canal aux événements d'un pipeline et permet d'approuver un déploiement depuis le canal :

Slack : /azpipelines subscribe https://dev.azure.com/{organisation}/{projet}/_build?definitionId={id}
Teams : @Azure Pipelines subscribe https://dev.azure.com/{organisation}/{projet}/_build?definitionId={id}

Service hooks (Project settings > Service hooks) : envoient l'événement (run state changed, run stage state changed…) à un webhook, Azure Service Bus, Azure Storage queue, Grafana, Jenkins… Une souscription en échec répété ou inactive est désactivée ; la charge utile est limitée (2 Mo).

Dans le YAML, un job de notification conditionnel complète le tout :

# Prévenir l'équipe seulement si un job précédent a échoué (webhook stocké en variable secrète)
- job: notify_failure
  dependsOn: [build, deploy]
  condition: failed()
  pool:
    vmImage: ubuntu-latest
  steps:
    - script: |
        curl -sS -X POST -H "Content-Type: application/json" \
          -d "{\"text\":\"Échec de $(Build.DefinitionName) #$(Build.BuildNumber)\"}" "$ALERT_WEBHOOK_URL"
      env:
        ALERT_WEBHOOK_URL: $(alertWebhookUrl)   # variable secrète, jamais en clair dans le YAML

5.3 GitHub Actions#

• Notifications GitHub (Settings > Notifications > System > Actions) : email et/ou web pour les runs que vous avez déclenchés ; un workflow planifié (schedule) notifie celui qui l'a créé ou modifié en dernier. Option Only notify for failed workflows.
• Status badge dans le README, par workflow, branche ou événement :

![CI](https://github.com/OWNER/REPO/actions/workflows/ci.yml/badge.svg?branch=main&event=push)

• Step if: failure() pour prévenir un canal (même principe que le job Azure Pipelines) :

      - name: Prévenir l'équipe en cas d'échec
        if: failure()
        run: |
          curl -sS -X POST -H "Content-Type: application/json" \
            -d "{\"text\":\"Échec de ${{ github.workflow }} sur ${{ github.ref_name }} : ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}\"}" \
            "$ALERT_WEBHOOK_URL"
        env:
          ALERT_WEBHOOK_URL: ${{ secrets.ALERT_WEBHOOK_URL }}

• Workflow centralisé déclenché par l'événement workflow_run : il réagit à la fin d'autres workflows et filtre sur github.event.workflow_run.conclusion == 'failure' ; pratique pour une seule logique d'alerte pour tous les workflows d'un repo.

on:
  workflow_run:
    workflows: ["CI", "Deploy"]
    types: [completed]
jobs:
  alert:
    if: ${{ github.event.workflow_run.conclusion == 'failure' }}
    runs-on: ubuntu-latest
    steps:
      - run: echo "Échec de ${{ github.event.workflow_run.name }} : ${{ github.event.workflow_run.html_url }}"

• Webhook de repository ou d'organisation sur l'événement workflow_run ou workflow_job vers un outil externe (signé par X-Hub-Signature-256, chapitre 01).

6. Les indicateurs d'infrastructure : CPU, mémoire, disque, réseau#

Deux sources, à ne pas confondre :

Où regarder :

• Metrics explorer (Monitor > Metrics ou la VM > Metrics) : choisir la metric, l'agrégation (Avg, Min, Max, Sum, Count), Apply splitting (par instance, par disque), Add filter, plusieurs ressources d'un même type et d'une même région sur un graphique, puis Pin to dashboard ou New alert rule directement depuis le graphique.
• VM insights > Performance : vue Top N sur toutes les VM d'un abonnement (les 20 premières, jusqu'à 500 en liste), avec percentiles (P50, P90, P95) : la bonne vue pour trouver « la » VM saturée parmi cent.
• Workbooks pour un tableau de bord partagé (metrics + KQL dans la même page) ; Azure Managed Grafana pour Prometheus et le multi-cloud.

// CPU moyen par VM sur la dernière heure (VM insights)
InsightsMetrics
| where TimeGenerated > ago(1h)
| where Origin == "vm.azm.ms" and Namespace == "Processor" and Name == "UtilizationPercentage"
| summarize CpuMoyen = avg(Val) by bin(TimeGenerated, 5m), Computer
| render timechart

// Disques logiques à moins de 10 % d'espace libre
InsightsMetrics
| where TimeGenerated > ago(30m)
| where Namespace == "LogicalDisk" and Name == "FreeSpacePercentage"
| summarize LibreMin = min(Val) by Computer, Disque = tostring(todynamic(Tags)["vm.azm.ms/mountId"])
| where LibreMin < 10

// Machines qui n'envoient plus de heartbeat depuis 15 minutes (agent arrêté, VM éteinte)
Heartbeat
| summarize DernierSignal = max(TimeGenerated) by Computer
| where DernierSignal < ago(15m)

Un seuil fixe (CPU > 80 %) bruite vite sur une charge variable : les dynamic thresholds d'une metric alert apprennent la saisonnalité. Toujours définir les seuils à partir d'une baseline mesurée, pas d'une valeur au hasard.

7. Analyser l'usage et la performance applicative#

7.1 La performance et les échecs#

Dans la ressource Application Insights :

Méthode type après une release : Failures filtré sur la dernière heure → opération la plus touchée → code de réponse ou exception dominant → Drill into samples → End-to-end transaction details pour voir la dépendance en cause.

graph TD
    A[Alerte ou plainte<br/>après un déploiement] --> B{Annotation de release<br/>juste avant la hausse ?}
    B -->|oui| C[Failures / Performance<br/>de cette release]
    B -->|non| D[Application Map<br/>et Service Health]
    C --> E{Erreur dans le code<br/>ou dans une dépendance ?}
    E -->|code| F[Exceptions + transaction<br/>rollback ou hotfix]
    E -->|dépendance| G[AppDependencies<br/>Target, ResultCode, durée]
    D --> H[VM insights / Container insights<br/>CPU, mémoire, disque, réseau]

7.2 L'usage#

Les vues Usage d'Application Insights s'appuient sur la télémétrie du navigateur (SDK JavaScript) et sur les événements personnalisés envoyés par le code :

Côté DevOps, l'usage sert à valider une fonctionnalité livrée derrière un feature flag (chapitre 05) : comparer l'adoption et les échecs de la cohorte qui a la fonction avec les autres.

7.3 Les metrics applicatives en KQL#

// Volume, taux d'échec et P95 par tranche de 5 minutes (sum(ItemCount) corrige le sampling)
AppRequests
| where TimeGenerated > ago(6h)
| summarize Requetes = sum(ItemCount),
            Echecs = sumif(ItemCount, Success == false),
            P95ms = percentile(DurationMs, 95) by bin(TimeGenerated, 5m)
| extend TauxEchec = round(100.0 * Echecs / Requetes, 2)
| render timechart

// Dépendances les plus lentes (SQL, HTTP…) par cible
AppDependencies
| where TimeGenerated > ago(1h)
| summarize Appels = sum(ItemCount), DureeMoyenneMs = avg(DurationMs), Echecs = countif(Success == false) by Target, DependencyType
| top 10 by DureeMoyenneMs desc

8. La trace distribuée dans Application Insights#

8.1 Le principe#

Une requête utilisateur traverse plusieurs composants (navigateur, front, API, base de données). Pour la suivre, chaque composant propage un contexte de trace dans l'en-tête HTTP W3C Trace Context :

traceparent: 00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-01
             │  └── trace-id (32 hex) ─────────┘ └ parent-id (16) ┘ └ flags (01 = échantillonné)
             └ version

L'ancien en-tête Request-Id (Application Insights historique) est déprécié : W3C Trace Context est le standard, et les distributions OpenTelemetry le propagent automatiquement pour HTTP.

sequenceDiagram
    participant N as Navigateur (JavaScript SDK)
    participant W as Frontend (cloud role web)
    participant A as API (cloud role api)
    participant S as Azure SQL
    N->>W: GET /Home/Stock + traceparent (trace-id T)
    Note over W: request enregistrée, operation_Id = T
    W->>A: GET /api/stock/value + traceparent (trace-id T, parent = span du front)
    Note over A: request enregistrée, operation_ParentId = dependency du front
    A->>S: requête SQL
    Note over A: dependency SQL enregistrée, même operation_Id T
    A-->>W: 200
    W-->>N: 200

8.2 Les vues de la trace#

• Application Map : un nœud par cloud role name, les dépendances entre eux, avec appels, durée et taux d'échec sur chaque lien ; cliquer un nœud ouvre Investigate failures / performance. Au-delà de 1 000 nœuds non groupés, la carte se simplifie : bien nommer les rôles.
• End-to-end transaction details (depuis Failures, Performance ou Search) : diagramme de Gantt de tous les spans de l'operation_Id, avec durées, exceptions et logs associés. C'est la vue pour dire « la lenteur vient de la requête SQL ».
• Transaction search : retrouver une transaction par son id, un utilisateur, un code de réponse.

8.3 Ce qui casse une trace#

// Reconstituer une transaction complète à partir de son operation_Id
union AppRequests, AppDependencies, AppExceptions, AppTraces
| where OperationId == "0af7651916cd43dd8448eb211c80319c"
| project TimeGenerated, Type, AppRoleName, Name, Target, DurationMs, Success, ParentId, Id
| sort by TimeGenerated asc

Pour la trace d'applications d'IA (spans d'appels de modèles, de tools, d'agents), voir AI-300, chapitre 06.

9. Interroger les logs en KQL#

9.1 L'essentiel#

Une requête KQL commence par une table et enchaîne des opérateurs séparés par |, chacun travaillant sur le résultat du précédent. Elle est en lecture seule : on ne modifie jamais les données en KQL.

Où l'exécuter : Logs d'un Log Analytics workspace, d'une ressource Application Insights ou d'une VM (portée réduite à la ressource) ; dans un workbook ; dans une log search alert. Le mode Simple du portail construit la requête sans la taper ; l'examen demande de lire et de compléter des requêtes simples.

9.2 Cinq requêtes à savoir écrire#

// 1. Les codes d'erreur HTTP des dernières 24 heures
AppRequests
| where TimeGenerated > ago(24h) and Success == false
| summarize Nombre = sum(ItemCount) by ResultCode
| sort by Nombre desc

// 2. Les exceptions liées aux requêtes en échec (corrélation par OperationId)
AppRequests
| where TimeGenerated > ago(1h) and Success == false
| join kind=inner (AppExceptions | where TimeGenerated > ago(1h)) on OperationId
| summarize Nombre = count() by Name, ExceptionType
| top 10 by Nombre desc

// 3. Comparer le temps de réponse avant et après un déploiement (heure du déploiement à adapter)
let deploiement = datetime(2026-10-21 14:00);
AppRequests
| where TimeGenerated between ((deploiement - 2h) .. (deploiement + 2h))
| extend Periode = iff(TimeGenerated < deploiement, "avant", "après")
| summarize P95ms = percentile(DurationMs, 95), Requetes = sum(ItemCount) by Periode, Name

// 4. Utilisateurs distincts par jour (vues de page du SDK JavaScript)
AppPageViews
| where TimeGenerated > ago(14d)
| summarize Utilisateurs = dcount(UserId) by bin(TimeGenerated, 1d)
| render columnchart

// 5. Journaux d'erreur des conteneurs AKS sur 30 minutes (Container insights)
ContainerLogV2
| where TimeGenerated > ago(30m)
| where LogLevel in ("ERROR", "CRITICAL")   // LogLevel est déduit du message
| project TimeGenerated, PodNamespace, PodName, ContainerName, LogMessage
| take 50

9.3 Les réflexes#

• Filtrer le temps en premier : coût et vitesse de la requête.
• sum(ItemCount) au lieu de count() dès que le sampling est actif.
• Même requête, deux noms de tables : AppRequests (workspace, colonnes DurationMs, OperationId) ou requests (ressource Application Insights, colonnes duration, operation_Id).
• Une log search alert = une requête KQL + une fréquence + un seuil sur le nombre de lignes ou une valeur agrégée.
• Pour aller au-delà (fonctions, parse, mv-expand, requêtes de chasse) : SC-500, chapitre 11.

10. Labs conseillés#

Abonnement de test uniquement. Coût faible si tout est supprimé le jour même : une App Service B1, une petite VM, un workspace avec quelques Mo ingérés. Organisation Azure DevOps et compte GitHub gratuits.

1. Application Insights + OpenTelemetry : créer un workspace et une ressource Application Insights, déployer une petite API Python ou .NET sur App Service avec la Microsoft OpenTelemetry Distro et APPLICATIONINSIGHTS_CONNECTION_STRING en paramètre d'application. Générer du trafic et quelques erreurs. Attendu : requêtes dans Performance, erreurs dans Failures, données dans AppRequests.
2. Trace distribuée : ajouter un second service (front → API) avec deux OTEL_SERVICE_NAME différents. Attendu : deux nœuds dans Application Map, une transaction complète dans End-to-end transaction details, même OperationId dans les deux tables. Refaire avec le même nom de service : un seul nœud.
3. Release annotation + check : pipeline Azure Pipelines qui déploie avec AzureWebApp, puis voir l'annotation dans Metrics. Créer une metric alert sur Http5xx, l'environment prod avec le check Query Azure Monitor alerts, déclencher l'alerte. Attendu : le stage prod attend puis échoue au timeout tant que l'alerte est active.
4. VM insights : petite VM Linux, activer VM insights, comparer Percentage CPU (host) et InsightsMetrics (invité), lancer stress ou une boucle CPU, regarder Top N, créer la metric alert du § 5.1. Arrêter l'agent : Attendu : la requête Heartbeat du § 6 la remonte.
5. GitHub : dans un repo, consulter Insights > Pulse, Traffic ; dans un project, créer un chart Status groupé par assigné, puis un historique. Ajouter un workflow qui échoue volontairement, le badge, le step if: failure() et un workflow workflow_run. Attendu : notification d'échec et run du workflow d'alerte.
6. Audit streaming (organisation reliée à Entra ID) : créer un stream vers le workspace, modifier une permission, attendre le lot, requêter AzureDevOpsAuditing.
7. KQL : refaire les requêtes des § 6, 7.3, 8.3 et 9.2 sur les données des labs, puis sur l'environnement de démonstration public de Log Analytics (Log Analytics demo), sans coût.

Nettoyage : supprimer les resource groups des labs (workspace compris), le stream d'audit, les alert rules et l'action group ; désactiver le check sur l'environment de test.

11. Pièges d'examen#

12. Scénarios corrigés#

1. Après chaque déploiement du vendredi, le taux d'erreurs monte pendant une heure. L'équipe veut savoir quelle release est en cause sans croiser les heures à la main.

Release annotations : avec la tâche AzureWebApp et APPLICATIONINSIGHTS_CONNECTION_STRING sur la Web App, les marqueurs apparaissent seuls sur les graphiques Failures et Metrics ; sinon CreateReleaseAnnotation.ps1 en fin de pipeline.

2. Un incident Sev1 est en cours sur la production. Le pipeline ne doit pas pouvoir y déployer tant qu'il dure, sans qu'un humain y pense.

Check Query Azure Monitor alerts sur l'environment prod (filtre Sev0/Sev1, état Fired), avec un timeout. Le stage attend que l'alerte soit résolue.

3. Une API Python sur AKS doit apparaître dans Application Map avec sa dépendance PostgreSQL, sans mettre la connection string dans l'image.

Microsoft OpenTelemetry Distro dans le code, APPLICATIONINSIGHTS_CONNECTION_STRING injectée par un secret Kubernetes ou Key Vault (CSI), OTEL_SERVICE_NAME=api pour le cloud role name. Alternative sans code : autoinstrumentation AKS si le langage est supporté.

4. Le client se plaint que la page « Stock » est lente. Performance montre un P95 de 4 secondes sur GET Home/Stock.

Drill into samples → End-to-end transaction details : le Gantt montre quelle dépendance (appel d'API, requête SQL) porte le temps. Même operation_Id du navigateur à la base. En KQL : union AppRequests, AppDependencies | where OperationId == "…".

5. Les responsables sécurité veulent être prévenus quand quelqu'un modifie les permissions d'un projet Azure DevOps, et garder une trace un an.

Audit streaming vers un Log Analytics workspace (rétention configurée à un an), puis log search alert sur AzureDevOpsAuditing filtrée sur les opérations de sécurité, avec un action group vers l'équipe sécurité.

6. Une flotte de 200 VM : l'astreinte veut voir d'un coup les dix plus chargées en CPU et celles dont un disque est presque plein.

VM insights activé par Azure Policy sur l'abonnement, vue Performance > Top N (CPU Utilization %, Logical Disk Space Used %) ; pour l'alerte, log search alert sur InsightsMetrics (FreeSpacePercentage < 10).

7. Le chef de projet veut, dans GitHub, un graphique du nombre d'issues par statut et par développeur, et son évolution sur le trimestre.

GitHub Projects > Insights : un current chart (X-axis = Status, Group by = Assignees, layout Stacked column) et un historical chart (X-axis = Time, filtre sur le trimestre). Save changes ; tous ceux qui voient le project les voient.

8. Les workflows GitHub Actions d'un repo échouent parfois la nuit sans que personne ne le voie. On veut un message dans le canal de l'équipe, sans modifier les dix workflows.

Un workflow déclenché par workflow_run (types: [completed]) sur ces workflows, filtré sur github.event.workflow_run.conclusion == 'failure', qui poste dans le canal avec un webhook stocké en secret.

9. Les builds attendent de plus en plus longtemps avant de démarrer et la facture de minutes GitHub augmente.

Organisation > Insights : Actions Performance Metrics (queue time, par runner) pour l'attente, Actions Usage Metrics (minutes par workflow et runner) pour la facture. Puis ajuster runners, concurrence et cache (chapitre 06).

10. La requête AppRequests | where TimeGenerated > ago(1h) | count donne 600 requêtes, alors que le load balancer en compte 6 000.

Le sampling est à 10 % : chaque ligne représente ItemCount requêtes. Utiliser summarize sum(ItemCount).

13. Pour aller plus loin#

• Application Insights Profiler et Snapshot Debugger (.NET) : traces de code des requêtes lentes, état des variables au moment d'une exception.
• Azure Monitor workbooks et dashboards with Grafana : tableaux de bord d'équipe versionnables (modèles ARM / JSON) ; Azure Managed Grafana pour Prometheus et plusieurs clouds.
• OpenTelemetry Collector : recevoir, filtrer et router la télémétrie de plusieurs back-ends avant Azure Monitor.
• Coût : plan Basic ou Auxiliary pour les tables volumineuses peu requêtées, transformations de DCR pour filtrer à l'ingestion, commitment tiers (voir SC-500, chapitre 11).
• SLO et budgets d'erreur : traduire les metrics de disponibilité et de latence en objectifs, et bloquer les mises en production quand le budget est consommé (check du § 2.2).
• Métriques DORA à partir de la télémétrie de déploiement et d'incident : chapitre 01.

14. Fiche à retenir#

• Metrics (plateforme, 93 jours, Metrics explorer) ; logs (Log Analytics workspace, KQL) ; traces (tables App*).
• Host metrics sans agent ; invité = Azure Monitor Agent + DCR (VM insights → InsightsMetrics, Origin = "vm.azm.ms").
• Application Insights workspace-based ; Microsoft OpenTelemetry Distro (.NET, Node.js, Python), agent Java 3.x ; autoinstrumentation App Service / Functions / AKS ; SDK JavaScript pour l'usage.
• APPLICATIONINSIGHTS_CONNECTION_STRING en variable d'environnement ; Entra auth pour l'ingestion ; cloud role name = service.name.
• Container insights = logs (ContainerLogV2, KubeEvents, logging profiles) ; Managed Prometheus = métriques → Grafana.
• Storage insights et Network insights : gratuits, sans configuration ; E2E vs Server latency ; flow logs + Traffic analytics.
• DevOps ↔ Azure Monitor : release annotations, check Query Azure Monitor alerts (dynamique, AzureMonitor@1 en agentless), audit streaming → AzureDevOpsAuditing (Entra, auditing activé, preview, 90 jours natifs), Logic App → work item.
• Alertes : metric (statique / dynamique), log search, activity log ; 5 action groups par règle ; alert processing rules.
• Azure Pipelines : notifications (Build fails, stage waiting for approval), apps Teams / Slack, service hooks, condition: failed().
• GitHub : notifications (déclencheur ; schedule → dernier auteur), badge, if: failure(), workflow_run.
• GitHub Insights : Pulse, Traffic (14 j), Contributors ; Projects charts (current / historical, Layout, X-axis, Group by, Y-axis, Save changes) ; Actions Usage / Performance Metrics.
• Trace : traceparent W3C ; operation_Id = trace-id ; operation_ParentId ; Application Map ; End-to-end transaction.
• KQL : table | where (temps d'abord) | summarize … by bin() | render ; join on OperationId ; sum(ItemCount).

Références#

Lues le 21/10/2026, points incertains revérifiés le 22/10/2026 :

• Study guide for Exam AZ-400
• Azure Monitor overview
• Application Insights overview
• Enable OpenTelemetry in Application Insights
• Configure OpenTelemetry in Application Insights (cloud role name, sampling)
• Autoinstrumentation for Application Insights
• Microsoft Entra authentication for Application Insights
• Application Insights telemetry data model
• Distributed tracing and telemetry correlation
• Application Map
• Transaction search and diagnostics
• Failures and performance views
• Usage analysis with Application Insights
• Live metrics
• Release annotations for Application Insights
• Sampling in Application Insights
• Availability tests
• VM insights overview
• Chart performance with VM insights
• Query performance data from VM insights
• Supported metrics for Microsoft.Compute/virtualMachines
• Container insights overview
• Enable monitoring for AKS clusters
• Monitor your storage service with Azure Monitor Storage insights
• Azure Monitor Network insights
• Metrics explorer
• Azure Monitor alerts overview
• Action groups
• Alert processing rules
• Dynamic thresholds in metric alerts
• az monitor metrics alert
• az monitor action-group
• Define approvals and checks (Query Azure Monitor alerts)
• AzureMonitor@1 task
• Create audit streaming
• Manage notifications (Azure DevOps)
• Azure Pipelines with Microsoft Teams
• Azure Pipelines with Slack
• Integrate with service hooks
• Kusto Query Language overview
• Log Analytics tutorial
• SQL to Kusto query translation
• W3C Trace Context
• GitHub Docs : About repository graphs
• GitHub Docs : Viewing traffic to a repository
• GitHub Docs : About insights for Projects
• GitHub Docs : Configuring charts
• GitHub Docs : Viewing GitHub Actions metrics
• GitHub Docs : Notifications for workflow runs
• GitHub Docs : Adding a workflow status badge
• GitHub Docs : Events that trigger workflows (workflow_run)