Cos'è l'observability? Guida pratica per i team di sviluppo

Sono le 2 di notte, l'endpoint del checkout restituisce errori 500 a circa una richiesta su venti e tutte le dashboard sono verdi. Quel divario tra "il sistema dice che va tutto bene" e "gli utenti dicono che è rotto" è esattamente ciò che l'observability serve a colmare. Cos'è l'observability? È la capacità di capire cosa sta facendo il sistema al suo interno, osservando i dati che emette (log, metriche e trace), abbastanza bene da rispondere a domande che non si era previsto di porre.

Quell'ultima clausola è il cuore di tutto il discorso. Il resto di questo articolo è dettaglio.

Observability e monitoring: la domanda per cui non ha scritto un alert

Il monitoring risponde alle domande che già conosceva. CPU sopra il 90%? Tasso di errore sopra il 2%? La coda cresce? Lei sceglie le metriche, imposta le soglie, e un allarme scatta quando una soglia viene superata.

L'observability risponde alla domanda che non sapeva di dover fare. Perché solo le richieste di un tenant, su una certa versione dell'app, dopo un deploy preciso, impiegano quattro secondi in più? Nessuno ha un alert per questo, perché nessuno l'aveva previsto.

Quindi i due concetti non sono rivali. Il monitoring è il livello degli allarmi. L'observability è ciò che le permette di indagare quando l'allarme scatta, oppure quando un cliente scrive e nessun allarme è scattato. Se il suo unico strumento è un muro di dashboard predefinite, ha il monitoring. Se può suddividere i dati di produzione per qualsiasi dimensione e seguire una richiesta attraverso più servizi senza rilasciare nuovo codice, ha l'observability.

I tre segnali: metriche, log e trace

La maggior parte delle definizioni parte dai "tre pilastri". L'etichetta suona un po' rigida, ma i tre tipi di dato sono reali, e ognuno è bravo in un compito preciso.

• Metriche sono numeri nel tempo: tasso di richieste, latenza p95, memoria in uso. Economiche da archiviare, veloci da interrogare, ottime per capire se c'è un problema. Deboli nel dire quale richiesta, e perché.

• Log sono registrazioni con timestamp di eventi discreti: un pagamento fallito, un retry partito, un feature flag cambiato. Portano il dettaglio, ma i log non strutturati su un servizio molto trafficato diventano un pagliaio.

• Trace seguono una singola richiesta mentre attraversa i servizi. Ogni passaggio è uno span con un inizio, una durata e alcuni attributi. Una trace è la cosa più vicina a uno stack trace per un sistema distribuito.

Il sondaggio 2025 di Grafana su 1.255 professionisti mostra a che punto sono davvero i team. Il sondaggio sull'observability di Grafana rileva che il 95% degli intervistati usa metriche e l'87% usa log, ma solo il 57% usa le trace. Le trace sono il segnale più adatto a risolvere un bug distribuito, ed è quello che meno team hanno configurato.

Eviti la scorciatoia che dice: le metriche dicono cosa, i log dicono perché, le trace dicono dove. Suona ordinata, ma in pratica non regge: un buon log strutturato spesso dice più sul "dove" di una trace scarsamente strumentata.

Cosa rende un sistema osservabile nella pratica

Emettere dati è necessario, ma non basta. Un sistema è osservabile quando i dati hanno tre proprietà.

Alta cardinalità. Può filtrare per ID utente, tenant, SHA di build, regione, feature flag. Se il suo strumento la costringe a pre-aggregare per nome del servizio e codice di stato, non riesce a trovare il singolo tenant nello stato sbagliato.

Contesto che collega i segnali. Un trace ID su ogni riga di log permette di passare da uno span lento ai log esatti che ha prodotto. Senza questo collegamento, legge due storie separate e deve indovinare come si incastrano.

