13 — Monitoring (AZ-305)

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.

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

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

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)

M. Pattern monitoring complet AZ-305 (carte récap)

                ┌──────────────────────────────────────────────┐
                │            LAW central (KQL hub)             │
                └──┬────────┬────────┬─────────┬───────────────┘
                   ▲        ▲        ▲         ▲
   App Service ──► AppInsights  Diag       Activity   AMA+DCR
   Functions   ──► AppInsights  Settings    Log         │
   AKS         ──► Container Insights        (sub)      │
                                 │                       │
   Azure SQL ──► Audit ─────────►│                  VM Insights
                Defender for SQL                       (VMs)
                                                       │
   VNet ──► Network Watcher ──► VNet Flow Logs ──────► │
                                Traffic Analytics       │
                                                       ▼
                          Action Groups (email/SMS/Logic App/Func/ITSM)
                          Workbooks (dashboards)
                          Sentinel rules + SOAR automation
                          LAW Archive (12 ans compliance)

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.