Microsoft AZ-204: Supervision, diagnostics et intégration DevOps Azure — Guide d'étude

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

Fait partie du Microsoft Azure Developer Associate AZ-204 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Microsoft, ou passez des tests chronométrés sur ExamRoll.io.

Vue d’ensemble

Azure Monitor et Application Insights fournissent une pile d’observabilité unifiée et axée sur les développeurs pour les applications Azure. Application Insights collecte la télémétrie des applications telle que les requêtes, les dépendances, les exceptions et les traces, tandis qu’Azure Monitor agrège les métriques et les journaux de toutes les ressources dans un espace de travail Log Analytics et pilote les alertes et les intégrations DevOps. La maîtrise des choix d’instrumentation, de la sémantique de la télémétrie, des tests de disponibilité, du Kusto Query Language (KQL), des alertes avec des groupes d’actions, du suivi distribué et de l’Infrastructure as Code avec les modèles ARM garantit des solutions fiables, diagnosticables et automatisables.

Instrumentation et télémétrie d’Application Insights

Les ressources Application Insights sont identifiées pour l’ingestion soit par une clé d’instrumentation, soit par une chaîne de connexion. La clé d’instrumentation est l’ancien GUID unique utilisé par les SDK pour router la télémétrie. La chaîne de connexion est la recommandation actuelle ; elle inclut la clé d’instrumentation ainsi que les métadonnées de point de terminaison (points de terminaison d’ingestion et de Live Metrics) et permet le routage vers des points de terminaison non par défaut (pour les clouds souverains ou privés). Utilisez la chaîne de connexion dans les nouveaux codes et configurations ; elle permet de futurs changements de point de terminaison sans redéploiement de code. Au sein d’un App Service, l’activation d’Application Insights au niveau de la plateforme remplira la chaîne de connexion dans les paramètres d’environnement pour les runtimes auto-détectés.

L’instrumentation peut se faire via un SDK ou par auto-instrumentation. L’approche SDK (par exemple, Microsoft.ApplicationInsights.AspNetCore pour .NET, applicationinsights pour Node.js, et l’agent Java Application Insights) offre un contrôle au niveau du code : événements personnalisés, métriques et télémétrie enrichie via des TelemetryInitializers et des processeurs, y compris l’échantillonnage adaptatif. L’auto-instrumentation (attachement sans code) est disponible pour App Service et certaines piles de calcul et utilise des extensions de site/agents pour collecter les requêtes entrantes, les dépendances et les exceptions sans aucune modification de code. Utilisez l’instrumentation par SDK lorsque vous avez besoin d’événements personnalisés, de métriques métier ou d’une corrélation explicite dans les tâches en arrière-plan ; utilisez l’attachement sans code pour une visibilité rapide et à faible effort ou pour les charges de travail lift-and-shift. Dans les deux cas, définissez le nom de rôle cloud pour distinguer les services dans une architecture de microservices et configurez l’échantillonnage avec soin pour équilibrer la fidélité et le coût.

Application Insights émet plusieurs types de télémétrie de base :

Les Requêtes capturent les opérations entrantes (requêtes HTTP, invocations de fonctions), avec la durée, le code de réponse et le succès.
Les Dépendances capturent les appels sortants (HTTP, SQL, appels Azure SDK, files d’attente), avec la cible, le type, la durée et le succès.
Les Exceptions capturent les erreurs levées, les traces de pile et les exceptions gérées lorsqu’elles sont suivies explicitement.
Les Traces capturent les messages de journal ; les SDK s’intègrent aux frameworks de journalisation populaires afin que les journaux et la télémétrie partagent la corrélation.
Les Événements capturent les occurrences personnalisées au niveau métier via TrackEvent, prenant en charge les dimensions et les décomptes personnalisés.
Les Métriques capturent des mesures numériques ; vous pouvez suivre des métriques personnalisées pour les KPI et les inspecter dans Metrics Explorer.

Le suivi distribué dans Application Insights repose sur la corrélation. Chaque opération de bout en bout a un ID d’opération (ID de trace en termes W3C) partagé entre les données de télémétrie associées ; chaque span a des relations parent-enfant appliquées par des en-têtes de propagation. Les SDK modernes utilisent le W3C Trace Context (traceparent, tracestate). Operation_Id dans KQL relie les Requêtes, Dépendances, Exceptions et Traces pour la même transaction. Assurez-vous que les clients HTTP sortants propagent les en-têtes ; pour .NET, System.Diagnostics.Activity et le SDK AI s’en chargent automatiquement. Le suivi des dépendances instrumente les clients courants (HTTP, SQL, Service Bus, Storage). Lorsque les services franchissent des frontières (par ex., d’App Service à AKS), une propagation cohérente produit une carte de transaction connectée unique. Pour les flux asynchrones et basés sur des messages, assurez-vous que les SDK capturent et transmettent les ID de corrélation dans les métadonnées des messages ; la plupart des SDK Azure le font par défaut.

