Cos'è OpenTelemetry?

Il problema che risolve

In un'azienda tipica le metriche di sistema, i log applicativi, i log dell'infrastruttura, i dati di sicurezza e le metriche di business finiscono in strumenti diversi, ognuno con il suo agente, il suo formato e il suo protocollo. Quando qualcosa si rompe, correlare un log con la metrica che è salita nello stesso minuto richiede tre console aperte e molta pazienza. Il mercato ha prodotto per anni soluzioni proprietarie e open source che fra loro parlano poco.

OpenTelemetry nasce per risolvere questo problema. Fissa un modello dati comune per i segnali, un protocollo di trasporto, una serie di convenzioni sui nomi e un insieme di componenti software che li applicano. La promessa è scrivere la strumentazione una volta sola e riusarla per qualunque backend di analisi, oggi e fra tre anni. Il sito del progetto riassume la promessa in due principi: i dati che generi sono tuoi, senza vincolo a un fornitore, e c'è un solo insieme di API e convenzioni da adottare.

Cosa fa e cosa non fa

OpenTelemetry genera, raccoglie, elabora e trasmette la telemetria. Si ferma lì. Non archivia i dati, non li interroga, non disegna dashboard e non manda allarmi: queste funzioni restano al backend di observability, che può essere un prodotto commerciale come Datadog o Grafana Cloud, uno strumento open source come Grafana, Elastic o ClickStack, oppure il servizio nativo di un cloud provider.

Questa separazione spiega il sostegno trasversale di cui gode il progetto. Per chi adotta lo standard il vantaggio è evidente: si può cambiare backend senza rifare la strumentazione.

Il rovescio della medaglia c'è. Lo standard nasce dal consenso di decine di aziende e comunità, ed evolve con i tempi di un comitato: le specifiche sono ampie, alcune parti maturano più lentamente di altre, e la complessità non è banale. Chi lo adotta accetta questo compromesso in cambio della neutralità.

Come è fatto

La documentazione ufficiale elenca una decina di componenti: la specifica, il protocollo OTLP, le convenzioni semantiche, le API, gli SDK per i vari linguaggi, le librerie di strumentazione, la strumentazione automatica, il collector e una serie di strumenti di supporto come l'operatore per Kubernetes e gli Helm chart. Per orientarsi conviene ridurli a tre blocchi.

La strumentazione è ciò che produce la telemetria dentro le applicazioni e nell'infrastruttura: le librerie e gli agenti che aprono le trace, contano le richieste, emettono i log. Esistono SDK per tutti i linguaggi di uso comune, da Java a Go, da Python a .NET, da JavaScript a PHP.

Il protocollo, chiamato OTLP, è il formato con cui la telemetria viaggia dall'applicazione al collector e dal collector al backend. È unico per tutti i segnali, lavora in push su gRPC o HTTP, codifica i dati in Protocol Buffers o JSON ed è stateless, quindi scala in orizzontale dietro un load balancer. Un dettaglio che si rivela prezioso in produzione: una destinazione vicina alla saturazione può chiedere alla sorgente di rallentare.

Il collector è l'agente che riceve, elabora ed esporta.

Signals

OpenTelemetry chiama segnali le categorie di telemetria che gestisce. I principali segnali supportati sono: trace, metriche e log.

Due meccanismi tengono insieme segnali diversi. La propagazione del contesto fa sì che un log e uno span prodotti dalla stessa richiesta condividano lo stesso identificativo di trace, anche se arrivano da due servizi diversi: è la base della correlazione, ed è il motivo per cui con OpenTelemetry si passa da un log alla trace che l'ha generato con un clic. Le convenzioni semantiche fissano i nomi degli attributi, da service.name a http.response.status_code, in modo che due team o due linguaggi descrivano la stessa cosa nello stesso formato.

Il collector OpenTelemetry

Il collector è un singolo eseguibile, distribuito anche come immagine container, che fa da intermediario fra chi produce telemetria e chi la analizza. Si configura in YAML dichiarando dei componenti e collegandoli in pipeline, una per segnale.

