Log, metriche, trace: come penso all’osservabilità di un sistema distribuito

Come tastare il polso del sistema e capire cosa succede e dove.

Misurare è controllare, il tempo investito nell’implementazione dei log non è mai sprecato ma il migliore degli investimenti.

Differenza tra l’analisi di un problema su un monolite e su un sistema distribuito

Nel mondo monolitico l’analisi di un problema è quasi sempre un percorso lineare e prevedibile: un solo codice, un solo ambiente, un solo punto di osservazione. In caso di errore hai tutto sotto mano: l’IDE, il debugger, lo stack trace completo.

Nei sistemi distribuiti, invece, questo approccio non è più sufficiente.
Una singola richiesta può passare attraverso dieci servizi, due code, uno scheduler, un job asincrono e magari anche una chiamata esterna. Il problema può emergere minuti dopo il punto in cui ha avuto origine.

Non hai più la possibilità di “fermarsi e vedere cosa succede”.
Il debugging classico, semplicemente, non si applica più.
Serve un modo nuovo di osservare il sistema. Serve una disciplina che ti permetta di vedere anche ciò che non puoi mettere in pausa.

È qui che entra in gioco l’osservabilità.

Filosofia LID — Log Instead Debugging

La filosofia LID (Log Instead Debugging) parte da un’idea chiara:

Fornire nei log tutte le informazioni necessarie a capire cosa sta facendo un processo, senza bisogno di fare debugging.

Non è un sostituto del debugger in senso assoluto: il debugging rimane più potente.
Ma nei sistemi distribuiti è spesso impossibile usarlo, perché i servizi sono isolati, effimeri, asincroni, in cluster o in container che non puoi “pausare”.

LID significa progettare il software affinché:

• chi legge i log possa ricostruire il flusso del programma,
• anche senza avere il sorgente,
• persino senza conoscere lo stack tecnologico sottostante.

Questo approccio ha due conseguenze strategiche:

1. Riduce il costo della diagnosi
   Tecnici meno skillati possono analizzare problemi complessi leggendo log chiari e strutturati.
2. Rende il sistema leggibile da chiunque
   Non serve essere esperti dello stack per capire cosa stia succedendo.

In altre parole, LID democratizza la capacità di fare troubleshooting.
È un investimento che paga più volte: meno conoscenza tribale, meno dipendenza dai “guru” e maggiore autonomia del team.

Log management

Loggare non basta: serve poterli usare.
Il log management permette di trasformare una massa di eventi in una fonte di conoscenza utile e interrogabile.

Gli obiettivi principali sono:

• centralizzare log provenienti da molti servizi;
• indicizzarli in modo rapido;
• cercare eventi, pattern e correlazioni;
• creare dashboard e grafici;
• impostare regole di alerting;
• gestire retention, storage e volumi enormi.

Strumenti come ELK, Loki, OpenSearch o Datadog rappresentano ormai standard operativi. Senza una piattaforma di log management, anche i log migliori diventano inutili: sono solo righe sparse in container effimeri.

Il log management rende “sfruttabile” l’investimento LID.

Quantificare: l’arte nell’uso delle metriche

Le metriche sono la parte quantitativa dell’osservabilità.
Sono semplici, veloci, numeriche e comparabili nel tempo.

A differenza dei log, che raccontano cosa è accaduto, le metriche rispondono alla domanda:

Il sistema sta funzionando come dovrebbe?

Metriche fondamentali:

• RED metrics (Rate, Errors, Duration) – per API e servizi.
• Utilizzo risorse – CPU, memoria, I/O, connessioni DB.
• Code e sistemi asincroni – lunghezza, tempo di permanenza, tasso di consumo.
• Metriche business – KPI applicativi che impattano davvero (ordini, etichette generate, integrazioni riuscite).

Senza metriche non c’è controllo. Senza controllo non c’è miglioramento.
Le metriche ti dicono quanto un problema è grave e quando è iniziato. I log ti dicono perché.

Il giro del fumo: tracing di un processo in un sistema distribuito

Il tracing è ciò che collega insieme log, metriche e chiamate tra servizi.
È la vista end-to-end della vita di una singola richiesta.
Quello che chiamo “il giro del fumo”: il percorso completo di un evento nel sistema.

Con il tracing:

• assegni un trace-id a ogni richiesta;
• i servizi aggiungono informazioni sul proprio lavoro;
• ottieni un grafo del flusso e dei tempi;
• identifichi colli di bottiglia e componenti lenti;
• capisci dove nasce realmente un problema.

Senza tracing, un sistema distribuito è opaco.
Con il tracing, diventa leggibile come una mappa.

OpenTelemetry ha finalmente standardizzato questo approccio, rendendolo accessibile senza vendor lock-in.

Conclusioni

Purtroppo questo è un tema enorme, oggi mi limito solo a raccontarlo velocemente, ma a seguire scriverà articoli più approfonditi su ogni singolo tema.

L’osservabilità non è un insieme di strumenti: è un modo di pensare.
Significa progettare il sistema sapendo che, prima o poi, qualcosa andrà storto — e che dovrai capirlo in fretta.

Log Instead Debugging, metriche solide e tracing diffuso sono tre pilastri complementari:

• i log raccontano la storia,
• le metriche misurano la salute,
• il tracing collega tutto assieme.

In un monolite puoi vivere senza.
In un sistema distribuito, sono semplicemente indispensabili.

Investire nell’osservabilità significa investire nel futuro del progetto e del team.
Perché più un sistema è complesso, più diventa prezioso poterlo comprendere senza fatica.