Strumentazione OpenTelemetry per osservabilità distribuita vendor-neutral

OpenTelemetry è un progetto CNCF che definisce un'API vendor-neutral, SDK e protocollo wire (OTLP) per trace, metriche e log. A differenza degli agenti proprietari — Datadog APM, New Relic, Dynatrace — non incorpora codice vendor-specifico nell'applicazione. Si strumenta una sola volta usando l'API OTel aperta e si instradano i segnali verso qualsiasi backend conforme tramite il Collector. Per cambiare backend è sufficiente riconfigurare gli exporter del Collector, senza modificare il codice dell'applicazione.

Le trace registrano il percorso end-to-end di una singola richiesta tra i servizi — ogni operazione è uno span con timing, attributi e stato. Le metriche sono aggregazioni numeriche nel tempo (tasso di richieste, tasso di errori, percentili di latenza) adatte a dashboard e alerting. I log sono eventi testuali o strutturati con timestamp dei singoli componenti. OTel unifica tutti e tre sotto un unico SDK e protocollo wire, e gli exemplar collegano i punti di dato delle metriche direttamente alle trace che li hanno prodotti.

OTel stesso non effettua la redazione dei PII — è responsabilità della pipeline. Configuriamo il processor degli attributi e il transform processor del Collector OTel per eliminare, hash-are o mascherare attributi degli span e campi di log che potrebbero contenere dati regolamentati (email, ID utente, numeri di carta, codici fiscali) prima che i segnali raggiungano qualsiasi backend. Questo mantiene la telemetria conforme a GDPR e normative simili senza richiedere modifiche alla strumentazione a livello applicativo.

L'head-based sampling decide all'inizio di una trace se registrarla — veloce ed efficiente in termini di memoria, ma scarta le trace di errore rare con la stessa probabilità di quelle di routine. Il tail-based sampling bufferizza la trace completa nel Collector prima di decidere, consentendo policy come «mantieni sempre le trace con errori o latenza superiore a 1 s». Configuriamo il tail-based sampling per i sistemi in produzione dove perdere trace di errore è più costoso della memoria e CPU aggiuntive del Collector.

Il Collector OTel è un agente vendor-agnostic che riceve OTLP (o altri formati), elabora i segnali — batching, filtering, trasformazione degli attributi, redazione PII, tail-based sampling — ed esporta verso uno o più backend simultaneamente. È possibile esportare direttamente dagli SDK verso un backend, ma il Collector disaccoppia la strumentazione dalla scelta del backend, centralizza la gestione dei dati sensibili (redazione PII) e consente il fan-out verso più backend senza modifiche all'applicazione. Lo raccomandiamo per qualsiasi deployment in produzione.

L'overhead dipende dalla frequenza di sampling e dalla cardinalità. Con head-based sampling al 10% e attributi degli span ben ottimizzati (senza label ad alta cardinalità come l'ID utente per span), l'overhead della CPU è tipicamente inferiore al 2% e l'impatto sulla memoria è minimo. Gli agenti di auto-strumentazione aggiungono un costo di caricamento delle librerie all'avvio. Il tail-based sampling nel Collector aggiunge memoria proporzionale alla finestra di buffer. Effettuiamo il profiling dei servizi strumentati prima e dopo il deployment e adattiamo le policy di sampling per mantenere l'overhead all'interno degli SLO concordati.

La migrazione è incrementale. Iniziamo eseguendo il Collector OTel insieme all'agente esistente, instradando un flusso OTLP duplicato verso un backend di prova compatibile OTel mentre l'agente proprietario continua in produzione. Una volta confermata la parità dei segnali — copertura delle trace, cardinalità delle metriche, fedeltà degli alert — rimuoviamo l'auto-strumentazione dall'agente proprietario, lasciando solo gli SDK OTel nell'applicazione. Il Collector può ancora esportare verso Datadog tramite il suo OTLP exporter se Datadog viene mantenuto come backend, quindi non c'è un cutover netto.