13 — Monitoring

Suite Azure Monitor : collecter, analyser, alerter sur les metrics, logs, events des ressources Azure (et hybrides via Arc).

A. Azure Monitor — vue d'ensemble

3 piliers de données :

Sources de données

• Resource metrics/logs : auto pour ressources Azure → activer via Diagnostic Settings
• Guest OS (VMs) : via Azure Monitor Agent (AMA) → DCRs
• Activity Log : auto par sub
• Custom metrics/logs : via SDK/REST API
• Application Insights : pour apps (telemetry app-side)

B. Metrics

• Numériques, échantillonnés à 1 minute par défaut.
• Auto-collectées (pas de config nécessaire pour les ressources Azure).
• Rétention : 93 jours (gratuit).
• Metrics Explorer : visualisation interactive (chart, scatter plot, etc.).
• Multi-resource : agréger sur plusieurs ressources d'un même type.
• Splitting : décomposer une metric par dimension (ex: CPU par VM).

Custom metrics

• Jusqu'à 50 dimensions par metric.
• Envoi via API REST ou AMA.

C. Logs & Log Analytics

Log Analytics Workspace (LAW)

• Container régional pour stocker les logs.
• Pricing : Pay-as-you-go (par GB ingéré + retention) ou Commitment Tiers (engagement volume).
• Retention : 30j gratuit, jusqu'à 730 jours (2 ans), avec Archive (jusqu'à 12 ans) à coût réduit.
• 1+ workspaces par tenant. Choix : centralisé (1 LAW global) vs décentralisé (1 par BU/region) — trade-off coût/gouvernance.

Tables principales

KQL (Kusto Query Language)

Langage de requête sur les logs.

// Top 10 VMs avec le plus haut CPU
Perf
| where ObjectName == "Processor" and CounterName == "% Processor Time"
| where TimeGenerated > ago(1h)
| summarize avg(CounterValue) by Computer
| top 10 by avg_CounterValue desc

// Erreurs 5xx sur App Service
AppServiceHTTPLogs
| where ScStatus >= 500
| summarize count() by CsHost, bin(TimeGenerated, 5m)

Pour AZ-104 : connaître le concept de table + opérateurs basiques (where, summarize, project, top, join). Pas de KQL avancé attendu.

Search query — syntaxe à connaître (piège exam)

→ Pour "trouver error dans la table EventLogs" → search in (EventLogs) "error" (avec in (table) pour limiter le scope, plus efficient que search "error" sans scope).

D. Activity Log

Audit log plane management : "qui a fait quoi" sur les ressources Azure.

Catégories

• Administrative : create/update/delete ressource
• Service Health : incidents Azure, maintenance planifiée
• Resource Health : santé d'une ressource
• Alert : déclenchements d'alertes
• Autoscale : actions auto-scale
• Security : alertes Defender
• Recommendation : Advisor
• Policy : compliance Policy

Caractéristiques

• 90 jours gratuits, dans le portail.
• Pour conserver plus longtemps : exporter via Diagnostic Settings vers :
  • Log Analytics (KQL queries, alerts)
  • Storage Account (long-term archive)
  • Event Hub (streaming vers SIEM externe)

E. Diagnostic Settings

Configuration par ressource (ou via Azure Policy à grande échelle) pour exporter ses logs + metrics vers une destination.

Destinations

• Log Analytics workspace (recommandé pour analyse)
• Storage Account (archive long-terme)
• Event Hub (streaming SIEM)
• Partner solutions (Datadog, etc.)

À retenir

• Pas activé par défaut sur la plupart des ressources.
• 5 diagnostic settings max par ressource.
• Catégories de logs varient par service (ex: Storage = StorageRead/Write/Delete + Transactions).

F. Azure Monitor Agent (AMA) & DCRs

Agent unifié pour collecter logs + metrics du guest OS (VMs Azure et Arc).

🚨 Azure Diagnostics extension dépréciée 31 mars 2026. Log Analytics agent (MMA) retraite août 2024 (déjà retiré). → Utiliser AMA uniquement pour toutes nouvelles installations.

Architecture

