Cos’è la telemetria in Application Insights

Application Insights è il componente di Azure Monitor dedicato all’Application Performance Monitoring (APM). Raccoglie telemetria dall’applicazione e la invia a un Log Analytics workspace, dove diventa interrogabile con KQL e visualizzabile in Application Map, Live Metrics e Transaction Search. Per l’esame è essenziale distinguere i tipi di telemetria:

  • Requests: chiamate HTTP in ingresso servite dall’app (con durata, esito, codice di risposta).
  • Dependencies: chiamate in uscita verso SQL, HTTP, Storage, Service Bus, ecc.
  • Exceptions: eccezioni non gestite e tracciate esplicitamente.
  • Traces: messaggi di log (integrati con ILogger).
  • Custom events e custom metrics: segnali di dominio applicativo definiti dallo sviluppatore.
  • Performance counters / metriche di sistema e page views (lato browser).

Auto-instrumentation vs strumentazione via SDK

La auto-instrumentation (codeless) attiva la raccolta senza toccare il codice: si abilita dal portale per App Service, Azure Functions, AKS e VM. Cattura automaticamente requests, dependencies ed exceptions. È la scelta giusta quando non puoi ricompilare o vuoi coprire rapidamente un servizio esistente, ma non genera custom event o custom metric.

La strumentazione via SDK dà controllo fine. Nel 2026 l’approccio raccomandato è l’Azure Monitor OpenTelemetry Distro (Azure.Monitor.OpenTelemetry.AspNetCore), che standardizza traces, metrics e logs su OpenTelemetry con propagazione W3C Trace Context predefinita. In alternativa resta valido il classico TelemetryClient dell’Application Insights SDK per invii espliciti:

telemetryClient.TrackEvent("CheckoutCompleted",
    properties: new() { ["tier"] = "premium" });
telemetryClient.TrackMetric("CartItems", itemCount);
  • TrackEvent → custom event per azioni di business (usa properties per dimensioni filtrabili).
  • TrackMetric → custom metric aggregata; per volumi elevati preferisci GetMetric() che pre-aggrega lato client.
  • TrackException / TrackDependency / TrackTrace completano i segnali manuali.

Scelta architetturale tipica: auto-instrumentation per la copertura di base + SDK/OpenTelemetry per gli eventi di dominio che l’auto-instrumentation non conosce.

Sampling: controllare volume e costo

Il sampling riduce il numero di item inviati e quindi il costo di ingestione, mantenendo la statistica rappresentativa. Le modalità principali:

  • Adaptive sampling (default nell’SDK ASP.NET Core): regola dinamicamente la percentuale per centrare un target di item/secondo.
  • Fixed-rate sampling: percentuale fissa, coordinata tra client e server così che le operazioni correlate restino coerenti.
  • Ingestion sampling: applicato all’endpoint, come ultima difesa se l’SDK non campiona.

Punto chiave: il sampling scarta intere operazioni correlate (una request con le sue dependencies), non singoli item, così le transazioni restano leggibili. Ogni item conserva un campo itemCount che consente ad Application Insights di ricostruire i conteggi reali nelle metriche pre-aggregate. Le query log-based su tabelle grezze, invece, vedono solo i record sopravvissuti: qui i conteggi vanno moltiplicati per itemCount, altrimenti risultano sottostimati.

Distributed tracing e correlazione

In architetture a microservizi un’unica operazione utente attraversa più servizi. Application Insights li lega tramite l’operation ID: operation_Id identifica l’intera operazione end-to-end, mentre operation_ParentId costruisce la gerarchia padre-figlio tra request e dependency. La propagazione avviene con l’header traceparent dello standard W3C Trace Context.

Con l’Azure Monitor OpenTelemetry Distro o gli SDK recenti la propagazione è automatica sulle chiamate HTTP strumentate. Diventa manuale quando il contesto attraversa canali non HTTP (es. messaggi su Service Bus o Event Hubs): occorre inserire traceparent nelle proprietà del messaggio e ripristinarlo lato consumer, altrimenti la catena si spezza e l’Application Map mostra servizi scollegati.

Trappole tipiche d’esame

  • Servono custom business event ma è attiva solo l’auto-instrumentation → aggiungi lo SDK/OpenTelemetry con TrackEvent/TrackMetric: la modalità codeless non emette telemetria custom.
  • Dopo aver abilitato il sampling i conteggi in una query KQL crollano → moltiplica per itemCount (o usa le metriche pre-aggregate): il sampling scarta operazioni intere, non falsa le metriche corrette da itemCount.
  • Le transazioni non si correlano tra due microservizi collegati via Service Bus → propaga manualmente il traceparent (W3C Trace Context) nelle proprietà del messaggio: la correlazione automatica copre solo HTTP strumentato.
  • Serve ridurre i costi di ingestione mantenendo le transazioni leggibili → usa adaptive o fixed-rate sampling nell’SDK, non filtri arbitrari che spezzerebbero le operazioni correlate.
  • Custom metric ad altissima frequenza gonfia volume e costo → usa GetMetric() che pre-aggrega lato client, invece di molte TrackMetric non aggregate.