Cos'è l'observability? Guida per chi lavora con i fogli

Cos'è l'observability? È la capacità di capire cosa sta facendo un sistema, e perché, usando solo i dati che emette: log, metriche e tracce. Se il monitoraggio ti dice che qualcosa si è rotto, l'observability ti permette di fare la domanda successiva: dove, per chi e da quando. Se lavori con i fogli di calcolo, la fai già in piccolo ogni volta che risali da un numero strano fino alla riga che lo ha generato.

Il riassunto in un minuto per chi vive nei fogli di calcolo

Immagina un foglio dei ricavi mensili in cui il totale non torna. Un cruscotto che dice "il totale è sbagliato" è monitoraggio. Poter filtrare per regione, per giorno e per prodotto, fino a trovare l'unico import che ha raddoppiato 400 righe, è observability.

I team software affrontano lo stesso muro con sistemi in produzione. Una pagina di pagamento rallenta. Scatta un allarme. Ora qualcuno deve capire quale servizio, quale segmento di clienti e quale rilascio hanno causato il problema. I dati che rendono possibile tutto questo si chiamano telemetria, e quanto bene li sai usare è ciò che si intende con observability.

Anche Biscuit ha una versione di questo. Non ha bisogno che gli dicano che la palla è persa. Gli serve ripercorrere dove l'ha vista l'ultima volta.

Monitoraggio e observability: problemi noti contro sorprese

Il monitoraggio controlla le cose che hai deciso di controllare in anticipo. CPU sopra il 90%, tasso di errore sopra il 2%, una pagina che smette di rispondere. Scrivi la regola, lo strumento urla quando la regola viene infranta.

L'observability serve per i problemi per cui non hai scritto nessuna regola. Il progetto OpenTelemetry la descrive come un modo per capire un sistema dall'esterno, senza conoscerne i meccanismi interni, il che aiuta con i cosiddetti "unknown unknowns", cioè i guasti che non sapevi nemmeno di poter avere.

Non serve scegliere tra le due. Il monitoraggio è il rilevatore di fumo. L'observability è la planimetria e il video della telecamera che guardi dopo. Ti servono entrambi.

Log, metriche e tracce: i tre ingredienti grezzi

Quasi ogni spiegazione arriva agli stessi tre segnali. Eccoli in termini di foglio di calcolo.

I log sono messaggi con timestamp su singoli eventi. In un foglio è una riga per evento: ora, utente, azione, esito. Hanno il massimo dettaglio e occupano più spazio.

Le metriche sono numeri aggregati nel tempo, come tasso di errore, richieste al minuto o memoria usata. In un foglio sono la scheda di riepilogo. Costano poco da conservare e sono rapide da graficare, ma non ti dicono quale singola richiesta è fallita.

Le tracce seguono una singola richiesta mentre attraversa più servizi, con il tempo speso in ogni passaggio. In un foglio pensa a un numero d'ordine che segui su cinque schede, annotando quanto è rimasto fermo in ciascuna.

La scorciatoia più usata: le metriche dicono che qualcosa non va, le tracce dicono più o meno dove, i log dicono il dettaglio. Vediamo come appare in una cella vera, in un minuto.

Hai 5,000 righe di log in un file: un esempio pratico in Sheets

Supponi di aver esportato 5,000 righe di log di un'applicazione in Google Sheets. La colonna A contiene il timestamp, la B il nome del servizio, la C il codice di stato, la D il tempo di risposta in millisecondi. Funziona in Excel e in Sheets, salvo dove indicato.

Prima il tasso di errore, una metrica classica:

=COUNTIF(C2:C5001, ">=500") / COUNTA(C2:C5001)

• L'intervallo è C2:C5001, cioè i codici di stato.

• Il criterio ">=500" conta ogni errore lato server.

• Dividere per COUNTA dà la quota su tutte le richieste. Formatta la cella come percentuale.

Questo è monitoraggio: un numero, una soglia. Ora la parte da observability. Quale servizio è responsabile?

=QUERY(A1:D5001, "select B, count(C) where C >= 500 group by B order by count(C) desc", 1)

Questa formula funziona solo in Google Sheets, perché QUERY non ha un equivalente in Excel. Gli argomenti:

• I dati sono in A1:D5001, intestazioni comprese.

• Il testo è una piccola query in stile SQL: conta gli errori per servizio, dal più frequente al meno frequente.

• L'ultimo 1 indica che c'è una sola riga di intestazione.

In Excel 365 ottieni lo stesso risultato con un'altra ricetta:

=LET(s, FILTER(B2:B5001, C2:C5001>=500), u, UNIQUE(s), HSTACK(u, COUNTIF(s, u)))

Serve Excel 365 o Excel 2021, perché FILTER, UNIQUE e HSTACK non esistono in Excel 2016. Le versioni più vecchie sono servite meglio da una tabella pivot.

Per le richieste lente, il 95° percentile è più onesto della media:

=PERCENTILE(D2:D5001, 0.95)

Se il tempo medio di risposta è 180 ms ma il 95° percentile è 2,400 ms, un utente su venti sta passando una brutta giornata. La media nasconde proprio questo, ed è la trappola che gli strumenti di observability cercano di aiutarti a evitare.