• AMA installé sur la VM (extension Azure ou Arc).
• Data Collection Rules (DCR) définissent quoi collecter, où envoyer.
• 1 VM peut avoir N DCRs assignées.

DCR — composants

• Data sources : Performance counters Windows/Linux, Event log, Syslog, Custom logs (text files).
• Streams : transformations (KQL light) avant ingestion → réduire le coût.
• Destinations : LAW, Azure Monitor Metrics, Event Hubs.

Déploiement à grande échelle

• Azure Policy : assigner AMA + DCRs sur toutes les VMs (effect DINE).
• DCR Association : crée le lien VM ↔ DCR.

Data Collection Endpoint (DCE)

Endpoint réseau (public ou Private Endpoint) qui reçoit les données de l'AMA avant ingestion dans LAW. Optionnel pour les data sources standard, requis pour :

• Custom logs (text/JSON files via DCR — sans DCE l'ingestion custom log refuse de démarrer).
• AMPLS (Azure Monitor Private Link Scope) — trafic Monitor via Private Endpoint.
• Logs ingestion API custom.

Référencé dans la DCR via le champ dataCollectionEndpointId. 1 DCE peut servir N DCRs (même region).

💡 Piège exam : "données AMA collectées via endpoint dédié pour compliance" → 1ère étape = créer le DCE, puis le référencer dans la DCR. Ne pas confondre avec AMPLS (qui sécurise tout Azure Monitor, scope plus large) ou VM Insights (focus perf, pas collecte custom).

G. Alerts

Surveillent les conditions et déclenchent des actions.

Types d'alertes

Service Health vs Resource Health (piège classique)

Pour AZ-104 : savoir distinguer les deux. Service Health = problème côté Azure. Resource Health = problème côté ta ressource (peut être causé par le service en panne, ou autre).

États

• Alert state : New → Acknowledged → Closed (manuel)
• Monitor condition : Fired / Resolved (auto, basé sur les conditions)

Severity

• 0 (Critical) → 4 (Verbose)

Action Groups

• Définissent ce qui se passe quand l'alerte fire.
• Actions multiples possibles :
  • Email / SMS / Push (mobile app) / Voice call
  • Webhook (custom endpoint)
  • Azure Function
  • Logic App
  • Automation Runbook
  • Azure Mobile App push notif
  • ITSM (ServiceNow, etc.)
  • Event Hub
• 1 Action Group réutilisable sur N alertes.

Alert Processing Rules

• Règles globales pour modifier le comportement des alertes :
  • Suppress alertes pendant une fenêtre de maintenance
  • Apply Action Groups à plusieurs alertes
• Scope : sub / RG / resource type.

H bis. Métriques Azure Functions / Stream Analytics — niche AZ-104

Si une question porte sur "events Azure Functions ou Stream Analytics en attente / délai" :

→ Pour "trop d'events non traités sur une Azure Function reliée à Event Hub" → Backlogged Input Events. Action : scale out le Function App ou optimiser le code.

Niche : tombe rarement à l'exam réel mais TD le pose.

I. Insights (solutions packagées)

Vues préconfigurées pour types de ressources spécifiques :

Tous nécessitent un Log Analytics workspace (sauf certaines metrics).

Application Insights — Agent vs SDK

🚨 Piège exam : "monitor app perf avec minimal code changes" → Agent (pas SDK).

Application Insights Profiler

Profiling auto des requêtes web d'une app → identifie le hot code path (méthodes les plus lentes), médiane / fastest / slowest response time par endpoint. Activable sur App Service, VM, Cloud Services. Pas d'impact perf significatif.

🚨 Piège exam : "tracer les requêtes web lentes / comprendre la cause d'un délai" → Application Insights Profiler. Pas Network Watcher (réseau ≠ code), pas Activity Log (events plane management), pas "Diagnose and solve problems" (diagnostic générique).

J. Network Watcher

Suite d'outils diagnostic réseau. Activé automatiquement dans chaque region où tu as un VNet.

Outils principaux

NSG Flow Logs ⚠️

• Loggue chaque flux allow/deny par NSG → vers Storage Account, optionnellement enrichi via Traffic Analytics (Log Analytics).
• 🚨 Retraite 30 sept 2027. Création bloquée depuis 30 juin 2025.
• → Migrer vers VNet Flow Logs (capture au niveau VNet, plus complet, recommandé MS).

VNet Flow Logs (successeur)

• Capture tout le trafic d'un VNet (pas juste un NSG).
• Supporte Traffic Analytics (visualisation dans Log Analytics).
• À configurer pour toute nouvelle workload.

Traffic Analytics

• Couche d'analyse au-dessus des Flow Logs (NSG ou VNet).
• Visualise : top talkers, traffic patterns, threats potentielles, geo-distribution.
• Coût : ingestion Log Analytics + processing.

Pré-requis (3 obligatoires) :

1. NSG ou VNet Flow Logs activés (source des données)
2. Log Analytics Workspace (LAW) — destination + analyse via KQL
3. Data Collection Rule (DCR) — définit quoi collecter et où envoyer (modèle moderne via AMA)

Permissions pour activer : Owner, Contributor, ou Network Contributor au scope sub.

💡 Piège exam : pour "enable Traffic Analytics + visualize traffic" il faut 2 actions : (1) Log Analytics workspace + (2) Data Collection Rule. Pas Sentinel (SIEM ≠ traffic), pas Azure Policy (compliance ≠ traffic), pas Monitor Alerts (réactif ≠ analyse).

K. DDoS Protection (rappel)

Recommandé prod : Network Protection sur VNets exposés publiquement (App Gateway, LB public).

DEMO — chemins portail & KQL

Voir les metrics d'une VM

1. VM > Monitoring > Metrics
2. Sélectionner namespace + metric (ex Percentage CPU)
3. Aggregation (Avg, Max, Min, Sum, Count)
4. Time range + granularity
5. Pin to dashboard ou créer alerte

Activity Log — review + archive

1. Monitor > Activity log → filter par catégorie / sub / RG / time
2. Pour archive long-terme : Activity log > Diagnostic settings > Add diagnostic setting
3. Choisir destination : LAW (KQL) + Storage (archive)

Diagnostic Settings (sur une ressource)

1. Resource > Monitoring > Diagnostic settings > Add diagnostic setting
2. Cocher catégories de logs + AllMetrics
3. Destination : LAW / Storage / Event Hub

Log Analytics — query basique

// Heartbeat des VMs (qui ne reportent plus ?)
Heartbeat
| summarize LastHeartbeat=max(TimeGenerated) by Computer
| where LastHeartbeat < ago(15m)

// Activity Log — qui a supprimé des ressources hier ?
AzureActivity
| where TimeGenerated > ago(1d)
| where OperationNameValue endswith "delete"
| project TimeGenerated, Caller, OperationNameValue, ResourceGroup, _ResourceId

Configurer une alerte metric

1. Monitor > Alerts > + Create > Alert rule
2. Scope : choisir la ressource (VM, App Service, etc.)
3. Condition : choisir metric + opérateur (>, <, etc.) + threshold + aggregation
4. Action : sélectionner ou créer un Action Group (email, SMS, webhook, runbook…)
5. Details : nom, severity, description, suppress duplicate alerts (mute pendant X)

Configurer une alerte log

1. Monitor > Alerts > + Create > Alert rule
2. Scope : LAW
3. Condition : Custom log search → écrire la KQL query → seuil (Number of results > 0 par exemple)
4. Frequency d'évaluation (1min, 5min…)
5. Action group + details

Network Watcher — IP Flow Verify

1. Network Watcher > IP flow verify
2. Sélectionner VM source + direction + protocol + IP/port distant
3. Le tool indique : Allow/Deny + quelle règle (NSG) gagne

Network Watcher — Connection Troubleshoot

1. Network Watcher > Connection troubleshoot
2. Source : VM Azure
3. Destination : VM / IP / FQDN + port
4. Run → résultat : path, latency, status

Network Watcher — Connection Monitor (continu)

1. Network Watcher > Connection monitor > Create
2. Test group : sources (VMs/agent on-prem) + destinations + tests (TCP/HTTP/ICMP) + frequency
3. Visualisation continue dans le dashboard, alertes possibles
4. Données dans Log Analytics (table NWConnectionMonitorTestResult)

NSG Flow Logs (legacy, à éviter)

1. Network Watcher > NSG flow logs > Create → choisir NSG + Storage
2. Activer Traffic Analytics : pointer vers un LAW
3. Visualiser dans Network Watcher > Traffic Analytics

VNet Flow Logs (recommandé)

1. Network Watcher > Flow logs > Create > Type: VNet
2. Choisir VNet + Storage Account + retention
3. Activer Traffic Analytics → LAW

Packet Capture

1. Network Watcher > Packet capture > + Add
2. Choisir VM cible
3. Configurer filters (proto, IP, port) + max size + max duration
4. Run → fichier .cap enregistré dans Storage Account
5. Analyser avec Wireshark

Network Diagnostics workflow type

1. IP Flow Verify : "le NSG bloque-t-il ce flux ?" — 30 sec
2. Next Hop : "où va vraiment ce trafic ?" — détecte UDR / peering issues
3. Connection Troubleshoot : test bout-en-bout, voir le path
4. Packet Capture : si rien d'évident → analyse profonde du trafic réel

🏢 Scenarios d'entreprise réels — pensée d'architecte

Comment ces services s'utilisent dans la vraie vie. Pour chaque scenario : contexte business → choix techniques (uniquement les services traités dans la fiche) → pièges typiques.

Scenario 1 : SaaS B2B — observabilité centralisée multi-tenant

Contexte business : éditeur SaaS RH (50 clients enterprise, 200 microservices sur AKS + App Services). SRE team 6 personnes en charge de l'uptime. Besoin : 1 single pane of glass + corrélation cross-service + alertes routées au bon on-call. Choix techniques : LAW unique central (région primary) + AMA + DCRs pour les VMs/AKS + Diagnostic Settings Policy DINE sur tout + Action Groups par squad + Workbooks par produit. Architecture / pattern :

• 1 LAW central (law-prod-weu) — retention 90j hot + Archive 2 ans (audit)
• Tags Tenant=client42 injectés en custom property dans App Insights → KQL filter par tenant pour debug
• DCR unique dcr-vm-prod avec Perf counters + Syslog + Event → assignée via Policy DINE à toutes les VMs
• Activity Log de chaque sub → export Diagnostic Settings → même LAW (un seul endroit pour "qui a fait quoi")
• Action Groups par squad (ag-payments, ag-reporting) : email squad + webhook PagerDuty + Automation Runbook auto-remediation pour incidents connus
• Workbook "Tenant Health" par client (top errors, latency p95, requests/s) Pièges à éviter :
• LAW décentralisée (1 par squad) → impossible de corréler "payment 5xx → DB lent → host saturé" entre 3 workspaces. Centraliser tant que feasible coût.
• Confondre Activity Log et Diagnostic Settings : Activity Log = audit management plane (auto, 90j). Diagnostic Settings = export ressource-par-ressource (logs+metrics du service) vers LAW. Faut les deux pour observabilité complète.
• MMA déprécié (août 2024) + Diagnostics extension Azure retraite mars 2026 → tout nouveau setup uniquement AMA + DCR

Scenario 2 : Healthcare — compliance + alertes service health

Contexte business : clinique privée (PHI sur Azure, 30 VMs Windows + App Services). Régulateur exige : preuve d'alerting opérationnel, archive logs 7 ans, notification immédiate si MS annonce une maintenance impactant West Europe. Choix techniques : LAW + Archive tier + Activity Log alert sur Service Health + Resource Health alerts par ressource critique + AMA + DCR custom logs (apps métier). Architecture / pattern :

• LAW : retention interactive 90j + Archive 7 ans sur tables critiques (SecurityEvent, AuditLogs) — coût Archive = 1/10 du hot
• Service Health alert (Activity Log alert) : catégorie Service Health > Service issue filtré sur West Europe + services utilisés (Compute, SQL, Storage) → Action Group email DSI + SMS astreinte
• Resource Health alert par VM critique : trigger sur état Unavailable ou Degraded → Action Group dédié
• DCR avec Custom logs ingérant les logs métier de l'app DICOM (text files) — nécessite DCE (Data Collection Endpoint) créé en amont
• Diagnostic Settings : tout export vers LAW + Storage Account immuable (legal hold) pour archive très long terme Pièges à éviter :
• Confondre Service Health (côté MS) et Resource Health (côté ta ressource) : faut les 2 alertes, ce ne sont pas les mêmes événements
• Custom logs sans DCE → ingestion refuse de démarrer (piège exam classique)
• Archive ≠ hot : queries sur Archive nécessitent Search Jobs ou Restore (latence, coût) → garder hot ce qui sert vraiment au quotidien

Scenario 3 : Fintech — troubleshooting perf appli + détection latence backend

Contexte business : néobanque, app mobile + API REST sur App Service. Plaintes utilisateurs : "le login est lent par moments". Équipe a ajouté l'App Insights SDK il y a 6 mois mais ne sait pas l'exploiter. Choix techniques : Application Insights Profiler + metric alerts + log alerts KQL sur 5xx + Smart Detection ML. Architecture / pattern :

• App Insights connecté à l'App Service (Agent auto-instrumentation, pas SDK lourd) → trace dépendances DB, externe APIs
• Profiler activé : traces de requêtes web lentes → identifie le hot path (méthode ValidateToken() à 2.3s p95 sur 8s totaux)
• Metric alert : Response time > 3s (avg sur 5min) → Severity 2, Action Group ag-mobile-oncall
• Log alert KQL : AppRequests | where ResultCode startswith "5" | summarize count() by bin(TimeGenerated, 5m) | where count_ > 50 → Sev 1 pageDuty
• Smart Detection activée (ML auto sur App Insights) → détecte anomalies de latence sans seuil manuel
• Workbook "API Health" : top 10 endpoints lents, dependencies failures, exceptions Pièges à éviter :
• "Pour tracer requêtes web lentes" → App Insights Profiler, pas Network Watcher (réseau ≠ code), pas Activity Log (audit ≠ perf)
• Agent vs SDK : Agent = zéro code change, idéal app existante. SDK = nécessite recompile + déploiement (use case : tracker custom events business)
• Alertes sans Action Group = inutile (alerte fire mais personne notifié). Toujours tester l'Action Group avant prod

Scenario 4 : E-commerce — pic Black Friday & autoscale observability

Contexte business : retailer e-commerce, pics x20 trafic sur Black Friday (jusqu'à 50K req/s). VMSS + Azure Functions reliées à Event Hub pour le pipeline commande. Besoin : voir en direct si le scale-out suit la charge, sinon escalade. Choix techniques : Metric alerts multi-resource sur VMSS + Backlogged Input Events sur Functions + Connection Monitor pour latence vers PSP externe + Alert Processing Rules pour suppress maintenance. Architecture / pattern :

• Metric alert VMSS : Percentage CPU > 75% agrégé 5min sur l'ensemble → Action Group qui trigger un Automation Runbook (force scale-out manuel +5 instances en panique)
• Metric alert Backlogged Input Events sur Azure Function func-orders (events Event Hub en attente) > 1000 → indique que la function ne suit pas la cadence → scale plan upgrade
• Connection Monitor (nouveau, pas Classic retiré juillet 2024) : sondage continu de l'API PSP externe depuis Azure → si latence > 500ms ou packet loss → alerte
• Alert Processing Rule : supprime toutes les alertes Sev 3-4 entre J-2 et J+1 du Black Friday (focus sur Sev 0-2 critiques) ; auto-réactive ensuite
• Workbook live "Black Friday War Room" projeté sur écran : req/s, scale events, errors, top slow endpoints Pièges à éviter :
• Backlogged Input Events ≠ Late Input Events ≠ Watermark Delay : pour "events en attente non traités" → Backlogged Input Events uniquement
• Connection Monitor Classic retiré 1er juillet 2024 : si vieux setup tourne dessus → migrer vers Connection Monitor (nouveau) avant l'événement
• Action Group avec trop de canaux (email + SMS + voice + Teams + ITSM) sur Sev 0 = bruit ingérable : 1 canal urgent (SMS/voice) + 1 canal trace (ITSM) suffit

Sources :

• Azure Monitor enterprise architecture
• Multi-tenant monitoring
• Action Groups