Cos'è l'observability: definizione, segnali e costi
Riassunto
Cos'è l'observability? È la capacità di spiegare il comportamento di un sistema usando solo la telemetria che già emette, anche per guasti nuovi. Il monitoring controlla soglie note; l'observability permette di porre domande nuove in produzione. Si basa su log, metriche e trace, e richiede dati ad alta cardinalità per isolare la causa di un incidente senza rilasciare nuovo codice.
Cos'è l'observability? È la capacità di spiegare perché un sistema si comporta male usando solo la telemetria che già emette, anche per guasti che nessuno aveva previsto. Il monitoring ti dice che la latenza del checkout ha superato gli 800 ms. L'observability ti permette di chiedere quale cliente, quale dipendenza o quale deploy ha causato il problema, senza scrivere nuovo codice alle tre di notte per scoprirlo.
Ecco lo scenario che rende concreta la differenza. Scatta l'allarme: il p99 dell'API dei pagamenti è salito da 180 ms a 1,4 secondi. La dashboard è verde su CPU, memoria e tasso di errore. Ogni pannello predefinito dice che il servizio funziona, e ogni cliente dice il contrario. Quello che fai nei dieci minuti successivi è il vero argomento di questo articolo.
Perché la definizione conta prima degli strumenti?
Il termine viene dalla teoria dei sistemi di controllo: un sistema è osservabile se puoi dedurre il suo stato interno dalle sue uscite esterne. Il software l'ha preso in prestito, poi i vendor lo hanno allargato fino a farlo significare "un prodotto con dashboard". Ignora questa deformazione.
La definizione utile per un team di ingegneria è più stretta e più pratica. Un sistema è osservabile quando puoi rispondere a una domanda nuova sul suo comportamento, in produzione, senza distribuire nuova strumentazione. La parola che conta è "nuova". Un alert a soglia risponde a una domanda scritta da qualcuno il trimestre scorso. Un sistema osservabile risponde a quella che stai facendo adesso.
Non è un test di purezza. Nessuno ha un sistema perfettamente osservabile, e l'obiettivo non è un punteggio. L'obiettivo è un percorso più breve da "qualcosa non va" a "questa modifica l'ha causato". Il tempo medio di rilevamento e il tempo medio di comprensione sono due numeri diversi, e la maggior parte dei team misura solo il primo.
In cosa l'observability si distingue dal monitoring?
Il monitoring è un insieme di controlli su modalità di guasto che già conosci: CPU sopra il 90% per cinque minuti, tasso di errore sopra l'1%, coda sopra 10.000 messaggi. È economico, affidabile e ti serve ancora. L'observability non lo sostituisce.
La differenza emerge quando il guasto è nuovo. Il monitoring nasce dai tuoi incidenti passati. L'observability serve per il prossimo, che per definizione non hai ancora visto.
Un test utile: prendi gli ultimi tre incidenti e chiediti come è stata trovata la causa.
Se qualcuno ha letto una dashboard predefinita e la risposta era lì, il monitoring ha fatto il suo lavoro.
Se qualcuno ha cercato nei log su sei host, ha formulato un'ipotesi, ha aggiunto una riga di log e ha rilasciato di nuovo per confermarla, quello è stato un buco di observability.
Se la risposta vera è arrivata dallo screenshot di un cliente, hai entrambi i problemi.
Non serve discutere se i due siano rivali. Sono livelli. Il monitoring è il rilevatore di fumo. L'observability è la capacità di percorrere l'edificio dopo e capire quale circuito ha innescato l'incendio.
Quali sono i tre segnali e dove fallisce ciascuno?
Log, metriche e trace sono il trio standard. Ognuno risponde a una domanda diversa e ha una modalità di guasto che le guide dei vendor tendono a saltare.
Le metriche sono misure numeriche aggregate nel tempo: tasso di richieste, tasso di errore, percentili di latenza, saturazione. Costano poco da memorizzare e si interrogano in fretta, per questo gli alert si basano su di esse. Il loro punto debole è l'aggregazione. Un p99 di 1,4 secondi ti dice che qualcosa è lento. Non ti dice che ogni richiesta lenta appartiene a un solo cliente su un solo shard.
I log sono registrazioni con timestamp di eventi discreti. Contengono il massimo di dettaglio e la minima struttura, a meno che tu non imponga una struttura. Il punto debole è il volume e il costo. I log non strutturati si cercano solo se sai già quale stringa cercare, e così diventano uno strumento di monitoring travestito da strumento di debug.
Le trace seguono una singola richiesta attraverso i confini dei servizi, con uno span per ogni salto e il relativo tempo. Sono l'unico segnale che mostra la forma di una richiesta: questa chiamata ha atteso 900 ms una dipendenza a valle che ha riprovato tre volte. Il punto debole è la copertura. Un servizio che perde il contesto di trace spezza la catena, e una trace con un buco è peggio che inutile perché sembra autorevole.
Avere tutti e tre non equivale a essere osservabili. Conta la correlazione. Devi poter passare da un picco di metriche alle trace che lo hanno prodotto, e da una trace ai log di quella richiesta esatta. Se i tre vivono in strumenti separati senza un identificatore comune, hai tre sistemi di monitoring e un ingegnere che fa da collante.
Perché la cardinalità decide se puoi fare debug?
La cardinalità è il numero di valori distinti che un campo può assumere. status_code ne ha circa venti. customer_id ne ha centinaia di migliaia. request_id ne ha uno per richiesta.
I campi che ti servono di più durante un incidente sono quelli ad alta cardinalità. "Quale cliente è coinvolto?" è una domanda su customer_id. "Quale build sta servendo le richieste lente?" è una domanda su deploy_version. Se il tuo modello di storage penalizza i campi ad alta cardinalità, facendoti pagare ogni serie unica o eliminandoli in silenzio, non potrai porre la domanda che risolve l'incidente.
Qui sta la vera linea architetturale tra un setup solo di metriche e uno osservabile. Le metriche pre-aggregate buttano via le dimensioni che vorrai più avanti. Gli eventi strutturati e ampi le conservano, e si affettano dopo.
Ecco come appare un evento utile al bordo di un servizio: un record strutturato per richiesta, con abbastanza contesto da filtrare per tutto ciò che ti interesserà in seguito.
logger.info("request.completed", {
trace_id: span.traceId,
route: "/v1/payments",
customer_id: ctx.customerId,
deploy_version: process.env.BUILD_SHA,
flag_variant: flags.get("new-ledger-path"),
db_ms: timings.db,
upstream_ms: timings.upstream,
status: res.statusCode,
duration_ms: elapsed,
});Nota la variante del feature flag. Una parte degli incidenti descritti nei post-mortem pubblici inizia con una modifica, e la valutazione di un flag è una modifica. Se la variante non è nell'evento, non puoi chiederti se le richieste lente sono proprio quelle sul nuovo percorso.
Come appare un incidente con e senza observability?
Riprendiamo lo scenario dei pagamenti. Stesso allarme, stesso p99 di 1,4 secondi.
Senza observability, il ciclo è questo: apri la dashboard del servizio, non trovi nulla, apri quella del database, non trovi nulla, chiedi nel canale dell'incidente se qualcosa è stato rilasciato. Qualcuno ricorda una modifica di configurazione. Qualcun altro non è d'accordo. Quaranta minuti dopo fai il revert dell'ultimo deploy per vedere se serve. Non serve, perché la causa era un rollout del flag su un sottoinsieme di tenant.
Con observability, il ciclo è questo: raggruppi le richieste lente per flag_variant e vedi che il 100% è sul percorso new-ledger-path. Raggruppi per customer_id e vedi che tre grandi tenant concentrano la maggior parte del volume. Apri una trace e vedi che la chiamata al ledger si espande in 40 query sequenziali. Tempo totale: qualche minuto. Spegni il flag, non il deploy.
Nota cosa il secondo ciclo non ha richiesto. Non ha richiesto una dashboard preparata. Non ha richiesto che qualcuno prevedesse in anticipo che "variante del flag" fosse una dimensione interessante. Ha richiesto che i dati fossero lì, ampi e interrogabili.
È l'argomento di Honeycomb in un paragrafo, e regge. Quello che non dice è che tutto questo non è gratuito.
Quanto costa e chi dovrebbe evitare la versione più cara?
La telemetria è prima di tutto un problema di volume di dati, e solo dopo un problema di strumenti. Secondo il sondaggio 2025 di Grafana Labs sull'observability, che ha coinvolto 1.255 professionisti, l'organizzazione media usa otto strumenti diversi per l'observability, e il costo è il criterio più citato nella scelta di nuovi strumenti. I due dati sono collegati. I team accumulano strumenti perché ognuno risolve una porzione del problema, poi pagano per l'ingestione sovrapposta in tutti.
Alcune regole pratiche che reggono nella maggior parte dei team:
Strumenta con OpenTelemetry, non con un agente proprietario. Il collector ti dà un unico punto dove campionare, filtrare e instradare. Cambiare backend diventa una modifica di configurazione e non un progetto di ri-strumentazione.
Campiona le trace in modo deliberato. Conserva ogni errore e ogni richiesta lenta, e campiona quelle sane e veloci. Il campionamento head-based fisso all'1% scarta proprio la trace che ti serve.
Imponi una struttura ai log al momento della scrittura. Fare il parsing del testo libero al momento della query è il modo più costoso per ottenere dei campi.
Definisci una politica di retention per ogni segnale. Metriche per un anno, eventi ampi per due settimane, log di debug per tre giorni. Nessuno ha mai avuto bisogno dei log di debug del trimestre scorso.
Evita l'approccio a piattaforma completa se gestisci un numero limitato di servizi e una sola rotazione di reperibilità. Un team piccolo ottiene la maggior parte del beneficio da log strutturati, metriche RED e trace sui due o tre percorsi più critici. Il contratto costoso, che fa tutto, si ripaga quando i servizi sono tanti che nessuno tiene in testa l'intera topologia, cosa che nella nostra esperienza accade oltre i 30 o 40 servizi.
Quali strumenti meritano attenzione?
La scelta dello strumento dipende da quanto vuoi gestire in autonomia, da come si presenta la tua cardinalità e da quanto il budget può sostenere. Un breve giro, con opinioni precise:
Datadog è l'opzione commerciale più ampia: metriche, log, trace e profiling sotto un unico tetto, con una forte correlazione tra i segnali. Il prezzo di questa integrazione è una fattura che cresce con gli host, le metriche personalizzate e il volume dei log ingeriti. Vale la pena se vuoi un solo fornitore e hai il budget adeguato. Controlla la voce delle metriche personalizzate prima di impegnarti.
Grafana è la scelta predefinita quando vuoi componenti aperti che puoi installare in autonomia o acquistare come stack gestito. Si abbina bene alle metriche in stile Prometheus e alle pipeline OpenTelemetry. Il compromesso è operativo: sei tu a gestire più parti dell'assemblaggio, e la proliferazione di strumenti del sondaggio citato sopra riguarda anche te.
SigNoz è un'opzione open source, nativa OpenTelemetry, che mette log, metriche e trace in un unico datastore. Conta per il punto sulla correlazione di prima, perché uno store condiviso trasforma il passaggio da metrica a trace a log in una query invece che in un cambio di scheda. È ragionevole per i team che vogliono l'auto-hosting senza mettere insieme quattro progetti.
Better Stack combina monitoraggio di uptime, alerting sugli incidenti e gestione dei log a un prezzo pensato per i team più piccoli. È un primo passo sensato se stai passando da "lo scopriamo dai clienti" a qualcosa di strutturato, e meno adatto a un service mesh grande con forti esigenze di trace.
Come iniziare senza voler risolvere tutto in una volta?
Non iniziare con una valutazione degli strumenti. Inizia dagli ultimi tre incidenti e da una domanda onesta: cosa avremmo voluto poter chiedere?
Una sequenza che funziona per un team di 50-200 ingegneri:
Scegli un percorso critico e strumentalo dall'inizio alla fine con OpenTelemetry. Checkout, login, qualsiasi cosa ti svegli alle tre di notte.
Emetti un evento strutturato e ampio per richiesta al bordo del servizio, con cliente, versione, varianti dei flag e tempi delle dipendenze a valle.
Definisci uno SLO su quel percorso e allerta sul tasso di consumo del budget, non su soglie grezze. Gli alert sul burn rate ti avvisano per l'impatto sugli utenti, e la telemetria del punto 2 ti dice perché.
Fai un game day. Inietta un guasto che non hai mai allertato e misura quanto ci mette qualcuno che non ha scritto il codice a trovarlo. Quel numero è la tua base di partenza.
Espandi un percorso alla volta, solo dopo che il primo si è ripagato in un incidente reale.
L'observability si compra come piattaforma e si adotta come abitudine. L'abitudine è chiedersi "di cosa avrei bisogno per spiegarlo?" durante la code review, prima dell'incidente e non durante.
Riprendi la tua ultima revisione di incidente. Cerca la frase "abbiamo poi aggiunto il logging per confermare". Ognuna di queste è una domanda a cui il tuo sistema non sapeva rispondere in produzione. Quante ne hai documentate, e quante sarebbero ancora senza risposta oggi?