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. 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).

I. 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).

J. DDoS Protection (rappel)

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

🏢 Scénarios d'entreprise (CAF/WAF)

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

Contexte business : un éditeur SaaS RH (50 gros clients, 200 microservices sur AKS + App Services) a une équipe SRE de 6 personnes responsable de l'uptime. Il veut un seul écran de supervision, pouvoir corréler les incidents entre services, et router chaque alerte vers la bonne équipe d'astreinte. Choix architectural : un seul Log Analytics (LAW) central (région primaire) + AMA + DCR sur les VMs/AKS + Diagnostic Settings déployés partout via Policy DINE + des Action Groups par équipe + des Workbooks par produit. Architecture / pattern :

• 1 LAW central (law-prod-weu), rétention 90j en accès rapide + archive 2 ans (audit).
• Le tag Tenant=client42 est ajouté comme propriété dans App Insights, ce qui permet de filtrer les logs par client en KQL pour déboguer.
• Une seule DCR (dcr-vm-prod) collecte compteurs perf + Syslog + Event, appliquée à toutes les VMs via Policy DINE.
• L'Activity Log de chaque abonnement est exporté (Diagnostic Settings) vers ce même LAW : un seul endroit pour savoir « qui a fait quoi ».
• Action Groups par équipe (ag-payments, ag-reporting) : email équipe + webhook PagerDuty + Runbook de remédiation auto pour les incidents connus.
• Workbook « Tenant Health » par client (top erreurs, latence p95, requêtes/s). Trade-offs assumés :
• Gain : corrélation des incidents sur un seul écran et alertes routées par équipe.
• Perte : un LAW central concentre le coût d'ingestion et impose un RBAC granulaire pour cloisonner les accès. Pièges à éviter :
• Un LAW par équipe rend impossible de corréler « paiement 5xx → base lente → hôte saturé » entre 3 workspaces. Centraliser tant que le coût le permet.
• Ne pas confondre Activity Log et Diagnostic Settings : l'Activity Log est l'audit des actions de gestion (automatique, 90j) ; les Diagnostic Settings exportent les logs+métriques de chaque ressource vers le LAW. Il faut les deux pour tout voir.
• MMA est déprécié (août 2024) et l'extension Diagnostics Azure part en retraite en mars 2026 : tout nouveau montage uniquement en AMA + DCR.

📐 Réf. CAF/WAF — Centralized logging (Azure landing zone, Management design area) : le pattern d'un Log Analytics workspace central dans la subscription Management est la recommandation CAF pour les opérations de plateforme. En mode resource-centric access control, un même workspace sert l'app logging avec un RBAC granulaire (chaque équipe ne voit que ses logs), ce qui réduit l'overhead. CAF — Centralized logging

Scenario 2 : Healthcare — compliance + alertes service health

Contexte business : une clinique privée a des données de santé (PHI) sur Azure (30 VMs Windows + App Services). Le régulateur exige : prouver qu'un système d'alerte tourne, archiver les logs 7 ans, et être prévenu immédiatement si Microsoft annonce une maintenance touchant West Europe. Choix architectural : LAW + niveau Archive + une alerte Activity Log sur Service Health + des alertes Resource Health par ressource critique + AMA + DCR custom logs pour les apps métier. Architecture / pattern :

