Componenti e funzionamento di OpenTelemetry

OpenTelemetry è un framework open source progettato per standardizzare la raccolta e la gestione dei dati telemetrici in modo indipendente dal fornitore (vendor-neutral). Nato dalla fusione di OpenTracing e OpenCensus, è ora un progetto incubatore della Cloud Native Computing Foundation (CNCF) e sta diventando rapidamente lo standard de facto per l’observability nel mondo cloud-native.

Il problema che OpenTelemetry risolve è fondamentale: in ambienti distribuiti moderni, comprendere cosa succede nei sistemi è diventato estremamente complesso. Microservizi, container, serverless e architetture multi-cloud hanno frammentato le applicazioni in componenti distribuiti difficili da monitorare con gli approcci tradizionali.

A cosa serve OpenTelemetry?

OpenTelemetry fornisce un insieme di API, SDK, librerie e strumenti standardizzati per:

Instrumentare il codice: aggiungere punti di osservazione nelle applicazioni
Raccogliere dati telemetrici: catturare informazioni sullo stato e sul comportamento del sistema
Esportare questi dati: inviarli a qualsiasi backend di osservabilità

I principali vantaggi di OpenTelemetry includono:

Indipendenza dal vendor: puoi cambiare il tuo backend di monitoring senza modificare l’instrumentazione
Standardizzazione: formato dati e API consistenti in diversi linguaggi e framework
Riduzione del vendor lock-in: libertà di scegliere il miglior strumento per ogni esigenza
Instrumentazione completa: supporto integrato per traces, metriche e log

OpenTelemetry nasce per l’instrumentazione, generazione, collezionamento ed esportazione di dati di telemetria. I dati di telemetria sono chiamati signals e ne fanno parte: tracce, metriche e log. Nelle sezioni successive vedremo nel dettaglio cosa sono e gli altri tipi di signali.

L’architettura a strati

L’architettura di OpenTelemetry è organizzata in tre strati principali, ognuno con responsabilità specifiche:

Architettura a strati di OpenTelemetry

Strato di Instrumentazione

Lo strato più vicino al codice applicativo, responsabile della generazione dei segnali telemetrici. Si divide in:

Instrumentazione Manuale: definita dagli sviluppatori per tracciare punti specifici dell’applicazione
Instrumentazione Automatica: fornita dalle librerie per tracciare automaticamente framework e librerie comuni

Strato API

Definisce le interfacce standard per:

Generazione delle tracce
Raccolta delle metriche
Gestione dei log
Propagazione del contesto

Questo strato rimane stabile nel tempo, fornendo un’interfaccia consistente per gli sviluppatori.

Strato SDK

Il cuore pulsante di OpenTelemetry, responsabile di:

Processing dei segnali
Sampling dei dati
Buffering e batching
Export verso sistemi esterni

Signals

I Signals in OpenTelemetry sono unità fondamentali di telemetria che forniscono informazioni sullo stato e il comportamento del sistema.

Tracce

Le tracce rappresentano il percorso di un’esecuzione attraverso un sistema distribuito. Sono composte da span, unità atomiche di lavoro con un inizio e una fine, che formano una gerarchia parent-child. Ogni span contiene:

Un identificatore unico
Un timestamp di inizio e fine
Attributi che descrivono l’operazione
Eventi che marcano punti significativi
Links ad altri span correlati
Lo stato dell’operazione (success, error, etc.)

Ecco un esempio semplificato di traccia:

Trace ID: 7bf3f854c16a75424fcb1210e929fc4a

[Span] GET /api/orders (245ms)
   |
   +--[Span] Database Query (95ms)
   |
   +--[Span] Call Payment Service (130ms)
        |
        +--[Span] Process Transaction (85ms)

Metriche

Le metriche sono rappresentazioni numeriche di dati misurati in intervalli di tempo. OpenTelemetry supporta diversi tipi:

Counter: valore che può solo aumentare (es. numero di richieste)
Gauge: valore che può aumentare o diminuire (es. memoria utilizzata)
Histogram: distribuzione di valori (es. latenza delle richieste)
UpDownCounter: counter che può sia aumentare che diminuire

Log

I log sono record testuali di eventi che si verificano nel sistema. In OpenTelemetry, i log vengono arricchiti con metadati che li correlano alle tracce e alle metriche, creando un sistema di telemetria completo e integrato.

L’integrazione di log con tracce permette di passare facilmente da una vista aggregata (metriche) all’analisi dettagliata di una singola esecuzione (traccia) fino ai messaggi specifici (log).

Baggage

Il Baggage è documentato in OpenTelemetry insieme ai segnali, ma non è un vero e proprio segnale. Si tratta di un meccanismo per immagazzinare coppie chiave-valore che vengono propagate tra servizi e processi, fornendo contesto aggiuntivo utile per traces, metriche e log.

Per comprendere il funzionamento del Baggage, immaginiamo un esempio: Supponiamo di avere un servizio Ordini e un servizio Magazzino. Nel servizio Ordini, una chiamata API come /orders/{Id} genera un trace con un Parent Span e, se necessario, dei Child Span. Durante questa operazione, il servizio Ordini effettua una chiamata al servizio Magazzino. Se nel servizio Magazzino servono informazioni di contesto per l’osservabilità, come ClientId, OrderId o ClientRegion, queste possono essere trasportate utilizzando il Baggage.

Importante: il Baggage è pensato esclusivamente per dati di telemetria legati all’osservabilità. Non deve mai essere usato per trasportare dati critici o necessari alla logica di business.

Sicurezza

Quando si aggiungono informazioni al Baggage, queste diventano accessibili a tutti i segnali di telemetria, inclusi quelli inviati a servizi di terze parti. Inoltre, il Baggage viene propagato come header HTTP, rendendolo visibile a chiunque nella rete. Per questo motivo, è fondamentale inserire solo informazioni non sensibili ed applicare policy chiare su quali dati possono essere inclusi nel Baggage.

Profiles

Al momento della scrittura di questo articolo il segnale Profiles è in fase di studio da parte del Profiling Working Group. I profili permetteranno di raccogliere informazioni dettagliate sulle performance a livello di codice.

Architettura del Collector

Un componente chiave nell’ecosistema OpenTelemetry è il Collector, un servizio indipendente che riceve, processa ed esporta dati di telemetria. Il Collector è organizzato in:

Receivers: ricevono dati da varie fonti
- OTLP (OpenTelemetry Protocol)
- Protocolli legacy (Jaeger, Zipkin)
- Altri formati (Prometheus)
Processors: elaborano i dati in transito
- Batch: aggregano dati per efficienza
- Filter: rimuovono dati indesiderati
- Attribute: aggiungono o modificano attributi
Exporters: inviano i dati alle destinazioni
- Backends di observability (Jaeger, Prometheus)
- Cloud providers (AWS, Azure, GCP)
- Storage locali (file, console)

Architettura del Collector Immagine tratta dal sito ufficiale di OpenTelemetry

Il Collector può essere deployato in diverse modalità:

Agent: vicino all’applicazione
Gateway: punto centralizzato di raccolta
Standalone: istanza indipendente

Conclusioni

L’architettura di OpenTelemetry è progettata per essere:

Modulare: componenti indipendenti e sostituibili
Estensibile: possibilità di aggiungere nuove funzionalità
Interoperabile: compatibile con diversi sistemi
Vendor-neutral: indipendente da specifici vendor

Comprendere questa architettura è il primo passo per implementare efficacemente l’observability nelle applicazioni moderne. Continua a leggere gli articoli della serie su OpenTelemtry per affrondire maggiormente.