Log vs metriche: due modelli di dati, due strumenti

In Application Insights (parte di Azure Monitor) la telemetria vive in due mondi complementari. Capire quale usare è metà del lavoro di observability.

  • Le metriche sono valori numerici aggregati e campionati a intervalli fissi (di solito 1 minuto), ottimizzati per essere near-real-time e a costo di query bassissimo. Esempi: Server response time, Failed requests, Availability. Ideali per dashboard sempre accesi e per alerting reattivo.
  • I log conservano il dettaglio per singolo evento: ogni richiesta HTTP, ogni chiamata a dipendenza, ogni eccezione è una riga con decine di campi. Li interroghi con KQL (Kusto Query Language). Servono quando devi rispondere a “quale utente, quale URL, quale stack trace”.

La regola pratica per l’esame: metrica per il “quanto/quando”, log per il “chi/cosa/perché”.

KQL: interrogare i log

Le tabelle principali che AZ-204 si aspetta tu conosca:

  • requests — richieste HTTP in ingresso (nome, resultCode, duration, success).
  • dependencies — chiamate in uscita (SQL, HTTP, Storage, Service Bus): target, type, duration.
  • exceptions — eccezioni con tipo e stack trace.
  • traces — log applicativi emessi via ILogger/TrackTrace, con severityLevel.
  • customEvents / customMetrics — telemetria custom da TrackEvent/TrackMetric.

Gli operatori fondamentali:

  • where — filtra le righe. Metti sempre per primo un filtro temporale (where timestamp > ago(1h)): è ciò che limita il volume scansionato.
  • summarize — aggrega (count(), avg(), percentile()) opzionalmente by una dimensione.
  • project / project-away — seleziona/scarta colonne per ridurre il payload.
  • extend — aggiunge colonne calcolate; render per il grafico.

Esempio: top 10 dipendenze più lente nell’ultima ora.

dependencies
| where timestamp > ago(1h)
| where success == false
| summarize p95=percentile(duration,95), calls=count() by target, type
| top 10 by p95 desc

L’ordine conta: filtrare prima di aggregare riduce drasticamente il costo. Una query senza where timestamp scansiona l’intera retention (fino a 90+ giorni) e può timeoutare o generare costi elevati su un workspace Log Analytics.

Strumenti diagnostici

  • Application Map: visualizza automaticamente la topologia dell’app e delle sue dipendenze, con latenze e tassi di errore su ogni arco. Perfetto per localizzare quale componente sta degradando in un’architettura distribuita.
  • Live Metrics: stream a latenza di secondi, non campionato, utile durante un deploy o un incidente per vedere l’effetto in tempo reale. Non è persistito: è “guarda ora”, non “analizza dopo”.
  • Transaction search / End-to-end transaction: segue un singolo operation_Id attraverso requests → dependencies → exceptions correlate. È il modo per ricostruire il percorso di una richiesta fallita.
  • Failures / Performance blades: viste pre-costruite sopra le stesse tabelle KQL.

Alerting

Due famiglie di alert, da scegliere in base alla fonte:

  • Metric alert: valuta una metrica contro una soglia (statica o dynamic threshold che apprende il baseline). Bassa latenza, costo minimo, ideale per “CPU > 80%” o “failed requests > 50 in 5 min”.
  • Log search alert (log query alert): esegue una query KQL a intervalli e scatta se il risultato supera una soglia. Necessario quando la condizione dipende dal dettaglio (es. “più di 10 eccezioni di tipo SqlException da uno specifico endpoint”).

Entrambi si collegano a un Action Group (email, SMS, webhook, Azure Function, Logic App, ITSM) che definisce cosa succede allo scatto. Scegli il metric alert quando basta un numero aggregato; passa al log alert solo quando serve interrogare i campi dei singoli eventi.

Trappole tipiche d’esame

  • Scenario: serve sapere quali URL restituiscono 500 e con quale eccezione → risposta: usa un log alert / query KQL su requests+exceptions, non una metrica (le metriche aggregano e perdono il dettaglio).
  • Scenario: la query KQL è lenta o costosa → risposta: aggiungi come primo operatore where timestamp > ago(...) e usa project per ridurre le colonne; filtrare prima di summarize.
  • Scenario: durante un deploy vuoi vedere l’impatto istante per istante → risposta: Live Metrics, non un metric chart (campionato a 1 min né persistito serve qui).
  • Scenario: individuare quale dipendenza rallenta un’architettura a microservizi → risposta: Application Map, non una singola query manuale.
  • Scenario: alert semplice “response time medio alto” con minima latenza e costo → risposta: metric alert (eventualmente dynamic threshold), non un log alert che sarebbe overkill.