13 — Monitoring

Concevoir l'observabilité d'une solution Azure → Azure Monitor (metrics, logs, alertes), Log Analytics, Application Insights et la stratégie de collecte/rétention.

A. Le cerveau du monitoring : Azure Monitor

Azure Monitor c'est l'umbrella qui collecte 2 types de data :

• Metrics (numériques, time-series, near real-time) → stockées dans Azure Monitor Metrics DB
• Logs (texte/JSON structurés) → stockées dans un Log Analytics Workspace (LAW), interrogeable en KQL

Au-dessus, des "Insights" = dashboards préconfigurés pour un type de ressource (App, VM, Container, Network, Cosmos, KV, Storage). Tous écrivent dans le même LAW si bien designé.

                  Azure Monitor (umbrella)
                          │
   ┌──────────────┬───────┴───────┬──────────────┐
   ▼              ▼               ▼              ▼
 Metrics       Logs (LAW)     Activity Log   Diagnostic
 (numeric)     (KQL)          (control plane) Settings
                  │                            (route resource logs)
                  │
        ┌─────────┴──────────┬──────────────┬─────────────┐
        ▼                    ▼              ▼             ▼
   App Insights         VM Insights   Container Ins.  Network Ins.
   (code app interne)   (OS guest VM) (AKS/ACI logs)  (NSG/topology)

B. Collecte de data : Diagnostic Settings, DCR, AMA

B.1 Les 3 voies pour faire arriver de la data dans LAW

B.2 Diagnostic Settings (pour les ressources Azure)

Sur chaque ressource (KV, SQL, Storage, Front Door, App Gateway…) : Resource > Monitoring > Diagnostic settings > + Add.

3 destinations possibles, multi-sélection OK :

🚨 Diagnostic Settings ≠ Activity Log. Activity Log = control plane (créer/modif/delete), auto-collecté 90j. Pour le router → Diagnostic Setting au niveau subscription.

🚨 Diagnostic Settings — cross-subscription OK : Tu peux envoyer les logs d'une ressource Sub A vers un Log Analytics Workspace dans Sub B (même tenant Entra). Pratique pour centraliser monitoring multi-sub sur un LAW unique. ⚠️ Limite : même région recommandée pour éviter coûts egress + même tenant Entra obligatoire (pas cross-tenant). Pattern ALZ : LAW central dans la sub "Platform-LogAnalytics", toutes les ressources des subs workload pointent dessus.

B.3 DCR (Data Collection Rules) — pierre angulaire AMA

Une DCR dit à l'AMA (agent sur VM) : quoi collecter, comment le transformer, où l'envoyer.

            ┌──────────────┐
   DCR ───▶ │ Azure Monitor│ ─── stocké en sub, associé via DCRA ───▶ AMA on VM
            │   (ARM obj)  │                                              │
            └──────────────┘                                              ▼
                                                               collecte et envoie
                                                   → LAW / Metrics / Custom table

À retenir :

• Une DCR peut être associée à plusieurs VMs ; une VM peut avoir plusieurs DCRs (CPU+Syslog dans une, custom logs dans une autre).
• DCR définit : sources (perf counters, events Windows, Syslog, IIS, custom text/JSON), transformations KQL (filtrer/enrichir avant ingestion = économies), destinations.
• Azure Policy peut forcer l'association DCR à toutes les VMs d'un scope → design at scale.

B.4 DCE (Data Collection Endpoint) — awareness 305

DCE = endpoint d'ingestion vers Azure Monitor. Tu en as besoin si :