Tests de disponibilité et surveillance synthétique

Les tests de disponibilité valident l’accessibilité externe et la réactivité depuis plusieurs zones géographiques. Le test Ping d’URL émet des requêtes HTTP à une fréquence configurée depuis plusieurs emplacements de test et valide les codes de statut, la santé SSL et une correspondance de contenu optionnelle. Utilisez des nouvelles tentatives et plusieurs emplacements pour réduire les faux positifs et configurez des alertes sur les échecs de test pour des notifications exploitables.

Les tests de disponibilité en plusieurs étapes exécutaient historiquement des séquences enregistrées de requêtes HTTP avec des cookies avec état pour vérifier les workflows. Les tests web classiques en plusieurs étapes ont été retirés ; pour les scénarios à requêtes multiples ou authentifiés, implémentez des tests synthétiques en instrumentant votre propre client ou service à l’aide de l’API TrackAvailability (ou des exportateurs OpenTelemetry) pour émettre de l’AvailabilityTelemetry. Cette approche permet une authentification personnalisée, des charges utiles (payloads) et une validation spécifique au domaine tout en conservant des rapports et des alertes centralisés.

La méthode personnalisée TrackAvailability vous donne le contrôle sur :

Le nom du test, l’emplacement d’exécution et les identifiants de séquence pour l’analyse des tendances et la déduplication.
La sémantique de durée et de succès basée sur vos validations, et non uniquement sur le statut HTTP.
Des messages enrichis et des dimensions personnalisées pour des indices sur la cause racine et la corrélation avec la télémétrie du backend.

Combinez les tests de disponibilité avec la télémétrie des dépendances et des requêtes du backend pour différencier rapidement les problèmes de disponibilité des points de terminaison (réseau, DNS, TLS) des défaillances applicatives (exceptions, timeouts) et des pannes en aval (SQL, API externes). Liez les échecs des tests de disponibilité à des groupes d’actions pour piloter les workflows d’incidents.

Données Azure Monitor, KQL et alertes avec les groupes d’actions

Azure Monitor ingère deux principaux types de données : les métriques et les journaux. Les métriques sont des séries temporelles numériques légères avec une ingestion quasi temps réel et un découpage multidimensionnel (par ex., par instance, route d’API). Elles sont idéales pour la détection rapide (CPU, mémoire, taux de requêtes, latence, disponibilité) et prennent en charge une rétention allant jusqu’à 93 jours par défaut. Les journaux sont des enregistrements structurés et interrogeables, stockés dans un espace de travail Log Analytics, et incluent les données d’Application Insights, les journaux de ressources de la plateforme et les journaux personnalisés avec une rétention configurable. Utilisez les Paramètres de diagnostic pour acheminer les métriques de la plateforme et les journaux de ressources vers un espace de travail, un Event Hub ou un compte de stockage pour l’archivage et l’analyse.

Le Kusto Query Language (KQL) est le moteur de l’analyse exploratoire, des tableaux de bord et des alertes de journal. Les modèles principaux incluent :

Requêtes de base : Table | take 10 pour un échantillonnage rapide ; limitez toujours la période avec where TimeGenerated >= ago(…) au début de la requête pour de meilleures performances.
Filtrage et projection : Table | where Column == "Value" | project KeyColumns pour réduire la charge utile et cibler l’analyse.
Agrégation : summarize count() by bin(TimeGenerated, 5m), Dimension pour calculer des taux, des centiles ou des moyennes ; utilisez percentile() et make-series pour les graphiques temporels.
Jointures : join kind=inner ou leftouter sur des clés de corrélation telles que operation_Id pour connecter les Requests avec les Dependencies ou les Exceptions ; pour les jointures inter-ressources, assurez-vous que les deux envoient leurs données au même espace de travail ou activez les requêtes inter-ressources.
Tables utiles : requests, dependencies, exceptions, traces, availabilityResults pour Application Insights ; AzureDiagnostics et AzureActivity pour les journaux de la plateforme ; Perf et Heartbeat pour VM insights.
Meilleures pratiques : ne projetez que les colonnes nécessaires, filtrez tôt, agrégez sur des intervalles raisonnables et évitez les jointures croisées coûteuses sur de grandes fenêtres de temps, sauf si nécessaire.

