Un sistema può essere «verde» su tutti i pannelli di controllo e, nello stesso momento, far aspettare dieci secondi un utente su cento. Il monitoraggio classico risponde a domande che conosci in anticipo: il server è acceso? Il disco è pieno? L'osservabilità serve per le domande che non avevi previsto: perché proprio quelle richieste sono lente, e solo da ieri?
Monitoraggio e osservabilità
Il monitoraggio controlla indicatori noti e genera avvisi quando superano una soglia. È indispensabile, ma presuppone di sapere già cosa può andare storto.
L'osservabilità è una proprietà del sistema: quanto bene puoi capire cosa sta succedendo al suo interno guardando i dati che produce. Un'applicazione osservabile emette informazioni abbastanza ricche da permettere di indagare problemi nuovi senza dover aggiungere codice e rilasciare una nuova versione.
I dati su cui si basa sono tradizionalmente tre, spesso chiamati i tre pilastri.
Metriche
Le metriche sono valori numerici misurati nel tempo: richieste al secondo, percentuale di errori, tempo di risposta, memoria usata, lunghezza di una coda. Sono compatte, economiche da conservare a lungo e ideali per grafici e avvisi.
Per i tempi di risposta la media inganna. Se novantanove richieste impiegano 50 millisecondi e una ne impiega dieci secondi, la media sembra accettabile ma un utente su cento ha un'esperienza pessima. Per questo si usano i percentili: il 95° o il 99° percentile indicano il tempo entro cui si concludono il 95 o il 99 per cento delle richieste.
Un criterio pratico per scegliere cosa misurare su un servizio è osservare quattro segnali: traffico, errori, latenza e saturazione delle risorse.
Il limite delle metriche è la cardinalità. Si possono suddividere per etichette, come endpoint o codice di risposta, ma aggiungere etichette con troppi valori diversi, come l'identificativo dell'utente, fa esplodere il numero di serie da memorizzare e i costi.
Log
I log sono registrazioni di eventi: una richiesta ricevuta, un errore, un'operazione completata. Contengono il dettaglio che le metriche non hanno: quale utente, quale parametro, quale messaggio d'errore.
Per essere utili in un sistema distribuito i log devono essere:
- strutturati, cioè in formato JSON o simile, con campi separati invece di frasi libere, così da poter filtrare per campo;
- centralizzati, raccolti da tutti i server in un unico posto interrogabile;
- correlabili, con un identificativo di richiesta che permetta di seguire la stessa operazione tra componenti diversi;
- sobri, senza password, token o dati personali non necessari.
Un log strutturato ha questo aspetto:
{"ts":"2026-03-14T10:22:31Z","level":"error","service":"ordini","request_id":"a91f3c","msg":"timeout verso pagamenti","durata_ms":5003}
Tracce distribuite
In un'architettura con molti servizi, una singola richiesta dell'utente può attraversarne cinque o sei. Se è lenta, quale servizio è responsabile? Le tracce rispondono a questa domanda.
Una traccia segue una richiesta dall'inizio alla fine. È composta da span, ciascuno dei quali rappresenta un'operazione: la chiamata a un altro servizio, una query al database, una lettura dalla cache. Ogni span ha un inizio, una durata e un riferimento allo span che lo ha generato. Visualizzata, una traccia mostra a colpo d'occhio dove si consuma il tempo: per esempio che una query al database impiega quattro dei cinque secondi totali.
Le tracce sono costose da conservare tutte, perciò si ricorre al campionamento: si registra solo una parte delle richieste, scegliendo di conservare sempre quelle con errori o particolarmente lente.
Usarli insieme
La forza dell'osservabilità sta nel passare da un tipo di dato all'altro.
- Una metrica segnala che il 99° percentile della latenza è salito.
- Filtrando le tracce di quel periodo si scopre che le richieste lente passano tutte per lo stesso servizio.
- I log di quel servizio, filtrati con l'identificativo della traccia, mostrano il messaggio d'errore esatto.
Perché questo funzioni, log e tracce devono condividere lo stesso identificativo, e tutti i dati devono usare gli stessi nomi per servizi e ambienti.
OpenTelemetry
Per anni ogni fornitore di strumenti di osservabilità ha avuto le proprie librerie, legando le applicazioni a un prodotto. OpenTelemetry è un progetto open source che definisce uno standard comune per generare e trasmettere metriche, log e tracce. Si strumenta il codice una volta e si possono inviare i dati a sistemi diversi, open source o commerciali, cambiando solo la configurazione.
Molti linguaggi offrono anche una strumentazione automatica, che registra senza modifiche al codice le chiamate HTTP e le query ai database più comuni.
Da dove cominciare
Non serve un'infrastruttura complessa per iniziare. Un percorso ragionevole:
- esponi le metriche essenziali del servizio e crea pochi grafici sui quattro segnali;
- passa ai log strutturati e aggiungi un identificativo di richiesta;
- raccogli i log in un unico punto;
- introduci le tracce quando i servizi diventano più di due o tre.
In sintesi
- Il monitoraggio controlla problemi noti; l'osservabilità permette di indagare quelli imprevisti.
- Le metriche sono numeri nel tempo: usa i percentili per la latenza e attenzione alla cardinalità.
- I log devono essere strutturati, centralizzati, correlabili e privi di dati sensibili.
- Le tracce mostrano il percorso di una richiesta tra servizi e dove si perde tempo.
- OpenTelemetry offre uno standard unico per produrre i dati senza legarsi a un fornitore.