Biscuit l'ha già recuperata per te, se la formula è la parte che dimentichi sempre. Formula.dog trasforma una descrizione in linguaggio naturale in formule come queste.

Dove si vede l'observability in una giornata normale

Non devi gestire server per imbatterti nell'observability. Lo fa un responsabile del supporto che si chiede perché i ticket sono raddoppiati martedì. Lo fa un analista finanziario che riconduce uno scostamento a una singola fattura di un fornitore, o un addetto alle operations che scopre che un import notturno ha saltato un file in silenzio.

Nel software le stesse domande diventano più pressanti perché i sistemi sono distribuiti. Un clic su un pulsante può toccare un API gateway, un servizio di autenticazione, un database e un fornitore di pagamenti. Quando fallisce, il messaggio d'errore che vedi raramente è il punto da cui è partito tutto. Una traccia mostra la catena intera, con l'anello lento o rotto evidenziato, così nessuno deve tirare a indovinare.

Tre termini ricorrono in continuazione, quindi eccoli in parole semplici:

• Strumentazione è aggiungere al codice la parte che emette telemetria. Pensala come aggiungere a un report una colonna con timestamp e ID che prima non aveva.

• Cardinalità è quanti valori distinti può assumere un campo. La regione ha bassa cardinalità, l'ID utente ha cardinalità altissima. I campi ad alta cardinalità rispondono alle domande più precise e costano di più da conservare.

• SLO (service level objective) è un obiettivo che ti dai, per esempio "il 99.5% dei pagamenti si completa in meno di due secondi". Trasforma una preoccupazione vaga in un numero che puoi tenere sotto controllo.

Perché una montagna di dashboard non è observability

Ecco l'opinione che dà fastidio ai vendor: avere tutti e tre i segnali non vuol dire avere observability. Se le metriche stanno in uno strumento, i log in un altro e le tracce in un terzo, qualcuno deve allinearli a mano alle 2 di notte. È l'equivalente di tre cartelle di lavoro senza una colonna ID in comune.

Il test è semplice. Quando succede qualcosa di inatteso, puoi fare una domanda nuova ai tuoi dati senza rilasciare nuovo codice? Se la risposta è "dovremmo aggiungere log e rifare il deploy", hai del monitoraggio con qualche passaggio in più.

Due cose fanno la differenza nella pratica:

• Contesto su ogni evento. Ogni riga di log porta un ID di richiesta, il nome del servizio e la versione, così puoi raggruppare e filtrare dopo. È la colonna ID che vorresti avere in ogni export.

• Dettaglio conservato abbastanza a lungo. I dati ad alta cardinalità (ID utente, ID ordine) sono dove si nascondono le risposte, ed è anche ciò che fa salire la bolletta.

Gli strumenti che si usano davvero e cosa costano

Non serve comprare nulla per capire l'idea, ma il mercato vale la pena di conoscerlo.

OpenTelemetry è lo standard aperto per produrre telemetria, non un posto dove conservarla o visualizzarla. Strumenti una volta sola e mandi i dati dove preferisci.

Grafana Cloud è costruito su standard aperti e ha un piano gratuito con 10,000 serie di metriche attive e 50 GB al mese di log, tracce e profili. Puoi anche installare in autonomia lo stack open source, a patto di assemblare tu Prometheus, Loki e Tempo.

Datadog è l'opzione chiavi in mano: installi l'agente, ottieni dashboard funzionanti in pochi minuti e un unico posto per infrastruttura, APM e log. Il problema è la fatturazione. Il prezzo per host (circa $15 per host al mese solo per l'infrastruttura) più i costi separati per log e metriche personalizzate può salire in fretta oltre circa 50 host, e non esiste un piano gratuito permanente.

New Relic sta a metà come prezzo: 100 GB di dati ingeriti al mese gratis, poi $0.40 per GB, con un utente piattaforma completo incluso.

Vale la spesa se hai un piccolo team di piattaforma e nessuna voglia di gestire un'infrastruttura che monitora la tua infrastruttura. Lascia perdere se hai due server e uno sviluppatore. Un buon formato di log e le formule qui sopra ti porteranno sorprendentemente lontano.

Cosa fare lunedì se non sei un ingegnere

Potresti non toccare mai una traccia in vita tua. Ma il ragionamento da observability si trasferisce bene a chiunque riporti numeri per lavoro.

1. Aggiungi un ID a ogni export. Una colonna su cui fare join batte qualsiasi formula furba.

2. Conserva le righe grezze. Non incollare valori sopra la scheda di dettaglio. I riepiloghi sono metriche, le righe grezze sono log.

3. Scrivi cosa significa "normale". Una soglia che non hai mai definito non può far scattare nessun allarme.

4. Fatti la terza domanda. "I ricavi sono in calo" è l'allarme. "In calo dove?" è la metrica. "In calo per colpa di quali righe?" è observability.

Fai questo e il prossimo totale strano nel tuo foglio richiederà dieci minuti per essere spiegato, invece di un pomeriggio.

Le risposte più brevi alle domande più comuni sono nella FAQ qui sotto. Se ne ricordi una sola: l'observability non è un prodotto che compri. È quanto bene i dati emessi dal tuo sistema ti permettono di rispondere a domande che non avevi previsto.