Les alertes couvrent les métriques et les journaux. Les alertes de métrique évaluent les seuils de métriques en quasi temps réel, prennent en charge les dimensions et la division par dimension, et peuvent utiliser des seuils statiques ou dynamiques (basés sur des lignes de base ML). Elles sont avec état (stateful) et peuvent se déclencher et se résoudre automatiquement en fonction des résultats de l’évaluation, produisant une seule notification lorsque l’état change. Les alertes de journal (requête planifiée) exécutent des requêtes KQL à une cadence définie et se déclenchent en fonction des résultats de la requête (nombre de correspondances ou seuils de mesure). Utilisez les alertes de journal lorsque les conditions dépendent de schémas complexes sur plusieurs tables ou nécessitent une analyse de texte. Les alertes de détection intelligente (Smart detection) et d’anomalie dans Application Insights peuvent mettre en évidence des régressions sans seuils explicites.

Les groupes d’actions (Action groups) définissent des ensembles de réponses réutilisables pour les alertes. Les types de notification incluent l’e-mail, le SMS, les appels vocaux et les notifications push de l’application mobile Azure. Les intégrations incluent :

Webhooks (v1 et v2) avec le Schéma d’alerte commun (Common Alert Schema) pour des charges utiles cohérentes ; définissez des en-têtes personnalisés pour l’authentification et acheminez vers des systèmes de gestion d’incidents (par ex., PagerDuty ou des récepteurs personnalisés).
Azure Functions, Logic Apps et des runbooks Automation pour la correction et l’enrichissement programmatiques ; utilisez Logic Apps pour des transformations et des connecteurs flexibles.
Connecteurs ITSM (par ex., ServiceNow) pour ouvrir des incidents avec des champs mappés. Associez les groupes d’actions à des règles de traitement des alertes pour supprimer les notifications pendant la maintenance, les acheminer par gravité ou appliquer des actions dynamiques. Pour sécuriser les webhooks sortants, restreignez le récepteur aux adresses IP d’Azure ou exigez des signatures/en-têtes et validez les propriétés du Schéma d’alerte commun telles que Essentials.AlertRule et AlertContext.

Modèles ARM pour l’observabilité et le déploiement reproductible

Les modèles Azure Resource Manager (ARM) définissent de manière déclarative les ressources et la configuration de supervision en tant que code. La structure d’un modèle inclut :

$schema et contentVersion pour identifier la version du modèle.
parameters pour les valeurs externalisées (par ex., noms d’espaces de travail, emplacements, références SKU). Utilisez secureString/secureObject pour les secrets.
variables pour les valeurs calculées afin d’éviter la répétition.
resources pour le déploiement déclaratif d’Application Insights, des espaces de travail Log Analytics, des règles d’alerte, des groupes d’actions et des paramètres de diagnostic.
outputs pour émettre des valeurs comme le connectionString d’Application Insights pour les étapes de déploiement en aval.

Utilisez des modèles liés ou imbriqués pour composer des déploiements complexes. Une ressource de déploiement (Microsoft.Resources/deployments) référence un modèle enfant via templateLink (URI externe) ou l’intègre en ligne. Transmettez les objets de paramètres via parameters ou parametersLink, définissez dependsOn pour l’ordonnancement et réutilisez les modules entre les environnements. Exemples d’observabilité par défaut via ARM :

Déployer un espace de travail Log Analytics et définir des sorties workspaceResourceId utilisées par les ressources Application Insights (mode basé sur l’espace de travail).
Créer Application Insights (basé sur l’espace de travail) et sortir son connectionString ; évitez d’exposer les anciennes clés d’instrumentation.
Activer les paramètres de diagnostic sur les ressources (par ex., App Service, Key Vault, Storage) pour diffuser les journaux et les métriques vers l’espace de travail et/ou Event Hub.
Provisionner des alertes de métrique (microsoft.insights/metricAlerts) avec des critères et des dimensions, et des alertes de requête planifiée (microsoft.insights/scheduledQueryRules) avec KQL, en liant les groupes d’actions par leur ID de ressource.
Définir des groupes d’actions (microsoft.insights/actionGroups) avec des destinataires e-mail/SMS et webhook ; paramétrez les adresses et les points de terminaison pour un routage spécifique à l’environnement.

Adoptez des conditions et des boucles de copie pour des déploiements évolutifs (par ex., appliquer des paramètres de diagnostic à un ensemble d’ID de ressource). Utilisez des fonctions ARM telles que resourceId, subscriptionResourceId, reference, concat et guid pour construire des références dynamiques et des noms stables. Maintenez la configuration de la télémétrie cohérente entre les services en centralisant les conventions de nom de rôle et l’échantillonnage dans les paramètres d’application fournis via des ressources de configuration ARM ou App Service.

Scénario de problème pratique

Adobe a besoin d’une observabilité de bout en bout pour un nouveau pipeline de traitement multimédia multirégional basé sur des API Azure App Service et des microservices AKS. Ils exigent une détection rapide des régressions de latence, un suivi distribué à travers les services, des vérifications proactives de la disponibilité pour les points de terminaison publics, et un routage automatisé des incidents vers leur système d’astreinte avec une reproductibilité de type infrastructure-as-code.

