I due tipi di dati: metriche e log

Azure Monitor è la piattaforma unificata di osservabilità di Azure. La distinzione fondamentale da padroneggiare è tra i due tipi di dati che raccoglie, perché determinano dove finiscono e come li interroghi.

  • Metriche (metrics): valori numerici campionati a intervalli regolari, near-real-time, ottimizzati per alert veloci e grafici di andamento (es. Percentage CPU di una VM, Transactions di uno storage account). Risiedono in un time-series database dedicato con retention fissa a 93 giorni e si interrogano con Metrics Explorer.
  • Log (logs): record strutturati con timestamp ed eventi eterogenei (audit, errori, richieste applicative). Vengono ingeriti in un Log Analytics workspace e si interrogano in KQL (Kusto Query Language). Non sono real-time come le metriche, ma sono molto più ricchi e correlabili tra risorse.

Il Log Analytics workspace

Il Log Analytics workspace è il contenitore-destinazione di tutti i dati di tipo log. Qui atterrano platform log, custom log e i dati di Application Insights (che oggi è basato su workspace). Scelte architetturali tipiche da esame:

  • Centralizzare vs segmentare: un numero ridotto di workspace semplifica query cross-resource e correlazione; workspace separati servono per data sovereignty (region diverse), separazione dei costi per team, o RBAC granulare.
  • La region del workspace conta: i dati risiedono lì e alcuni scenari richiedono che risorsa e workspace siano co-locati.

Diagnostic settings: instradare platform log e metriche

Le risorse Azure emettono resource log (i log specifici del piano dati, es. le richieste su un Key Vault) e platform metric, ma non li inviano da nessuna parte finché non crei una diagnostic setting. La diagnostic setting è la configurazione che instrada questi dati verso una o più destinazioni:

  • Log Analytics workspace — per interrogazione KQL, alert e correlazione.
  • Azure Storage account — archiviazione a basso costo/long-term e compliance.
  • Event Hub — streaming verso SIEM esterni o pipeline di terze parti.

Ogni risorsa può avere più diagnostic setting; puoi selezionare quali categorie di log e quali metriche esportare.

Activity log

L’Activity log è distinto dai resource log: è il registro a livello di control plane della subscription (chi ha creato, modificato o cancellato risorse, eventi di service health, operazioni di autoscale). È retention di 90 giorni di default. Per conservarlo più a lungo o correlarlo con i resource log lo si instrada — anch’esso via diagnostic setting — verso un Log Analytics workspace.

Application Insights

Application Insights è la componente di APM (Application Performance Monitoring) di Azure Monitor per il lato applicativo: request rate, dipendenze, eccezioni, availability test, mappa delle dipendenze e distributed tracing. In modalità workspace-based scrive nello stesso Log Analytics workspace, così puoi correlare telemetria applicativa e log di piattaforma in un’unica query KQL.

Retention e costo

Nel workspace, retention e costo dipendono dal volume di dati ingeriti (data ingestion), non dal numero di risorse monitorate:

  • Il billing è principalmente per GB ingeriti (con pricing tier / commitment tier a scaglioni per grandi volumi).
  • La retention interattiva è configurabile (default tipico 30 giorni, estendibile); oltre questa soglia i dati passano ad Archive a costo ridotto ma con accesso differito.
  • Per contenere i costi si limitano le categorie di log realmente utili, si usano le Basic/Auxiliary logs table plan per dati verbosi a basso valore d’analisi, e si separano i dati costosi in workspace dedicati.

Trappole tipiche d’esame

  • Scenario: i resource log di un Key Vault non compaiono in Log Analytics anche se la risorsa è in esecuzione → Risposta: manca la diagnostic setting; senza di essa i resource log non vengono raccolti (le metriche di piattaforma sì, ma i log no).
  • Scenario: serve conservare l’Activity log per 1 anno per audit → Risposta: crea una diagnostic setting dell’Activity log verso un Log Analytics workspace (o Storage per archivio economico); i 90 giorni di default non bastano.
  • Scenario: alert immediato sulla CPU della VM con la minima latenza → Risposta: usa un metric alert sulle metriche near-real-time, non una query KQL sui log (i log hanno latenza di ingestion maggiore).
  • Scenario: i costi di monitoring crescono a dismisura → Risposta: la spesa dipende dal volume ingerito nel workspace; riduci categorie di log, adotta il table plan Basic/Auxiliary o commitment tier, non ridurre semplicemente il numero di risorse.
  • Scenario: correlare eccezioni applicative con i platform log in un’unica query → Risposta: usa Application Insights workspace-based che condivide il Log Analytics workspace, così KQL interroga entrambi.