Osservabilità oltre i log: cosa cambia nella pratica OpenTelemetry

Monitorare se un sistema è attivo e funzionante non equivale a capire perché si comporta in un certo modo e confondere queste due cose è l'errore più costoso che i team di ingegneri commettono quando scalano un'architettura distribuita. Una dashboard verde non significa che l'utente stia vivendo una buona esperienza. Significa semplicemente che i servizi rispondono ai ping. La distanza tra queste due affermazioni è esattamente il punto in cui si trovano i bug più difficili da trovare, il degrado silenzioso e gli incidenti che richiedono ore per essere diagnosticati.

Ciò che separa il monitoraggio dall'osservabilità

Il monitoraggio parte da domande conosciute in anticipo: il server risponde? La coda sta crescendo? Il tasso di errore ha superato la soglia? Definisci le metriche, configuri gli avvisi e attendi che qualcosa superi una soglia. Funziona bene quando il sistema è semplice e le modalità di guasto sono prevedibili.

L'osservabilità è diversa. Il termine, preso in prestito dalla teoria del controllo, descrive la capacità di dedurre lo stato interno di un sistema dai suoi output. In pratica, significa essere in grado di rispondere a domande che non sapevi che avresti posto quando hai costruito il sistema. Perché questo utente specifico ottiene 503 mentre gli altri no? Perché la latenza del checkout è aumentata del 40% solo per i clienti di San Paolo? Perché questo servizio consuma il doppio della CPU il martedì dopo le 14:00?

Queste domande non hanno avvisi preconfigurati. Richiedono dati ricchi e correlati con un contesto sufficiente per guidare un'indagine reale.

Perché i log da soli non risolvono il problema

Per anni, la risposta standard a "come eseguire il debug in produzione" è stata "aggiungere più log". I registri sono utili: registrano eventi distinti, acquisiscono messaggi di errore e consentono il controllo. Ma nelle architetture distribuite diventano insufficienti per ragioni strutturali.

Una richiesta che passa attraverso dieci servizi genera log in dieci posti diversi. Senza un identificatore di correlazione propagato correttamente lungo tutta la catena, è impossibile ricostruire il percorso intrapreso dalla richiesta. Anche con gli ID di correlazione, stai mettendo insieme frammenti di testo sparsi e stai cercando di mettere insieme manualmente una narrazione coerente. Il tempo impiegato in un incidente attivo è il tempo che l'utente trascorre senza servizio.

Le metriche risolvono parte del problema (mostrano tendenze aggregate e consentono avvisi rapidi), ma perdono il contesto in base alla progettazione. Sai che la latenza media è aumentata, ma non sai quale operazione specifica, quale database, quale chiamata esterna era responsabile.

Le tracce colmano questa lacuna. Una traccia segue una richiesta dall'inizio alla fine, attraversando ogni servizio, ogni chiamata bancaria, ogni integrazione esterna, registrando durata e attributi ad ogni passaggio. Con le tracce, l'indagine che richiederebbe ore di grep nei file di registro ora richiede minuti di analisi visiva del tempo impiegato da ciascun intervallo.

Il problema che OpenTelemetry è venuto a risolvere

Prima di OpenTelemetry, dotare un sistema di osservabilità significava scegliere un fornitore (Datadog, New Relic, Jaeger, Zipkin) e implementare l'SDK proprietario di ciascuno. Cambiare fornitore significava riscrivere la strumentazione nell'intera base di codice. Utilizzare più strumenti contemporaneamente significava mantenere più SDK, con semantica diversa e sovraccarico duplicato.

OpenTelemetry, un progetto di laurea del CNCF con il contributo di Google, Microsoft, Splunk e dozzine di altre organizzazioni, ha concluso questo modello in due modi. Innanzitutto, ha definito una specifica unificata per i tre pilastri – metriche, log e tracce – con una semantica coerente tra di loro. In secondo luogo, ha implementato questa specifica negli SDK praticamente per tutti i linguaggi rilevanti, con l’autostrumentazione per i framework più comuni.

Il risultato pratico è che la strumentazione è nel codice una volta e la destinazione dei dati è configurata nel raccoglitore. Puoi inviare tracce a Jaeger durante lo sviluppo, a Tempo in produzione e testare Honeycomb in parallelo, il tutto senza toccare una riga di codice dell'applicazione. Il vincolo del fornitore non esiste più come vincolo tecnico.

Come implementare senza fermare la squadra

L'errore comune quando si adotta OpenTelemetry è provare a strumentare tutto in una volta. Il percorso intelligente è incrementale, iniziando dai punti di maggior valore diagnostico.

Il primo passaggio consiste nell'installare l'SDK e abilitare l'autostrumentazione per il framework HTTP utilizzato dal servizio. In Node.js, Go, Python e Java, questo copre automaticamente le chiamate in entrata, le chiamate in uscita e le connessioni al database senza alcuna modifica al codice aziendale. Avrai tracce con contesto utile in meno di un'ora di lavoro.

Il secondo passo è configurare OpenTelemetry Collector come intermediario tra le applicazioni e i backend di osservabilità. Il Collector riceve i dati, può trasformarli, filtrarli e inviarli a più destinazioni. Ciò disaccoppia l'applicazione da qualsiasi decisione su dove archiviare i dati.

Il terzo passaggio, che la maggior parte dei team sottovaluta, è la definizione di una strategia per gli attributi. Le tracce senza attributi contestuali (ID utente, ID tenant, versione di distribuzione, regione) sono difficili da filtrare quando cerchi un modello specifico. Standardizzare gli attributi che ogni servizio deve propagare è una decisione architetturale, non implementativa.

Cosa cambia nel processo di debug in produzione

Con l’implementazione dell’osservabilità reale, le dinamiche delle indagini sugli incidenti cambiano in modo concreto. Invece di avviare un incidente consultando i dashboard dell’infrastruttura e cercando di correlare gli avvisi della CPU con i picchi di latenza, il team inizia con l’esperienza utente interessata.

Una traccia da parte dell'utente che ha segnalato il problema mostra esattamente dove si è concentrata la latenza, quale servizio ha restituito un errore, quale interrogazione bancaria ha richiesto tre volte più tempo del normale. L’ipotesi nasce dai dati, non da ipotesi su cosa sarebbe potuto cambiare.

Ciò riduce la distanza tra "qualcosa non va" e "ecco la causa principale e la riga di codice responsabile". Le squadre che operano con un'osservabilità matura arrivano all'autopsia con prove, non con ricostruzioni approssimative basate su registri frammentati.