Metriche e log: due telemetrie diverse

In Azure la telemetria di un servizio si divide in due famiglie che rispondono a domande diverse, e all’esame la distinzione è ricorrente.

  • Le metrics sono serie temporali numeriche, campionate a intervalli regolari (tipicamente ogni minuto), leggere e near-real-time. Servono a rispondere a “quanto?” e “quando ha superato la soglia?”: DWU utilizzate da un dedicated SQL pool, percentuale di CPU, code di tempdb, righe caricate. Sono ideali per dashboard e alert reattivi.
  • I logs sono record di eventi discreti, con schema ricco e interrogabili in KQL: ogni pipeline run di Azure Data Factory, ogni activity, ogni Spark job di Azure Databricks, ogni query SQL. Rispondono a “perché è fallito?” e “cosa è successo in quella run specifica?”.

Regola pratica: metriche per rilevare un problema, log per investigarlo.

Diagnostic settings: instradare la telemetria

Un servizio Azure non invia i propri log da nessuna parte finché non crei un diagnostic setting. È il componente che seleziona quali categorie di log e metriche esportare e verso quale destinazione:

  • Log Analytics workspace — obbligatorio se vuoi interrogare con KQL, correlare più servizi e costruire alert basati su log.
  • Storage account — retention economica a lungo termine, archiviazione/compliance, non interrogabile con KQL.
  • Event Hubs — streaming verso SIEM esterni o pipeline di terze parti.

Per ADF le categorie tipiche sono PipelineRuns, ActivityRuns, TriggerRuns; per Synapse dedicated SQL pool SQLRequests, SQLSecurityAuditEvents, ExecRequests; per Databricks i diagnostic logs per categoria (jobs, clusters, notebook). Puoi avere più diagnostic setting sullo stesso servizio con destinazioni diverse (es. Log Analytics per l’analisi + Storage per l’archivio).

Interrogare i log con KQL

Una query KQL parte da una tabella e concatena operatori con la pipe |. Le tabelle rilevanti sono, per esempio, ADFPipelineRun, ADFActivityRun, AzureDiagnostics (o le tabelle resource-specific), DatabricksJobs.

ADFPipelineRun
| where TimeGenerated > ago(24h)
| where Status == "Failed"
| summarize Failures = count() by PipelineName, bin(TimeGenerated, 1h)
| order by Failures desc

Gli operatori da conoscere:

  • where — filtro sulle righe (per tempo, stato, nome risorsa).
  • project / extend — seleziona o aggiunge colonne calcolate.
  • summarize con funzioni di aggregazione (count(), avg(), max(), percentile()) e by per raggruppare.
  • bin(TimeGenerated, 15m) — raggruppa il tempo in intervalli, base di ogni trend.
  • join — correla tabelle, ad esempio pipeline run e activity run per risalire allo step che ha fallito.

Per lo Spark di Databricks tipicamente si aggrega su durata dei job e task falliti; per il dedicated SQL pool si incrociano SQLRequests con le metriche di DWU per capire se un rallentamento è saturazione di risorse o una query mal scritta.

Alert e action group

Un alert rule valuta a intervalli una condizione. Puoi basarla su:

  • una metric (es. DWU used % > 90 per 15 minuti) — bassa latenza, ideale per saturazione;
  • una log query (es. numero di pipeline Failed nell’ultima ora > 0) — più flessibile ma con la latenza di valutazione della query.

Quando l’alert scatta, invoca uno o più action group, che sono l’insieme riutilizzabile di azioni: email/SMS, webhook, Azure Function, Logic App, ITSM, notifica push. Separare la regola (cosa monitorare) dall’action group (chi/come notificare) permette di riusare gli stessi destinatari su più alert.

Trappole tipiche d’esame

  • I log non sono retroattivi. Scenario: una pipeline è fallita ieri notte, ti chiedono come indagare ma il diagnostic setting non era abilitato. Risposta giusta: quei log non esistono; abilita i diagnostic setting prima che servano. Non puoi recuperare telemetria del passato.
  • KQL richiede Log Analytics. Scenario: “vogliamo interrogare i log ADF con query ad-hoc”. Un diagnostic setting verso Storage account o Event Hubs non basta: serve la destinazione Log Analytics workspace.
  • Metrica vs log per l’alert. Per rilevare in near-real-time la saturazione delle DWU scegli un metric alert, non una log query (latenza minore). Per contare pipeline fallite serve una log alert.
  • Distingui metriche e log. “Percentuale di DWU nel tempo” è una metrica; “quale query specifica ha causato il picco” richiede i log. All’esame la risposta sbagliata confonde le due sorgenti.
  • Action group riutilizzabile. Non si configurano i destinatari dentro ogni singola regola: si crea un action group e lo si collega a più alert.