Dettaglio sufficiente per essere utile, ma non così tanto da diventare insostenibile. È qui che la maggior parte dei team fatica. Nello stesso sondaggio Grafana, gli intervistati hanno citato più di 100 strumenti, servizi e progetti diversi, e il team medio ne usava otto. Il costo era uno dei criteri principali nella scelta. Raccogliere tutto è facile. Pagarlo è la parte che si scopre dopo.

Ecco come appare il punto di partenza con OpenTelemetry, lo standard di strumentazione indipendente dal vendor. Questo è un esempio minimo in Python che crea uno span e aggiunge gli attributi che vorrà avere alle 2 di notte:

from opentelemetry import trace

tracer = trace.get_tracer("checkout")

def charge(order):
    with tracer.start_as_current_span("charge_card") as span:
        span.set_attribute("order.id", order.id)
        span.set_attribute("tenant.id", order.tenant_id)
        span.set_attribute("app.version", APP_VERSION)
        result = payment_client.charge(order)
        span.set_attribute("payment.provider", result.provider)
        return result

Tre attributi fanno la differenza tra "il checkout è lento" e "il checkout è lento per il tenant 4412 sulla versione 3.8.1". La guida introduttiva di OpenTelemetry sull'observability spiega più a fondo i concetti alla base di tutto questo, e vale la pena leggerla una volta, anche se è il suo vendor a fare il collegamento al posto suo.

Dove differiscono gli strumenti di observability (e dove no)

Sotto il marketing, la maggior parte delle piattaforme acquisisce gli stessi tre segnali. Si differenziano per modello di prezzo, potenza delle query e quanto lavoro di strumentazione fanno al posto suo.

• Piattaforme all-in-one raggruppano metriche, log, trace, alerting e altro. Comode, con il compromesso di fatture a consumo che crescono con il traffico.

• Stack open source come Prometheus, Loki, Tempo e Grafana danno controllo e nessuna licenza per host, al prezzo di doverli installare e ottimizzare da soli.

• Backend nativi OpenTelemetry accettano direttamente il formato standard, quindi cambiare fornitore non richiede di ristrumentare ogni servizio.

Datadog è il punto di riferimento della categoria all-in-one: copertura ampia, interfaccia curata e una fattura che merita una revisione mensile. Ne vale la pena se cerca un unico fornitore e ha il budget. Lo lasci perdere se la prevedibilità dei costi è il vincolo principale.

Grafana è la scelta open source pragmatica. Può partire con delle dashboard sopra i dati che ha già, e aggiungere log e trace quando servono. Si aspetti di investire un po' di tempo di ingegneria.

SigNoz è costruito fin dall'inizio attorno a OpenTelemetry e riunisce metriche, log e trace in un'unica interfaccia open source. È una scelta sensata per un team che vuole l'esperienza in un'unica schermata senza il prezzo dell'all-in-one.

New Relic si colloca a metà tra i due mondi, con una piattaforma ospitata e un piano gratuito abbastanza generoso da permettere una valutazione reale. Lo giudichi in base alla capacità del suo team di rispondere davvero a una domanda di produzione concreta, non alla demo.

Nessuno di questi strumenti, da solo, la renderà osservabile. Lo strumento è un'interfaccia di interrogazione. La strumentazione è il prodotto.

La parte che molte guide saltano: l'observability si ferma al confine del codice

Qui c'è un limite che noterà la prima volta che usa seriamente questi strumenti. Una trace le dice che charge_card ha impiegato 3,9 secondi e che la parte lenta era una chiamata a payment_client. Non le dice cosa fa davvero payment_client, chi l'ha scritto, o perché ritenta tre volte senza backoff.

Per questo lascia lo strumento di observability e va a leggere il codice. In un servizio piccolo ci vogliono dieci minuti. In un repo da 100K righe di codice di quattro team diversi, la lettura è spesso la parte più lunga dell'incidente. Sa esattamente quale span è lento, e spende comunque un'ora per capire come è collegato il codice che c'è dietro.