• Tu veux Private Link sur l'ingestion (VM dans VNet sans accès public Azure).
• Tu utilises Logs Ingestion API (envoyer custom logs depuis n'importe où via REST).
• Tes VMs sont dans une région où le DCR par défaut ne va pas.

🎯 Au 305 : sache juste que si la question parle d'ingestion sans accès internet / Private Link sur AMA → c'est DCE.

C. Log Analytics Workspace (LAW) — design

C.1 Combien de LAW ?

Le pattern recommandé MS : 1 LAW central (ou 1 par région si compliance data residency). Évite la dispersion qui complique les queries cross-resource.

Quand multiplier les LAW :

• Data sovereignty (UE doit rester en UE)
• RBAC strict (équipe sécurité ne voit pas data dev)
• Sentinel séparé (LAW dédié SIEM, table-level RBAC alternative)

C.2 Retention & Archive

Question typique 305 : "compliance 7 ans, coût mini" → LAW Archive tier (12 ans max, paie ingest + archive très bas).

C.3 Commitment Tiers (cost design)

Au-delà d'un certain volume (100 GB/jour+), souscrire un Commitment Tier réduit le coût ingest jusqu'à 30%. Pour design "high volume" → mentionner.

D. Application Insights (APM)

D.1 C'est quoi

APM dans Azure Monitor. Voit l'app de l'intérieur (code) : requests, dependencies, exceptions, traces, custom events. Vit dans un LAW (workspace-based, le classic est sunset).

D.2 Quand le recommander

• Toute app prod (App Service, Functions, AKS (pas confondre avec le monitor des nods/pods en eux même), custom on-prem/multicloud — juste connection string + HTTPS).
• Besoin distributed tracing (1 requête traverse N microservices, lequel rame ?).
• Besoin Application Map (auto-discovery deps : DB, Storage, externes).
• Availability tests (URL up + content match depuis N régions).

D.3 Comment l'attacher

D.4 Cost & sampling

Apps high-traffic = volume LAW énorme → Adaptive sampling (auto) ou Fixed-rate. (On garde qu'un pourcentage des log, soit par detection automatique, soit c'est nous qui choisissons ce pourcentage manuellement, en générale lié au type d'event) Question 305 : "reduce monitoring cost without losing critical errors" → sampling.

E. VM Insights — guest OS perf monitoring

E.1 C'est quoi

Insight prêt-à-l'emploi qui :

1. Installe AMA sur la VM (On-prem, Cloud via Extension)
2. Crée une DCR prédéfinie (CPU, memory, disk, network counters → table InsightsMetrics)
3. Optionnel : installe Dependency Agent → feature Map (processus + connexions network entre VMs)

E.2 Quand le recommander

• "Monitorer le système d'exploitation guest de mes VMs Azure/Arc/hybrid" → VM Insights.
• "Voir qui parle à qui entre VMs (deps process-level)" → VM Insights Map.
• "Performance counters host-level seulement" → suffit du VM host metric (auto, gratuit, pas besoin VM Insights).

E.3 VM host vs VM guest

F. Container Insights — AKS / ACI

F.1 C'est quoi

Équivalent VM Insights pour AKS / ACI / Arc-K8s. Container AMA (containerized agent) collecte logs/métriques → LAW.

F.2 Architecture moderne (2024+)

MS recommande de séparer logs et metrics :

• Logs (stdout/stderr containers, KubeEvents) → Container Insights → LAW (table ContainerLogV2)
• Metrics → Managed Prometheus (Azure Monitor Workspace) → visu via Azure Managed Grafana
• Control plane logs → Diagnostic Settings → LAW

F.3 Quand le recommander

• "Monitor pods AKS" → Container Insights (logs) + Managed Prometheus (metrics).
• "Custom dashboards K8s standards" → Managed Grafana.
• "App métier dans le pod" → App Insights dans le pod (complémentaire, pas remplacement).

🎯 Question 305 typique : AKS prod, vous voulez metrics Kubernetes standards + dashboards Grafana communauté → Azure Monitor managed service for Prometheus + Azure Managed Grafana, pas seulement Container Insights.

G. Network Watcher

G.1 Les outils Network Watcher (memo et rappel du (7))

G.3 Network Insights

Network Insights = dashboard préconfiguré dans Azure Monitor qui agrège : topologie, NSG flow logs, traffic analytics, alertes. Diagnostic Toolkit dedans = raccourci vers les outils Network Watcher ci-dessus.

H. Workbooks & cross-cutting

Azure Workbooks = canvas Markdown + KQL + paramétres pour bâtir des dashboards composites mixant plusieurs LAW / ressources. Use case 305 : "reporting unifié multi-subscription pour compliance" → Workbook (pas Dashboards classiques).

Différence rapide :

I. Activity Log vs Resource Graph vs Diagnostic Settings

Triple confusion classique au 305 :

🚨 Resource Graph ≠ historique. Pour historique de l'inventaire → exporter periodiquement vers LAW. Activity Log retention longue → Diagnostic Setting au niveau subscription vers LAW (ou export Storage).

J. Routing des logs — design patterns 305

Le sous-objectif officiel "Recommend a solution for routing logs" → savoir choisir la destination selon besoin.

                ┌─ LAW (KQL, alertes, Sentinel)
Resource ─Diag─►├─ Storage (archive long-term, WORM compliance)
                └─ Event Hub (SIEM externe Splunk/QRadar, streaming)

Hybrid case : multi-destinations simultanées OK

🚨 Event Hub doit être MÊME RÉGION que la source. LAW = cross-region OK. Storage = même région recommandée.

K. SQL Audit Logs + Defender for SQL

K.1 SQL Audit (compliance, forensics)

Active sur SQL Server (server-level recommandé) ou SQL DB (db-level, additif). Capture : logins (success/fail), DML (SELECT/INSERT/UPDATE/DELETE), DDL schéma, GRANT/REVOKE, backup.

Destinations (multi-OK) :

K.2 Defender for SQL (sécurité, payant)

• Vulnerability Assessment : scan baseline (recurring weekly)
• Advanced Threat Protection (ATP) : SQL injection, brute force, exfiltration, anomalous access

Active au subscription-level (Defender for Cloud > Environment settings) → couvre toutes DBs présentes + futures.

🎯 Question 305 typique : "compliance HIPAA + détection menaces SQL" → SQL Audit (server-level → LAW + Storage WORM) + Defender for SQL ATP.

L. Decision tree monitoring AZ-305

Par ressource

Custom app code (perf, traces, exceptions)  → Application Insights
Azure VMs (OS guest, processes, deps)       → VM Insights + AMA + DCR
Azure VMs (host CPU/disk)                   → Metrics par défaut (rien à faire)
Azure resources control plane (audit)       → Activity Log (+ diag setting sub vers LAW pour retention)
Azure resources data plane (logs, perf)     → Diagnostic Settings → LAW
Réseau (troubleshoot, flow)                 → Network Watcher (+ VNet Flow Logs + Traffic Analytics)
AKS (logs containers)                       → Container Insights
AKS (métriques K8s/Prometheus)              → Managed Prometheus + Managed Grafana
SQL audit/compliance                        → SQL Audit + Defender for SQL
Inventaire snapshot ("qui a quoi")          → Resource Graph

Par besoin business

"Compliance 7 ans archive logs"             → LAW Archive tier OU Storage immutable WORM
"SIEM externe (Splunk)"                     → Event Hub (même région que source)
"Sentinel comme SIEM"                       → LAW central + connector
"Reporting unifié multi-source/sub"         → Workbooks (Workbook = canvas riche, pas Dashboard)
"App lente, où ?"                           → App Insights Application Map + Performance
"Combien d'users actifs ?"                  → App Insights Custom Events + Funnel
"Trace requête microservices"               → App Insights distributed tracing
"VM connectivité KO, NSG ?"                 → Network Watcher IP Flow Verify
"Monitoring continu latence VM → DB"        → Network Watcher Connection Monitor
"VPN ne fonctionne pas"                     → Network Watcher VPN Troubleshoot
"Quelqu'un attaque ma DB"                   → Defender for SQL (ATP)
"Audit qui a supprimé le RG ?"              → Activity Log (90j) ou archive LAW
"Inventaire toutes VMs sans tag X"          → Resource Graph (Resource Graph Explorer)

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

Scénario 1 : Banque/Assurance — observabilité centralisée multi-subscription (ALZ)

Contexte business : groupe bancaire en Landing Zone, 40+ souscriptions réparties sur 3 management groups. Le SOC et l'équipe Plateforme veulent UNE vue des logs plateforme (Firewall, Bastion, Entra, VNets), sans que chaque équipe app voie les logs des autres. Choix architectural : un workspace de logs (LAW) central dans la souscription Plateforme pour tout ce qui est plateforme, plus un LAW par équipe pour leurs propres ressources. Azure Policy (DINE) force l'envoi automatique des logs plateforme vers le LAW central. Architecture / pattern :

• LAW central = logs plateforme partagés, en mode resource-centric → chaque équipe ne voit, automatiquement, que les logs de ses ressources.
• Envoi des logs entre souscriptions (même tenant Entra) automatisé par Policy DeployIfNotExists.
• Équipes app : leur propre LAW pour leurs apps/PaaS ; peuvent dupliquer certains logs pour leur confort.
• Sentinel sur un LAW sécurité dédié (facturation à part). Trade-offs assumés :
• Gain : gouvernance à grande échelle, droits d'accès propres, vue plateforme unifiée, coût plateforme mutualisé.
• Perte : croiser un log central avec un log d'équipe lors d'un incident est compliqué → prévoir des procédures de triage. Pièges à éviter :
• Ne pas tout mettre dans un seul LAW « fourre-tout » : ça noie les logs et casse la séparation des droits.
• Le partage entre souscriptions ne marche que dans le même tenant Entra ; Event Hub doit rester dans la même région que la source. 📐 Réf. CAF — Management design area / Centralized logging in ALZ : la reference architecture ALZ centralise le logging plateforme dans un LAW de la management subscription, avec resource-centric RBAC pour isoler les logs app ; les équipes workload peuvent router leurs PaaS vers leurs propres LAW. Lien

Scénario 2 : E-commerce — APM et distributed tracing microservices

Contexte business : e-commerce sur App Service + AKS, latence qui fluctue au checkout pendant les pics. L'équipe veut savoir quel microservice ralentit une requête, et garder l'œil sur les erreurs critiques sans faire exploser la facture des logs. Choix architectural : Application Insights workspace-based (instrumentation auto sur App Service, OpenTelemetry sur AKS), traçage de bout en bout + Application Map, et adaptive sampling pour limiter le volume. Architecture / pattern :

• App Insights workspace-based, rattaché au LAW (droits unifiés, accès aux Basic Logs / commitment tiers).
• App Service : instrumentation automatique (sans toucher au code) ; AKS via OpenTelemetry.
• Traçage de bout en bout (operation_Id) + Application Map (découverte auto des dépendances).
• Tests de disponibilité multi-région (alerte si 3 sondes sur 5 échouent).
• Échantillonnage adaptatif côté SDK ; plafond journalier comme garde-fou. Trade-offs assumés :
• Gain : on identifie le microservice fautif, on baisse le coût de télémétrie via l'échantillonnage, et les métriques pré-agrégées restent fiables même échantillonnées.
• Perte : au-delà de ~60 % d'échantillonnage les requêtes de logs perdent en précision ; si les apps n'échantillonnent pas de la même façon, la trace de bout en bout peut avoir des trous. Pièges à éviter :
• App Insights (code de l'app) ≠ Container Insights (logs pods/nodes) : les deux sont complémentaires.
• Le mode Classic est retiré → toujours workspace-based, sinon pas de Basic Logs ni commitment tiers.
• Pré-agréger les custom metrics (sinon on paie double : logs + metrics store). 📐 Réf. WAF — Service guide Application Insights / Cost Optimization : réduire le sample rate pour les flux peu critiques, filtrer la télémétrie non essentielle, utiliser les métriques pré-agrégées et le daily cap ; App Insights est facturé via le LAW sous-jacent. Lien

Scénario 3 : Média/SaaS — FinOps et maîtrise du coût de monitoring high-volume

Contexte business : SaaS qui ingère > 300 GB/jour de logs ; la facture Azure Monitor Logs s'envole. La direction FinOps veut réduire le coût sans perdre les logs opérationnels critiques ni l'audit. Choix architectural : jouer sur tous les leviers de coût des logs — type de facturation (commitment tier vs paiement à l'usage), plan de table (Analytics/Basic/Auxiliary), transformations à l'ingestion (DCR), règles de résumé pour les flux volumineux, et traitement allégé du non-prod. Architecture / pattern :

• Commitment Tier (dès 100 GB/jour) → jusqu'à ~30 % d'économie sur l'ingestion vs paiement à l'usage.
• Tables de debug/audit en Basic Logs (ingestion moins chère, requête payante).
• DCR avec transformations KQL : filtrer/réduire avant l'ingestion = ne payer que l'utile.
• Summary rules sur les flux à fort débit → données agrégées pour le reporting long terme.
• Non-prod : moins de logs collectés, rétention réduite ; Archive pour le froid.
• Workbooks + Workspace Insights pour suivre l'usage et repérer les anomalies de collecte. Trade-offs assumés :
• Gain : baisse directe du coût d'ingestion et de rétention, facturation lisible par workspace.
• Perte : Basic Logs = fonctions limitées (pas d'alertes standard, requêtes payantes) ; les transformations DCR sont à maintenir ; résumer/échantillonner fait perdre le détail brut. Pièges à éviter :
• Descendre la rétention sous 31 j ne baisse PAS le coût (les 31 j sont inclus dans l'ingestion).
• Forwarder Event Hub vers un SIEM externe = même région obligatoire (sinon coût de sortie).
• Mettre les logs Sentinel (facturation à part) dans un LAW distinct des logs opérationnels. 📐 Réf. WAF — Service guide Log Analytics / Cost Optimization : configurer diagnostic settings et DCR pour ne collecter que l'essentiel, choisir le bon billing model (commitment vs PAYG), Basic Logs pour les tables peu requêtées, Summary rules pour le high-volume, et traiter non-prod différemment. Lien

DEMO

Portail — App Insights workspace-based + App Service

Étape 1 — Créer App Insights workspace-based

1. Create a resource > Application Insights
2. Basics :
   • Name appi-myapp-prod
   • Region = même que App Service
   • Resource Mode : Workspace-based (sinon Classic legacy)
3. LAW : sélectionner existant OU Create new (law-monitoring-central)
4. Review + Create

Étape 2 — Lier à l'App Service (auto-instrumentation)

1. App Service > Settings > Application Insights
2. Toggle Application Insights : Enable
3. Change your resource → appi-myapp-prod (créée étape 1) OU Create new
4. Runtime collection level : Recommended
5. Activer Profiler : On + Snapshot Debugger : On
6. Apply → confirmer pop-up restart App Service (~1 min)
7. View Application Insights data

Étape 3 — Vérifier types de logs collectées

1. Générer trafic (ouvrir URL Web App, recharger)
2. App Insights > Investigate :
   • Application Map → graph deps auto-découvert
   • Live Metrics → stream temps réel 1s
   • Failures → exceptions + failed requests
   • Performance → top operations lentes P50/P95/P99
   • Availability → tests Standard
   • Transaction search → operation_Id détaillé
3. Monitoring > Logs → KQL :

   requests | take 10
   dependencies | take 10
   exceptions | take 10
   traces | take 10
   customEvents | take 10
   

SDK manual (Node.js)

const appInsights = require('applicationinsights');
appInsights.setup(process.env.APPLICATIONINSIGHTS_CONNECTION_STRING)
  .setAutoCollectExceptions(true)
  .setAutoCollectDependencies(true)
  .setAutoCollectRequests(true)
  .setSendLiveMetrics(true)
  .start();

// Custom event
appInsights.defaultClient.trackEvent({
  name: 'OrderPlaced',
  properties: { orderId: '123', amount: 99.99 }
});

// Custom metric
appInsights.defaultClient.trackMetric({ name: 'QueueLength', value: 42 });

Availability Test (Standard)

1. App Insights > Investigate > Availability > + Add Standard test
2. Name myapp-health, URL https://myapp.com/health
3. Frequency 5 min, locations 5+ régions (best practice anti false positive)
4. HTTP method GET, SSL validation : ON (alerte X jours avant expiration)
5. Content match "status":"ok"
6. Alerts : severity, action group, failed if 3/5 locations échouent
7. Create

Portail — SQL Auditing

2 niveaux : Server-level (toutes DBs du serveur) OU Database-level (DB spécifique, additif).

Server-level (recommandé)

1. SQL Server > Security > Auditing
2. Toggle Enable Azure SQL Auditing : On
3. Cocher destinations (multi-select OK) :
   • Storage : Storage Account + Storage authentication : Managed Identity + Retention Days (ex 365 / 2555)
   • Log Analytics : LAW (région différente OK)
   • Event Hub : namespace + Event Hub instance (🚨 même région que DB)
4. Save

Database-level (alternative ou additif)

1. SQL Database > Security > Auditing
2. Toggle Enable : On → mêmes options destinations
3. Save

Tester

SQLSecurityAuditEvents
| where TimeGenerated > ago(1h)
| project TimeGenerated, server_principal_name_s, action_name_s, statement_s, succeeded_s
| order by TimeGenerated desc

Portail — Defender for SQL

1. SQL Server > Security section > Defender for Cloud (menu raccourci, page titre = "Microsoft Defender for Cloud")
2. Cliquer Enable Microsoft Defender for SQL (active ATP + VA)
3. Configure :
   • Vulnerability Assessment : Storage Account OU Express configuration (sans storage)
   • Periodic recurring scans : ON (hebdo)
   • Send scan reports to : [email protected]
   • Email admins/sub owners : ON
4. ATP types : laisser All (SQL injection, anomalous, brute force, exfil)
5. Save
6. Vérifier : Microsoft Defender for Cloud > Security alerts

Subscription-level (couvre toutes DBs futures) : Defender for Cloud > Environment settings > <sub> > Defender plans > Databases : ON.