OpenTelemetry per Tracing e Metrics — Guida Operativa senza Vendor Lock-in • Meteora Web Agency

Hai un'applicazione in produzione. Gli errori aumentano ma i log non dicono il perché. Le metriche aggregate ti mostrano un picco di CPU, ma non quale richiesta l'ha causato. Serve il distributed tracing. Il problema? Ogni vendor (Datadog, New Relic, AWS X-Ray) ha il suo SDK, il suo protocollo. Se domani cambi fornitore, devi riscrivere tutto. Noi di Meteora Web abbiamo visto questo scenario decine di volte: clienti con 5 strumenti diversi per log, metriche e trace, nessun dato coerente. OpenTelemetry (OTel) è lo standard aperto che unifica tutto: un SDK per tracciare, una semantica condivisa, e la libertà di esportare dove vuoi. In questa guida ti mostriamo come usarlo davvero, con codice che funziona, evitando i vendor lock-in.

Perché OpenTelemetry è diventato lo standard per tracing e metrics?

OpenTelemetry è nato dalla fusione di OpenTracing e OpenCensus, supportato da Cloud Native Computing Foundation (CNCF). Non è un prodotto, è un framework. Definisce come generare, raccogliere e trasmettere telemetry data (trace, metrics, logs) in modo indipendente dal backend. Perché serve? Perché in una architettura a microservizi, una richiesta utente attraversa decine di servizi. Senza un trace distribuito non sai dove si perde il millisecondo. Con OTel usi un unico SDK nel codice e poi decidi dove spedire i dati: Jaeger, Prometheus, Grafana, o persino il tuo collector custom. Nessun lock-in.

Esempio concreto: Seguiamo un cliente e-commerce che usava un vendor di APM proprietario. Il rinnovo annuale costava più del loro hosting. Con OTel abbiamo instrumentato i microservizi in Laravel e Node.js, esportato verso un cluster Prometheus + Jaeger self-hosted. Costi dimezzati, controllo totale. Se un giorno vorranno passare a Grafana Cloud, cambieranno solo un endpoint nel collector.

Come funziona la strumentazione automatica e manuale in OpenTelemetry?

Esistono due approcci: strumentazione automatica (auto-instrumentation) e manuale. La prima è ideale per iniziare: installi un agente (es. per Python, Java, Node.js) che modifica il runtime e cattura automaticamente le chiamate HTTP, database, cache. Non tocchi codice. Però non cattura logica business personalizzata. Qui entra la strumentazione manuale: aggiungi span nel codice per tracciare operazioni specifiche (es. un calcolo di sconto, una query complessa).

Esempio pratico: instrumentare un endpoint Flask in Python

pip install opentelemetry-distro opentelemetry-exporter-otlp

from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
from opentelemetry.instrumentation.flask import FlaskInstrumentor

# Setup provider
trace.set_tracer_provider(TracerProvider())

# Esportatore OTLP verso collector o backend
exporter = OTLPSpanExporter(endpoint="http://localhost:4317", insecure=True)
span_processor = BatchSpanProcessor(exporter)
trace.get_tracer_provider().add_span_processor(span_processor)

# Strumentazione automatica Flask
app = Flask(__name__)
FlaskInstrumentor().instrument_app(app)

# Strumentazione manuale
tracer = trace.get_tracer(__name__)

@app.route('/calcola-sconto')
def calcola_sconto():
    with tracer.start_as_current_span('calcolo_sconto') as span:
        prezzo = request.args.get('prezzo', 0, type=float)
        sconto = prezzo * 0.1
        span.set_attribute('prezzo_originale', prezzo)
        span.set_attribute('sconto_applicato', sconto)
        return {'totale': prezzo - sconto}

if __name__ == '__main__':
    app.run()

Con poche righe hai trace per ogni richiesta, inclusi i dettagli personalizzati. Lo stesso pattern vale per Node.js, Java, Go. Noi lo usiamo in Laravel con il pacchetto open-telemetry/opentelemetry-laravel.

Come inviare traces e metrics a un backend con OpenTelemetry Collector?