Questo è il problema del passaggio tra dati di runtime e codice sorgente, ed è il motivo per cui consideriamo observability e comprensione del codice due metà dello stesso flusso di lavoro:

1. L'observability dice dove a runtime: quale servizio, quale span, quale tenant.

2. La comprensione del codice dice perché nel sorgente: quale funzione, quale politica di retry, quale configurazione.

I team che chiudono il cerchio (il nome dello span rimanda a un file, il file rimanda a un responsabile e a una spiegazione) riducono il tempo tra "allarme scattato" e "fix capito". È soprattutto un problema di disciplina. Dia agli span il nome delle funzioni, metta il percorso del file nel repo come attributo dello span, e tenga una breve nota di architettura per ogni servizio. Un assistente AI in grado di rispondere sul suo codice, come "dove è impostata la politica di retry per le chiamate di pagamento?", ha allora qualcosa di concreto a cui agganciarsi.

Tre errori che fanno pensare che l'observability non funzioni

Considerare le dashboard come obiettivo. Una dashboard è una risposta salvata a una vecchia domanda. I team che ne costruiscono quaranta e non praticano mai query ad hoc finiscono con il monitoring in un involucro più elegante. Si chieda a ogni incidente: l'abbiamo risolto con una dashboard, o esplorando i dati grezzi?

Campionare troppo presto, o mai. Tenere il 100% delle trace su un servizio molto trafficato diventa costoso in fretta, e tenere l'1% a caso butta via la rara richiesta fallita che le interessa davvero. Il tail-based sampling, che conserva le trace lente e fallite e scarta la maggior parte di quelle sane, è il compromesso più usato. Lo decida prima della prima fattura, non dopo.

Lasciare che i nomi degli attributi si disallineino. Un servizio scrive user_id, un altro userId, un terzo uid. A quel punto la query che dovrebbe coprire tutti e tre restituisce un terzo del quadro. Concordi una piccola convenzione di nomi per tenant, utente, versione e flag, e la scriva nel repo dove le persone la troveranno.

Nessuno di questi è un problema di strumenti. Sono abitudini, e le abitudini costano meno da correggere dei fornitori.

Un modo realistico per iniziare senza voler fare tutto subito

Se oggi non ha nulla, resista alla tentazione di strumentare tutto già nella prima settimana. Una sequenza che funziona per team da 5 a 50 ingegneri:

1. Scelga un flusso utente critico. Checkout, registrazione, la chiamata API principale. Non l'intero sistema.

2. Aggiunga log strutturati con un ID di richiesta. JSON, un evento per riga, con trace o ID di richiesta su ogni riga.

3. Strumenti quel flusso con trace OpenTelemetry. Includa gli attributi di tenant, versione e flag dell'esempio sopra.

4. Definisca due o tre obiettivi di servizio (SLO). Per esempio, il 99,5% delle richieste di checkout va a buon fine in meno di 800 ms. Gli allarmi si agganciano a questi, non alla CPU.

5. Analizzi un incidente reale con i dati. Avrebbe trovato la causa senza scrivere nuovo codice? Se no, il divario emerso è il suo prossimo compito di strumentazione.

Il passo 5 è quello che si salta, ed è l'unico che dice se lei è davvero osservabile. Tutto il resto è infrastruttura di base.

Cosa faremmo noi

Se il suo team ha meno di 20 ingegneri, parta dalla strumentazione OpenTelemetry e da un backend il cui prezzo sia prevedibile. La strumentazione è portabile, quindi la scelta del backend è reversibile. Eviti di comprare la piattaforma più grande solo perché l'ha fatto un concorrente.

Se paga già uno strumento all-in-one, non lo tolga di colpo. Verifichi cosa acquisisce, elimini i log che nessuno interroga, e investa il risparmio nella strumentazione dei flussi che contano.

E qualunque strada scelga, scriva come uno span torna al codice. La dashboard le mostra l'incendio. Qualcuno deve comunque leggere il sorgente per scoprire perché è partito.