Il problema della frammentazione nell’osservabilità
Monitorare un sistema distribuito richiede tre tipi di dati: tracce che seguono una richiesta attraverso i servizi, metriche che misurano il comportamento aggregato e log che registrano eventi puntuali. Fino al 2019, raccogliere questi dati significa scegliere tra strumenti e formati incompatibili. Ogni backend di osservabilità — Jaeger, Zipkin, Prometheus, piattaforme commerciali — richiede la propria libreria di instrumentazione. Cambiare backend significa riscrivere il codice di raccolta. Il risultato è un vendor lock-in tecnico che vincola le scelte infrastrutturali per anni.
Due progetti open source affrontano il problema da angolazioni diverse: OpenTracing, incubato dalla CNCF, definisce API standard per il tracing distribuito; OpenCensus, nato in Google, fornisce librerie per tracce e metriche con esportazione verso più backend. Entrambi guadagnano adozione, ma la coesistenza di due standard parziali crea ulteriore frammentazione.
La fusione in OpenTelemetry
Nel maggio 2019 i due progetti annunciano la fusione in OpenTelemetry, un progetto unico sotto l’ombrello della Cloud Native Computing Foundation. L’obiettivo è definire uno standard aperto per la raccolta di dati di osservabilità che sia indipendente dal backend, dal linguaggio e dalla piattaforma.
Il principio fondamentale è: instrumentare una volta, esportare ovunque. Un’applicazione instrumentata con OpenTelemetry può inviare i propri dati a qualsiasi backend compatibile senza modifiche al codice.
Architettura: SDK, Collector e OTLP
L’architettura di OpenTelemetry si articola su tre livelli. Gli SDK multi-linguaggio — disponibili per Java, Python, Go, JavaScript, .NET, C++, Rust e altri — forniscono API per creare span (unità di lavoro nel tracing), registrare metriche e emettere log. L’instrumentazione può essere manuale o automatica, con librerie che intercettano framework e client HTTP senza modifiche al codice applicativo.
Il Collector è un componente indipendente che riceve, elabora e inoltra i dati di telemetria. Funziona come intermediario configurabile: può filtrare, arricchire, aggregare e instradare i dati verso uno o più backend. L’architettura a pipeline — receiver, processor, exporter — rende il Collector estensibile tramite plugin.
Il protocollo di trasporto è OTLP (OpenTelemetry Protocol), progettato per trasmettere tracce, metriche e log con un formato unificato su gRPC o HTTP. OTLP è il contratto tra SDK e Collector, e tra Collector e backend.
Osservabilità come infrastruttura
OpenTelemetry trasforma l’osservabilità da scelta di prodotto a infrastruttura standard. Le organizzazioni possono adottare un’unica libreria di instrumentazione sapendo che i dati raccolti saranno compatibili con qualsiasi piattaforma di analisi, oggi e in futuro. Per i sistemi distribuiti, dove comprendere il comportamento attraverso decine di servizi è una necessità operativa, uno standard aperto riduce il costo di adozione e elimina il vincolo verso un singolo fornitore.
Link: opentelemetry.io