Il Collector OTel è un componente chiave: riceve dati da più fonti (SDK, agenti, altre applicazioni), li elabora (filtri, campionamento, aggiunta attributi) e li inoltra a uno o più backend. Lo esegui come sidecar o daemon. Esempio di configurazione minima per inviare a Jaeger e Prometheus:

File config.yaml per OpenTelemetry Collector

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

exporters:
  jaeger:
    endpoint: jaeger:14250
    tls:
      insecure: true
  prometheus:
    endpoint: 0.0.0.0:8889

service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [jaeger]
    metrics:
      receivers: [otlp]
      exporters: [prometheus]

Avvia il collector con otelcol --config config.yaml. Ora ogni applicazione che invia dati OTLP all'indirizzo del collector (es. http://collector:4318) finirà automaticamente sia in Jaeger (trace) sia in Prometheus (metriche). Roba seria, non giocattoli: abbiamo usato questa architettura per monitorare un cluster Kubernetes con 20 microservizi. La latenza media di trasporto è sotto i 5ms.

Quali sono i costi nascosti di un'infrastruttura di observability con OpenTelemetry?

OpenTelemetry è gratuito e open source, ma le risorse non sono gratis. Ogni span, ogni metrica consuma CPU, RAM, storage e banda di rete. Noi abbiamo visto clienti mandare milioni di span al minuto senza campionamento, saturando il collector. Il campionamento (sampling) è obbligatorio. Usa il tail-based sampling per decidere quali trace conservare interamente. Ad esempio, conserva tutti i trace con errore o con latenza >500ms, e campiona al 10% quelli normali. Il collector OTel supporta nativamente il processor tail_sampling.

processors:
  tail_sampling:
    decision_match:
      - name: error
        policies:
          - type: status_code
            status_code: ERROR
      - name: slow
        policies:
          - type: latency
            threshold_ms: 500
    sampling_percentage: 10

Attenzione: se usi un backend SaaS (Datadog, Grafana Cloud), il costo è per volume di dati. Un collector locale con campionamento intelligente può ridurre la bolletta del 70%.

Come gestire la sicurezza e la privacy dei dati nei trace?

I trace contengono spesso dati sensibili: header HTTP, parametri di query, payload. OpenTelemetry fornisce processori per mascherare o eliminare attributi prima dell'esportazione. Esempi: rimuovere header Authorization, oscurare email, filtrare query SELECT * FROM users. Configurabile nel collector con il processor attributes o filter.

processors:
  attributes:
    actions:
      - key: http.request.header.authorization
        action: delete
      - key: db.statement
        action: hash

Noi rendiamo automatico questo filtro in ogni progetto: proteggere i dati del cliente è un requisito GDPR che non va lasciato al caso. Se usi un backend esterno, assicurati che sia conforme (es. Grafana Cloud con contratto DPA).

OpenTelemetry si integra con altri strumenti di monitoring?

Certamente. Il bello di OTel è la neutralità. Puoi raccogliere metriche con il SDK OTel e inviarle a Prometheus, mentre mantieni i trace su Jaeger e i log su Loki. Oppure unire tutto su Grafana. Noi abbiamo realizzato una dashboard unificata per un cliente che usava Redis (per job queue) e MongoDB (per dati geospaziali). Grazie a OTel abbiamo tracciato ogni query Redis e MongoDB con span specifici, senza cambiare librerie. Per approfondire, leggi il nostro articolo su Redis come coda di job e sugli indici MongoDB composti.

Cosa fare adesso

1. Installa l'SDK OpenTelemetry nel tuo progetto principale. Inizia con auto-instrumentation per un solo servizio.
2. Configura un OpenTelemetry Collector su un server o container. Usa il file di esempio sopra e punta a un backend gratuito come Jaeger (locale) o Grafana Cloud (free tier).
3. Attiva il campionamento dal primo giorno. I costi senza sampling esplodono.
4. Aggiungi strumentazione manuale per le operazioni critiche. Non fermarti all'auto-instrumentation: traccia il checkout, il calcolo del carrello, l'invio email.
5. Verifica la sicurezza dei dati esportati. Applica filtri per rimuovere PII.
6. Leggi la documentazione ufficiale: OpenTelemetry Documentation.
7. Consulta la nostra guida madre sul monitoring: Monitoring e Observability – pillar.