Observability e OpenTelemetry

Cos'è l'observability, e perché OpenTelemetry

Observability vuol dire riuscire a capire cosa succede nei propri sistemi partendo dai dati che producono: log, metriche e trace. Quando qualcosa si rompe, permette di risalire alla causa invece di andare per tentativi. Quando tutto fila liscio, dice dove finiscono tempo e risorse.

Per anni ogni strumento ha avuto i suoi agenti e i suoi formati, e il risultato è stato legare le aziende a un fornitore e moltiplicare i costi. OpenTelemetry ha cambiato le cose: oggi è lo standard de facto per raccogliere i dati, ed è il punto da cui parto in ogni infrastruttura di observability che progetto.

Cos'è OpenTelemetry

OpenTelemetry (OTel) è un framework per raccogliere log, metriche, trace e altri segnali. Mette insieme una serie di SDK, delle convenzioni semantiche, un protocollo (OTLP) e un agente, l'OpenTelemetry Collector, che in sostanza è una pipeline modulare per elaborare i dati e instradarli dove servono.

OpenTelemetry non è un backend, un database o uno strumento di visualizzazione: i dati si mandano a Elastic, Grafana, ClickHouse, Datadog o a quello che si adatta meglio allo stack. L'obiettivo è eliminare il vendor lock-in e uniformare il modo in cui la telemetria viene raccolta e trasportata. La promessa più concreta è questa: poter cambiare database o console di observability senza rifare l'instrumentazione.

Perché adottarlo, e con quali cautele

I punti di forza sono la neutralità rispetto ai vendor, un'instrumentazione unica per tutto e la libertà di cambiare backend. In un progetto enterprise ho sostituito una soluzione di observability proprietaria con una piattaforma open source basata su OpenTelemetry, distribuita tra datacenter di proprietà e cloud provider: i costi di licenza sono andati a zero e log e metriche si gestiscono ora in modo uniforme.

Ci sono anche limiti che è bene conoscere: una complessità non banale, un'evoluzione decisa da comitati, una maturità che cambia da componente a componente. Le distribuzioni di terze parti, poi, semplificano l'integrazione ma a volte portano con sé peso in più e una spinta verso un vendor, cioè il contrario di quella neutralità per cui si sceglie OTel. Ecco perché l'adozione va pianificata.

Adozione incrementale

Nei progetti reali, l'approccio che ho visto funzionare procede per gradi:

1. L'infrastruttura di raccolta. Collector configurati come codice, resilienti (code di invio persistenti su disco, retry, batching) e a loro volta monitorati.
2. La telemetria che c'è già. Log e metriche di macchine virtuali e cluster Kubernetes, raccolti senza toccare le applicazioni: valore immediato, rischio minimo.
3. Instrumentazione senza codice. L'auto-instrumentazione aggiunge trace e metriche applicative senza che nessuno debba modificare il codice.
4. Instrumentazione nel codice. Dove serve più dettaglio, gli SDK entrano direttamente nelle applicazioni.
5. Favorire l'adozione. Documentazione, convenzioni e affiancamento ai team, perché lo strumento venga usato davvero.

Ne ho parlato al containerday 2025 nel talk Strategie incrementali per l'adozione di OpenTelemetry e nell mio blog: OpenTelemetry Incremental Adoption Strategies.

Backend e alerting con Prometheus e Alertmanager

Come backend, oggi il mio punto di partenza è ClickStack: tiene log, metriche e trace in un unico database, ClickHouse, senza dover integrare tre prodotti diversi con tre linguaggi di query diversi.

OpenTelemetry non si occupa di allarmi, per scelta. Per questa parte uso la classica coppia Prometheus e Alertmanager: il collector invia le metriche a Prometheus, usato come motore di regole, e Alertmanager si occupa di raggruppamento, instradamento e silenziamento degli allarmi. Regole e routing sono al cento per cento Infrastructure as Code.

Observability per persone e agenti AI

Con un agente AI che sa interrogare i dati, l'interfaccia grafica conta sempre meno: quello che conta è che i dati siano organizzati bene, in un database adatto, e che l'agente vi abbia accesso nella sua harness, per esempio tramite un server MCP. A quel punto, quando c'è un problema, l'agente fa le query necessarie e arriva alla causa, spesso più velocemente di un'analisi manuale.

Un'infrastruttura OpenTelemetry ben fatta è la base di questo modo di lavorare.