• LAW : 90j en accès rapide + archive 7 ans sur les tables critiques (SecurityEvent, AuditLogs). L'archive coûte 10 fois moins cher que l'accès rapide.
• Alerte Service Health (via Activity Log) : catégorie Service Health > Service issue filtrée sur West Europe et les services utilisés (Compute, SQL, Storage) → Action Group email DSI + SMS astreinte.
• Alerte Resource Health par VM critique : se déclenche si l'état passe à Unavailable ou Degraded → Action Group dédié.
• DCR avec Custom logs pour ingérer les logs métier de l'app DICOM (fichiers texte) : nécessite un DCE (Data Collection Endpoint) créé au préalable.
• Diagnostic Settings : tout exporté vers le LAW + un compte de stockage immuable (legal hold) pour l'archive très long terme. Trade-offs assumés :
• Gain : conformité prouvable (alerting actif + archive 7 ans) et notification immédiate des incidents Microsoft.
• Perte : l'archive est peu coûteuse mais lente à interroger (Search Jobs / Restore), et il faut maintenir 2 types d'alertes distincts. Pièges à éviter :
• Ne pas confondre Service Health (côté Microsoft) et Resource Health (côté ta ressource) : il faut les 2 alertes, ce ne sont pas les mêmes événements.
• Des Custom logs sans DCE : l'ingestion ne démarre pas (piège d'examen classique).
• L'archive n'est pas l'accès rapide : interroger l'archive demande des Search Jobs ou un Restore (lent et coûteux). Garder en accès rapide ce qui sert vraiment au quotidien.

📐 Réf. CAF/WAF — Azure Monitor Baseline Alerts (AMBA, Manage / Monitor design area) : CAF recommande de déployer les alertes baseline par policy (metric/activity log/log query) sur les composants de plateforme. Important : les Service Health alerts ne supportent PAS les Alert Processing Rules → les configurer directement avec leur Action Group. Principe de subscription democratization : au moins 1 Action Group par subscription (canal email minimum). CAF — Monitor platform components

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

Contexte business : une néobanque a une app mobile + une API REST sur App Service. Les utilisateurs se plaignent : « le login est lent par moments ». L'équipe a ajouté le SDK App Insights il y a 6 mois mais ne sait pas s'en servir. Choix architectural : Application Insights Profiler + des alertes de métrique + des alertes de log KQL sur les 5xx + Smart Detection (détection ML). Architecture / pattern :

• App Insights branché sur l'App Service via auto-instrumentation (l'Agent, pas le SDK lourd) : il trace les appels à la base et aux API externes.
• Profiler activé : il trace les requêtes web lentes et pointe le coupable (la méthode ValidateToken() à 2,3s p95 sur 8s au total).
• Alerte de métrique : Response time > 3s (moyenne sur 5min) → gravité 2, Action Group ag-mobile-oncall.
• Alerte de log KQL : AppRequests | where ResultCode startswith "5" | summarize count() by bin(TimeGenerated, 5m) | where count_ > 50 → gravité 1, PagerDuty.
• Smart Detection activée (ML intégré à App Insights) : repère les anomalies de latence sans qu'on règle de seuil.
• Workbook « API Health » : top 10 des endpoints lents, échecs de dépendances, exceptions. Trade-offs assumés :
• Gain : la cause des lenteurs est localisée au niveau du code (Profiler) sans recompiler, alerting réactif sur perf et 5xx.
• Perte : l'auto-instrumentation par Agent trace moins finement le métier que le SDK, et le Profiler ajoute un léger overhead. Pièges à éviter :
• Pour tracer des requêtes web lentes → App Insights Profiler, pas Network Watcher (c'est le réseau, pas le code), pas l'Activity Log (c'est de l'audit, pas de la perf).
• Agent vs SDK : l'Agent ne demande aucun changement de code (idéal sur une app existante) ; le SDK exige de recompiler et redéployer (utile pour tracer des événements métier sur-mesure).
• Une alerte sans Action Group ne sert à rien : elle se déclenche mais personne n'est prévenu. Toujours tester l'Action Group avant la prod.

📐 Réf. CAF/WAF — Workload observability (WAF Operational Excellence) : le workload provisionne ses propres ressources de monitoring (App Insights APM + LAW workload) en plus du workspace central plateforme — séparation des responsabilités. WAF recommande Metrics pour l'analyse time-sensitive (détection rapide) et Logs pour l'analyse complexe/reporting, combinés pour le root cause. WAF — Architecture best practices for Log Analytics

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