Instrumenter les services avec Application Insights en utilisant des chaînes de connexion

Configurer chaque charge de travail App Service et AKS pour utiliser la chaîne de connexion Application Insights plutôt que les anciennes clés, garantissant des points de terminaison d’ingestion corrects et un routage pérenne. Définir les noms de rôle cloud par service pour permettre un filtrage et des cartographies clairs. Choisir l’instrumentation basée sur le SDK dans les API principales pour émettre des événements de domaine et des métriques ; activer l’attachement sans code pour les services auxiliaires afin d’accélérer la couverture. Pourquoi : Les chaînes de connexion permettent une flexibilité des points de terminaison ; les SDK fournissent une télémétrie personnalisée tandis que l’attachement sans code maintient un faible coût d’adoption.

Activer le suivi distribué et le suivi des dépendances

S’assurer que les clients HTTP sortants et les SDK Azure propagent le contexte de trace W3C ; vérifier la continuité de l’operation_Id dans KQL. Pour les flux de messages en arrière-plan (Service Bus), confirmer que la corrélation est injectée et extraite par les SDK ; compléter avec des TelemetryInitializers lorsque des en-têtes personnalisés sont utilisés. Pourquoi : Une propagation cohérente des traces produit une latence de bout en bout et une attribution des défaillances précises à travers les microservices.

Mettre en œuvre des tests de disponibilité et des vérifications synthétiques personnalisées

Configurer des tests de ping d’URL pour les API publiques depuis plusieurs zones géographiques avec une correspondance de contenu sur un point de terminaison de santé léger. Pour les flux authentifiés (acquisition de jeton et soumission de média), implémenter un client synthétique qui appelle le workflow et émet des résultats TrackAvailability avec le lieu d’exécution et des messages détaillés. Pourquoi : Les pings d’URL fournissent une vérification externe rapide ; TrackAvailability prend en charge des flux métier complexes et authentifiés au-delà des pings de base.

Centraliser les données dans un espace de travail Log Analytics et router les journaux de la plateforme

Déployer un espace de travail et configurer les paramètres de diagnostic sur les App Services, les journaux du plan de contrôle AKS, Key Vault et Storage pour diffuser les journaux et les métriques dans l’espace de travail. S’assurer que les ressources Application Insights sont basées sur l’espace de travail pour unifier les requêtes. Pourquoi : Un espace de travail unique permet d’utiliser KQL sur plusieurs services, en joignant les requêtes, les dépendances et les journaux de la plateforme pour une investigation holistique.

Créer des alertes de métrique et de journal avec des groupes d’actions

Définir des alertes de métrique sur les centiles de durée des requêtes et la disponibilité par emplacement avec des seuils dynamiques, en les répartissant par nom de rôle cloud. Ajouter des alertes de requête planifiée qui détectent les pics d’erreurs par nom d’opération et les corrèlent avec les défaillances de dépendances en utilisant une jointure KQL sur l’operation_Id. Pourquoi : Les alertes de métrique fournissent une détection quasi temps réel ; les alertes de journal capturent des modèles complexes non exprimables par de simples seuils.

Intégrer la réponse aux incidents via des groupes d’actions et des webhooks

Configurer un groupe d’actions avec un e-mail pour les propriétaires de service, un SMS pour les responsables d’astreinte, et un webhook sécurisé vers la plateforme d’incidents d’Adobe en utilisant le Common Alert Schema. Ajouter un récepteur Logic App pour enrichir les charges utiles avec des résultats de requêtes KQL récents et des métadonnées de topologie. Pourquoi : Les notifications multicanal réduisent le MTTA ; le webhook et Logic App permettent la création de tickets automatisée et des incidents riches en contexte.

Codifier la supervision avec des modèles ARM

Rédiger des modèles ARM pour déployer l’espace de travail Log Analytics, Application Insights (basé sur l’espace de travail), les paramètres de diagnostic, les alertes de métrique, les alertes de requête planifiée et les groupes d’actions. Paramétrer les noms d’environnement, les régions et les points de contact ; sortir le connectionString d’Application Insights pour la configuration d’application en aval. Utiliser des modèles liés pour les modules appartenant aux équipes (plateforme vs application). Pourquoi : L’Infrastructure-as-Code assure une observabilité cohérente et reproductible entre les environnements de développement, de préproduction et de production, et prend en charge le CI/CD.

Valider avec des tableaux de bord KQL

Construire des tableaux de bord utilisant KQL qui résument la latence par service (résumer les centiles par intervalle et par rôle), les taux d’erreur joints aux cibles de dépendance, et la disponibilité synthétique par emplacement. Intégrer des filtres de plage de temps et un accès au détail des traces et des exceptions. Pourquoi : KQL fournit une analyse flexible et des visualisations exploitables pour l’ingénierie et les opérations.

← Mise en cache · Tous les domaines

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →