Perché il design dell’observability è una scelta architetturale

In AZ-305 il monitoring non è “attaccare qualche alert dopo il deploy”: è una decisione di design che ricade direttamente sul pilastro Operational Excellence dell’Azure Well-Architected Framework. La domanda-chiave d’esame è sempre la stessa: dato questo requisito di visibilità, compliance e budget, quale topologia di telemetria raccomandi? La telemetria si divide in tre segnali — metriche (numeriche, time-series, economiche, retention lunga), log (verbosi, ricchi di contesto, costosi) e traces/distributed tracing (correlazione end-to-end). Un buon design li tratta con retention e costo differenziati, non con un’unica policy indiscriminata.

Topologia dei workspace Log Analytics: centralizzato vs distribuito

Il cuore del design è la scelta del numero e della collocazione dei Log Analytics workspace, il datastore di Azure Monitor.

  • Centralizzato (single workspace): massimizza la correlazione cross-risorsa, semplifica Microsoft Sentinel (che si appoggia a un workspace) e riduce la duplicazione. È la raccomandazione di default quando i requisiti di governance sono uniformi.
  • Distribuito (per team/BU/regione): necessario quando esistono confini di data residency (es. telemetria UE che non può lasciare l’Europa), isolamento RBAC forte tra business unit, o chargeback separato per subscription.

Il criterio decisivo è la combinazione sovranità del dato + modello RBAC + billing. Attenzione al data residency: il workspace ha una region fissa e i log vi risiedono; se un requisito impone che i dati tedeschi restino in Germania, un unico workspace in West Europe non basta. Per l’accesso granulare senza frammentare i workspace, si preferisce il resource-context RBAC (l’utente vede i log delle risorse su cui ha permessi) rispetto al proliferare di workspace, oppure le table-level RBAC per isolare tabelle sensibili.

Ingestione: Azure Monitor e Application Insights

L’ingestione di piattaforma passa da Data Collection Rules (DCR) e Data Collection Endpoints, che sostituiscono i vecchi agent e permettono di filtrare e trasformare alla sorgente — leva primaria per il controllo costi. Per il livello applicativo, Application Insights va progettato in workspace-based mode, così la telemetria APM (richieste, dipendenze, eccezioni, live metrics) confluisce nello stesso Log Analytics e diventa correlabile con i log infrastrutturali. Design tipico: un componente Application Insights per applicazione logica, tutti collegati a un workspace comune. Per gestire l’alto volume si usa il sampling (adaptive o fixed-rate) accettando il trade-off tra fedeltà statistica e costo.

Alert, dashboard e livelli di retention

Una strategia di alerting matura distingue metric alert (bassa latenza, near-real-time, ideali per SLO su CPU/latency/disponibilità) da log alert (query KQL, più flessibili ma con costo e latenza maggiori). Sopra tutto, gli Action Group centralizzano notifica ed escalation. Per la visualizzazione: Azure Workbook per analisi interattiva e report di governance, Azure Dashboard per viste operative sintetiche, e Managed Grafana quando serve un layer cross-cloud o già in uso dai team SRE.

Sul fronte retention e costo, il modello a due livelli è centrale: i dati “caldi” nel workspace (default 30 giorni, estendibili a 730), poi Archive a costo ridotto fino a un massimo pluriennale, interrogabile via search job o restore. Per requisiti di compliance a lunghissimo termine (es. audit trail 7-10 anni) la scelta corretta è esportare verso storage immutabile (Log Analytics data export → Storage/Event Hub), non gonfiare la retention interna. Il commitment tier riduce il costo di ingestion quando i volumi sono prevedibili.

Trappole tipiche d’esame

  • Requisito: correlare log app + infra + security in un SIEM → soluzione: un workspace centralizzato con Microsoft Sentinel e Application Insights workspace-based; evita workspace duplicati che spezzano la correlazione e moltiplicano i costi.
  • Requisito: audit log conservati 7 anni per compliance → soluzione: Archive tier + data export verso Storage immutabile con retention policy, NON impostare 730 giorni di retention “calda” (costoso e comunque insufficiente).
  • Requisito: telemetria UE non deve lasciare l’Europa → soluzione: workspace regionali distribuiti con region europea; un singolo workspace non-UE viola la data residency indipendentemente dai permessi.
  • Requisito: team diversi devono vedere solo i propri log senza frammentare la piattaforma → soluzione: resource-context / table-level RBAC su workspace condiviso, non un workspace per team.
  • Requisito: app ad altissimo traffico che fa esplodere i costi di ingestion → soluzione: adaptive sampling in Application Insights + trasformazioni/filtri nelle DCR alla sorgente, non retention ridotta a valle (che non taglia l’ingestion, il vero cost driver).
  • Requisito: alert a bassa latenza su disponibilità/SLO → soluzione: metric alert con Action Group, riservando i log alert KQL ai casi che richiedono logica di query complessa.