I receiver ricevono i dati: OTLP dalle applicazioni, ma anche formati preesistenti come Prometheus, syslog, file di log. Ne esistono più di novanta. I processor trasformano i dati in transito: aggiungono metadati, tolgono informazioni sensibili, filtrano, campionano. Gli exporter spediscono il risultato a una o più destinazioni, una cinquantina fra backend commerciali, open source e code di messaggi. A questi si aggiungono i connector, che uniscono due pipeline, e le estensioni per autenticazione, health check e archiviazione locale.

Su Kubernetes l'architettura standard prevede un collector per nodo in DaemonSet, che legge lo standard output dei pod e le metriche del kubelet, e un singolo collector in Deployment per gli eventi di cluster.

Da dove si comincia

Nei progetti di implementazione seguo generalmente questi passi:

1. Raccogliere la telemetria che esiste già. Un collector su ogni macchina virtuale o nodo legge i file di log, le metriche di sistema, gli endpoint Prometheus, i log di Windows. Nessuna modifica alle applicazioni, copertura ampia in poche settimane, e la possibilità di lavorare anche su software di terze parti che nessuno può toccare. Il limite: i log non strutturati vanno interpretati con espressioni regolari, e la correlazione fra segnali è debole o assente.
2. Strumentazione automatica, senza toccare il codice. Gli SDK di .NET, Go, Java, JavaScript, PHP e Python sanno agganciare le librerie più diffuse (server HTTP, client di database, code) e produrre trace e metriche già coerenti con le convenzioni semantiche. Si attiva con una variabile d'ambiente o un modulo caricato all'avvio. Il limite è che si vede solo quello che le librerie strumentate vedono.
3. Strumentazione nel codice. Gli sviluppatori creano le trace, definiscono le proprie metriche e scrivono i log attraverso l'API OpenTelemetry. È il gradino che dà la correlazione piena e il ritorno migliore nel lungo periodo, ed è anche il più costoso perché richiede di modificare le applicazioni.

Questo approccio ha senso per chi ha già applicazioni e infrastruttura in esercizio. Chi parte da zero può saltare i primi due step e strumentare nel codice fin dall'inizio.

Quattro accorgimenti rendono il percorso meno faticoso.

• Dare agli sviluppatori accesso diretto alle console di observability, anche in produzione, cosa che nei contesti con molto legacy è meno scontata di quanto sembri.
• Costruire e mantenere piccoli wrapper interni attorno agli SDK, così che strumentare un nuovo servizio sia una riga di import e non una pagina di codice ripetuto.
• Scrivere adattatori che convertano la telemetria già prodotta dai sistemi esistenti nei nuovi formati.
• Prevedere un periodo in cui il vecchio e il nuovo sistema girano in parallelo.

OpenTelemetry e intelligenza artificiale

L'intersezione di OpenTelemetry con gli LLM è duplice.

• Osservabilità dei sistemi AI. Una chiamata a un agente nasconde una catena di invocazioni al modello, chiamate a strumenti esterni e scambi di token, e senza telemetria non si distingue un modello lento da un agente che ripete lo stesso passo decine di volte. Le convenzioni semantiche per la GenAI di OpenTelemetry estendono OpenTelemetry per supportare l'operatività dei modelli LLM.
• Uso degli agenti a supporto dell'observability. Interrogare i dati, trovare la causa di un incidente, scrivere un report. Qui la qualità del risultato dipende poco dal modello e molto dai dati che ha a disposizione. Telemetria ben strutturata, correlata e interrogabile da un unico database è ciò che permette a un agente di arrivare alla causa in pochi passaggi, come racconto nel post Non apro una dashboard da sei mesi. OpenTelemetry fornisce esattamente quella struttura.

Adozione

Lavoro con OpenTelemetry nei progetti dei clienti da qualche anno, e sono convinto che abbia raggiunto da tempo la maturità per essere la scelta di default per log, metriche e trace. Non è privo di punti di attenzione: la specifica è ampia, la documentazione a tratti lascia a desiderare, ma i vantaggi superano i problemi. Ne ho parlato in due interventi a Container Day: nel 2024 sui log in OpenTelemetry e nel 2025 sulle strategie incrementali di adozione.