Il sistema funziona. Fino al momento in cui smette di farlo
Immagina un negozio online in cui i clienti possono consultare i prodotti, aggiungerli al carrello e procedere al pagamento. Il server risponde, il sito si apre e gli indicatori di base dell’infrastruttura non mostrano alcun problema serio. In apparenza tutto funziona correttamente.
Nel frattempo, però, parte dei clienti non riesce a completare l’ordine. Per alcuni il pagamento richiede diversi secondi, per altri compare un errore. Il team tecnico riceve segnalazioni, ma non sa ancora se la causa sia il gateway di pagamento, il database, l’ultimo aggiornamento dell’applicazione oppure un problema di comunicazione tra servizi.
È una situazione in cui il monitoring tradizionale può rivelarsi insufficiente. Può indicare che il numero di errori è aumentato o che il tempo di risposta si è allungato, ma non sempre fornisce le informazioni necessarie per individuare rapidamente la causa.
È proprio a questa lacuna che risponde l’observability, cioè l’osservabilità del sistema. Il suo obiettivo non è solo stabilire che l’applicazione non funziona correttamente. Si tratta della possibilità di analizzarne il comportamento, ricostruire la sequenza degli eventi e trovare l’origine del problema, anche quando in precedenza non era stato previsto uno scenario di guasto specifico.
Monitoring e observability - obiettivi simili, possibilità diverse
Monitoring e observability sono strettamente collegati, ma non significano la stessa cosa.
Il monitoring consiste nella raccolta sistematica e nell’analisi dei dati sullo stato dell’applicazione e dell’infrastruttura. Consente di monitorare parametri specifici, rilevare deviazioni dalle norme stabilite e attivare alert quando si verifica una situazione che richiede un intervento.
Esempi di domande a cui risponde il monitoring sono:
- Il server è disponibile?
- Qual è il tempo medio di risposta dell’API?
- Il numero di errori HTTP 500 supera la soglia stabilita?
- Qual è l’utilizzo di memoria e processore?
- La coda dei task cresce più rapidamente di quanto il sistema riesca a gestire?
L’observability va oltre. Permette di analizzare i dati provenienti da diverse parti del sistema e di collegarli in un contesto che aiuta a capire perché si è verificato un determinato comportamento.
Si può sintetizzare in tre domande:
- Monitoring: c’è qualcosa che non va?
- Diagnostica: dov’è comparso il problema?
- Observability: che cosa è successo, perché e qual è stato l’impatto sul funzionamento del sistema?
L’osservabilità non sostituisce il monitoring. È un approccio che utilizza il monitoring e dati telemetrici adeguatamente preparati per consentire un’analisi più approfondita del comportamento dell’applicazione. OpenTelemetry descrive l’observability come la possibilità di porre al sistema domande sul suo comportamento in base a segnali come log, metriche e tracce distribuite. <Cite ref="turn154932search0"/>
I tre pilastri dell’observability: log, metriche e tracing
La base dell’osservabilità sono tre tipi di dati telemetrici: logs, metrics e traces. Ognuno mostra un aspetto diverso del funzionamento dell’applicazione. Solo la loro correlazione offre un quadro più ampio della situazione.
1. Log - che cosa è successo nell’applicazione?
I log (logs) sono registrazioni strutturate degli eventi generati dall’applicazione, dal sistema operativo, dai server, dai database e da altri elementi dell’infrastruttura.
Possono registrare, per esempio:
- l’inizio e la fine di un processo,
- il tentativo di accesso di un utente,
- l’invio di una richiesta a un’API esterna,
- un errore di convalida dei dati,
- una transazione fallita,
- un’eccezione sollevata dall’applicazione,
- il cambiamento di stato di un ordine.
Un log può contenere un timestamp, un livello di gravità, il nome del servizio, un messaggio, un identificatore di richiesta e attributi aggiuntivi che descrivono l’evento.
È importante distinguere tra log testuali e log strutturati. Una registrazione testuale può apparire così:Errore durante l’elaborazione dell’ordine
Un messaggio del genere segnala la presenza di un problema, ma dice poco sul suo contesto. Un log strutturato può invece contenere campi separati, come l’identificatore dell’ordine, il nome dell’operazione, il codice di errore, il tempo di esecuzione e l’identificatore della traccia. In questo modo i dati possono essere filtrati, raggruppati e analizzati automaticamente.
Buona pratica: i log dovrebbero essere progettati pensando all’analisi successiva, e non solo alla registrazione dei messaggi. Vale la pena usare una nomenclatura coerente, livelli di gravità e identificatori di correlazione che consentano di collegare eventi provenienti da componenti diversi.
Allo stesso tempo, il logging richiede buon senso. Registrare ogni operazione in modo completo può generare enormi quantità di dati, aumentare i costi di archiviazione e rendere più difficile trovare le informazioni rilevanti. Altrettanto importante, i log non dovrebbero rivelare password, token di accesso, dati delle carte di pagamento o altre informazioni sensibili. È necessario applicare mascheramento, controllo degli accessi, periodi di retention adeguati e regole per un trattamento sicuro dei dati.
2. Metriche - come si comporta il sistema nel tempo?
Le metriche (metrics) sono dati numerici aggregati che descrivono lo stato, le prestazioni e il comportamento del sistema in un determinato periodo.
Esempi di metriche includono:
- il numero di richieste gestite al secondo,
- la percentuale di richieste concluse con errore,
- il tempo di risposta dell’API,
- l’utilizzo di CPU e memoria,
- il numero di sessioni attive,
- la lunghezza della coda dei task,
- il numero di transazioni completate,
- il tempo di attesa per la connessione al database.
Il loro maggiore vantaggio è la possibilità di osservare i trend. Un singolo errore può essere un incidente isolato, ma un tempo di risposta che cresce gradualmente, un aumento delle transazioni fallite o una coda dei task che si allunga possono indicare un problema in fase di sviluppo.
Nella pratica, le metriche aiutano a rispondere non solo alla domanda se l’applicazione funziona, ma anche se le sue prestazioni corrispondono alle aspettative degli utenti e ai requisiti di business.
Particolarmente utili sono i percentili del tempo di risposta, ad esempio p95 e p99. La media può nascondere una situazione in cui la maggior parte degli utenti riceve una risposta rapidamente, ma una piccola parte sperimenta ritardi molto elevati. I percentili mostrano quanto dura la gestione delle richieste più lente e aiutano a individuare problemi invisibili nei valori medi.
Buona pratica: scegli metriche che abbiano significato per l’utente e per il processo di business. La sola informazione sul carico della CPU non dirà se il cliente può effettuare un ordine. Vale quindi la pena monitorare anche gli indicatori legati alle funzioni chiave, come l’efficacia dei pagamenti, il tempo di evasione dell’ordine o la disponibilità delle operazioni più importanti.
3. Tracing - quale percorso ha seguito la richiesta?
Il tracing, in particolare il distributed tracing, cioè il tracciamento distribuito, consente di seguire il percorso di una singola richiesta attraverso i diversi componenti del sistema.
In un'applicazione moderna, un'operazione dell'utente può comprendere molte fasi. Il clic sul pulsante «Effettua ordine» può avviare una richiesta nel browser, che passa all'API, poi al servizio ordini, al database, al sistema di magazzino e a un operatore di pagamento esterno.
Se il processo rallenta, la sola informazione sul tempo di risposta dell'intera API può non bastare. Il tracing consente di suddividere questo tempo nelle singole operazioni e vedere quale fase è responsabile del ritardo.
L'elemento fondamentale di una traccia (trace) è lo span, cioè la registrazione di una singola operazione. Uno span può contenere l'ora di inizio e di fine, il nome dell'operazione, lo stato e i metadati. Gli span correlati formano una traccia che mostra il percorso dell'intera richiesta.
Ad esempio:
- L'API riceve la richiesta e la inoltra.
- Il servizio ordini verifica i dati.
- Il database salva l'ordine.
- Il servizio di magazzino verifica la disponibilità del prodotto.
- Il gateway di pagamento esterno elabora la transazione.
- L'applicazione restituisce il risultato all'utente.
Se l'intero processo dura 8 secondi, il tracing può mostrare che 6,5 secondi sono stati occupati dalla risposta del gateway di pagamento esterno, mentre le altre operazioni sono andate a buon fine. Il team ottiene così un punto concreto da approfondire, invece di iniziare la diagnosi da componenti casuali.
Il tracing è particolarmente utile nelle architetture a microservizi, nei sistemi distribuiti, nelle applicazioni basate su code e nelle soluzioni che integrano molti servizi esterni. <Cite ref="turn154932search0"/>
Alert - l'informazione deve raggiungere la persona giusta
I dati di telemetria sono utili solo quando consentono di agire. Per questo una parte importante dell'observability è il sistema di alerting.
Un alert è una notifica di un evento o di uno stato che richiede attenzione. Può essere attivato al superamento di una soglia di una metrica, al rilevamento di un determinato pattern di errori o quando si constata che una funzione chiave dell'applicazione non funziona come previsto.
Tuttavia, non ogni aumento del carico dovrebbe generare un allarme. Se il sistema gestisce regolarmente molto traffico nelle ore di punta, una notifica per ogni aumento del numero di richieste genererebbe rumore informativo. Troppi alert portano a ignorarli e, di conseguenza, a non accorgersi di un incidente realmente importante.
Vale quindi la pena stabilire:
- quali eventi richiedono una reazione immediata,
- quali problemi possono essere analizzati in modalità operativa standard,
- chi è responsabile di un determinato tipo di alert,
- quali informazioni dovrebbe contenere la notifica,
- quali azioni intraprendere dopo averla ricevuta.
Un buon punto di partenza è definire gli alert in base all'impatto sull'utente e agli obiettivi di affidabilità, e non solo sui parametri dell'infrastruttura. Ad esempio, un alert su un aumento del tasso di pagamenti falliti può avere un'importanza commerciale maggiore di un breve picco nell'utilizzo della CPU.
Un alert dovrebbe portare all'azione. Se non si sa chi deve gestirlo né cosa fare, è solo un altro messaggio nel sistema.
Esempio pratico: come l'observability aiuta a trovare la causa di un guasto?
Supponiamo che gli utenti di un'applicazione B2B segnalino che la generazione dei report richiede molto più tempo del solito. Il monitoring rileva un aumento del tempo di risposta e attiva un alert.
Il team inizia l'analisi:
- Le metriche indicano che il problema riguarda soprattutto i report che coprono ampi intervalli di dati. Le altre funzionalità operano nella norma.
- Il tracing mostra che il ritardo maggiore si verifica durante l'esecuzione della query al database.
- I log contengono i dettagli della query, i suoi parametri operativi e le informazioni sugli errori, senza rivelare dati sensibili.
- La correlazione dei dati consente di collegare una traccia specifica ai relativi record nei log e alle modifiche visibili nei grafici delle metriche.
- L'analisi della modifica indica che il problema è comparso dopo il rilascio della nuova versione del report, che ha iniziato a eseguire una query costosa.
Grazie a ciò, il team non deve controllare alla cieca l'intera infrastruttura. Può concentrarsi su un'operazione specifica, confrontare il comportamento prima e dopo il rilascio e poi ottimizzare la query o annullare la modifica.
L'observability non elimina i guasti e non garantisce che ogni causa venga trovata automaticamente. Permette però di limitare l'area di ricerca, ridurre il tempo di diagnosi e basare le decisioni sui dati anziché sulle ipotesi.
Correlazione dei dati - il massimo valore emerge insieme
Log, metriche e tracing sono utili singolarmente, ma il loro vero valore emerge quando possono essere collegati tra loro.
Immaginiamo che la dashboard mostri un improvviso aumento del tempo di risposta. La metrica indica quando e in quale scala è comparso il problema. La trace mostra quali operazioni componevano la richiesta lenta. I log permettono di verificare quali eventi si sono verificati in una fase specifica.
Affinché ciò sia possibile, il sistema dovrebbe trasferire in modo coerente il contesto della richiesta tra i servizi. Gli identificatori di trace e span possono essere usati per collegare le voci di log alle tracce. Vale anche la pena mantenere informazioni coerenti sul nome del servizio, sull'ambiente, sulla versione dell'applicazione e su altri attributi che descrivono la fonte dei dati.
Senza correlazione, il team può avere accesso a molti dashboard, file e strumenti, ma continuare comunque a perdere tempo nell'identificare manualmente quali eventi siano collegati tra loro. OpenTelemetry indica la correlazione tra log, tracce e contesto delle risorse come elemento essenziale per costruire una telemetria utile. <Cite ref="turn154932search1"/>
OpenTelemetry - uno standard comune per i dati di telemetria
L'adozione dell'observability non deve implicare la dipendenza da un unico fornitore di strumenti. Una delle soluzioni che favoriscono l'interoperabilità è OpenTelemetry (OTel) - un insieme aperto di standard, API, librerie e strumenti per strumentare, generare, raccogliere ed esportare dati di telemetria.
OpenTelemetry consente all'applicazione di emettere metriche, log e tracce in un modello coerente. I dati possono poi essere inoltrati al backend di observability scelto, che si occupa di archiviarli, cercarli, visualizzarli e analizzarli.
Un elemento importante dell'ecosistema è OpenTelemetry Collector. Può ricevere dati da varie sorgenti, elaborarli, arricchirli con contesto aggiuntivo ed esportarli ai sistemi configurati. In questo modo l'applicazione non deve essere direttamente collegata a ogni strumento usato per l'analisi.
Questo approccio è particolarmente utile quando l'azienda utilizza molte tecnologie, sviluppa l'architettura del sistema o vuole mantenere la possibilità di cambiare fornitore di strumenti. Lo standard, da solo, però, non garantisce un'observability completa. Restano necessari una corretta strumentazione, una strategia ben pensata di raccolta dei dati, dashboard adeguati, alert e procedure di risposta. <Cite ref="turn154932search3"/>
Quando vale la pena adottare l'observability?
L'observability può essere utile sia nei grandi sistemi distribuiti sia nelle applicazioni più piccole, in cui un'interruzione o un difetto difficile da rilevare ha conseguenze business significative.
In particolare, vale la pena considerare questo approccio quando:
- l'applicazione è composta da molti servizi o integrazioni,
- i problemi si verificano in modo irregolare ed è difficile riprodurli,
- gli utenti segnalano errori che non si vedono nei test standard,
- il tempo di diagnosi degli incidenti è troppo lungo,
- le successive distribuzioni causano effetti difficili da prevedere,
- l'azienda sta sviluppando il sistema e ha bisogno di dati per pianificare le prestazioni,
- l'applicazione supporta processi chiave di vendita, operativi o finanziari,
- il team ha bisogno di comprendere meglio l'impatto dei servizi esterni sul funzionamento dell'intera soluzione.
Tuttavia, ciò non significa che ogni sito web necessiti di un ambiente di telemetria esteso. In un servizio piccolo e semplice, possono essere sufficienti log di base, monitoraggio della disponibilità e alcune metriche chiave. L'ambito della soluzione dovrebbe corrispondere alla complessità dell'applicazione, alla scala del traffico, ai requisiti di affidabilità e ai costi di potenziali interruzioni.
Quando l'observability può essere un eccesso di forma rispetto alla sostanza?
L'implementazione di strumenti avanzati senza un obiettivo chiaramente definito può generare più costi che benefici.
Gli errori più comuni includono:
- Raccogliere tutto senza un piano. Un eccesso di dati aumenta i costi e rende più difficile trovare le informazioni rilevanti per la diagnosi.
- Mancanza di domande a cui il sistema deve rispondere. Le dashboard possono apparire impressionanti, ma non aiutare a risolvere i problemi reali.
- Inviare alert per ogni deviazione. Un numero eccessivo di notifiche provoca affaticamento da alert e aumenta il rischio di non notare un incidente.
- Mancanza di responsabilità nella risposta. Anche un problema ben rilevato può durare a lungo se nessuno sa chi debba occuparsene.
- Mancanza di protezione dei dati. La telemetria può contenere informazioni sensibili, identificativi degli utenti o dati operativi che richiedono accesso limitato e un'adeguata conservazione.
- Ignorare il costo dell'instrumentazione. La raccolta di tracce e log dettagliati su larga scala può influire sulle prestazioni dell'applicazione e generare costi significativi di archiviazione ed elaborazione.
- Considerare lo strumento come una soluzione pronta all'uso. La semplice installazione della piattaforma non garantisce una corretta instrumentazione né un processo di diagnosi efficiente.
L'observability richiede quindi non solo tecnologia, ma anche decisioni organizzative: quali dati servono, chi li analizza, come reagisce il team e in che modo le conclusioni tratte dagli incidenti si traducono in cambiamenti nel sistema.
Come pianificare l'implementazione dell'observability?
Il modo più sicuro è sviluppare l'osservabilità per fasi, iniziando dai processi e dalle funzioni il cui guasto ha il maggiore impatto sugli utenti e sull'azienda.
1. Definisci i processi aziendali chiave
Identifica le operazioni più importanti, come l'accesso, l'invio degli ordini, i pagamenti, la generazione di documenti o la sincronizzazione dei dati. Queste dovrebbero essere il punto di partenza per definire cosa significhi il corretto funzionamento dell'applicazione.
2. Stabilisci gli indicatori di affidabilità
Scegli le metriche che riflettono l'esperienza dell'utente, ad esempio la disponibilità delle funzioni chiave, il tempo di risposta o la percentuale di operazioni completate con successo. Per i servizi importanti si può definire un SLI (Service Level Indicator), cioè un indicatore del livello di servizio, e un SLO (Service Level Objective), cioè un obiettivo relativo a tale indicatore.
3. Cura i log strutturati
Uniforma il formato dei log, i livelli di importanza e gli attributi di base. Assicurati di avere identificativi di correlazione e una politica di eliminazione o mascheramento dei dati sensibili. I log devono essere leggibili per il team e processabili dagli strumenti.
4. Aggiungi il tracing nei percorsi critici
Inizia dai processi che coinvolgono più servizi, database o integrazioni esterne. Traccia il percorso della richiesta attraverso il sistema e cura la propagazione del contesto tra i componenti.
5. Costruisci dashboard intorno a domande concrete
Invece di creare un unico grande pannello, prepara viste che rispondano alle esigenze dei diversi ruoli. Il team tecnico può aver bisogno di informazioni su errori e ritardi, mentre il product owner di dati sull'efficacia dei processi chiave e sull'impatto dei guasti sugli utenti.
6. Progetta alert e procedure di risposta
Definisci soglie, priorità, responsabili e istruzioni operative. Un alert dovrebbe contenere il contesto che aiuta ad avviare rapidamente la diagnosi, e non solo informare del superamento di un valore.
7. Testa l'observability
Verifica se il team è in grado di trovare la causa di un esempio di errore sulla base dei dati disponibili. Si possono eseguire test controllati di guasto in ambiente di test o esercitazioni di risposta agli incidenti. Vale anche la pena verificare se gli alert si attivano quando dovrebbero.
8. Sviluppa la soluzione in base agli incidenti
Dopo ogni problema rilevante, vale la pena verificare quali informazioni erano disponibili, cosa mancava e come si può migliorare l'instrumentazione, l'alerting o le procedure. L'observability non è un progetto una tantum, ma un processo di miglioramento della conoscenza del funzionamento del sistema.
Costi e sicurezza - due aspetti che non si possono ignorare
I dati di telemetria hanno un costo. I costi possono derivare dall'instrumentazione, dal trasferimento, dall'indicizzazione, dall'archiviazione, dalla conservazione e dall'analisi dei dati. Nei sistemi ad alto traffico, può essere particolarmente costoso raccogliere tutte le tracce o log molto dettagliati.
Per questo conviene applicare una conservazione adattata alle esigenze, il filtraggio dei dati, il campionamento delle tracce (sampling) e diversi livelli di dettaglio a seconda dell'ambiente. Ad esempio, un sistema in produzione può raccogliere dati completi per gli errori e per alcune operazioni critiche selezionate, mentre una parte delle richieste corrette può essere campionata per ridurre il volume.
Altrettanto importante è la protezione dei dati. Log e tracce possono contenere inconsapevolmente dati personali, identificativi di sessione, frammenti di query o informazioni sulla struttura dell'infrastruttura. È necessario limitare l'accesso alla telemetria, rimuovere i dati non necessari, mascherare le informazioni sensibili e controllare i periodi di conservazione. Vale inoltre la pena considerare i sistemi di observability come parte dell'ambiente di produzione, che a sua volta richiede protezioni, backup e controllo degli accessi.
L'observability come strumento di gestione, non solo di diagnostica
Sebbene l'osservabilità sia più spesso associata al lavoro di sviluppatori, DevOps e amministratori, il suo valore va oltre l'ambito IT.
I dati sui tempi di risposta, sugli errori, sulla disponibilità e sull'efficacia dei processi possono aiutare l'azienda a capire quali elementi della tecnologia supportano l'attività e quali la limitano. Consentono di identificare problemi ricorrenti, valutare gli effetti delle modifiche e pianificare lo sviluppo sulla base del comportamento reale del sistema.
Se, ad esempio, il sistema degli ordini rallenta regolarmente in determinate ore, i dati di telemetria possono aiutare a stabilire se sia necessaria l'ottimizzazione delle query, un cambiamento nel modo di elaborare i task oppure un potenziamento dell'infrastruttura. Invece di investire in risorse aggiuntive sulla base dell'intuizione, l'azienda può prima identificare il vero collo di bottiglia.
L'osservabilità supporta anche l'analisi degli effetti dei rilasci. Confrontare metriche, trace e log prima e dopo una modifica consente di individuare più rapidamente le regressioni e valutare se l'aggiornamento ha prodotto l'effetto atteso.
Tuttavia, non bisogna identificare l'osservabilità con il processo decisionale automatico. I dati mostrano il comportamento del sistema, ma la loro interpretazione richiede la conoscenza dell'architettura, dei processi aziendali e del contesto dell'incidente specifico.
Glossario dei termini
- Observability (osservabilità) - la capacità di comprendere il comportamento interno di un sistema sulla base dei dati che emette.
- Monitoring - il monitoraggio continuo di parametri selezionati e il rilevamento di stati specifici che richiedono attenzione.
- Telemetry (telemetria) - dati raccolti e trasmessi da applicazioni e infrastruttura per analizzarne il funzionamento.
- Logs (log) - registrazioni degli eventi che si verificano nell'applicazione o nell'infrastruttura.
- Metrics (metriche) - misurazioni numeriche dello stato, delle prestazioni o del comportamento del sistema nel tempo.
- Tracing - il tracciamento del percorso delle operazioni attraverso i componenti dell'applicazione.
- Distributed tracing - il tracciamento di una singola richiesta in un sistema composto da molti servizi o processi.
- Span - il registro di una singola operazione che fa parte di un trace.
- Trace - un insieme di span correlati che rappresentano il percorso di un'operazione.
- Alert - una notifica di uno stato o evento rilevato che richiede una reazione.
- SLI - un indicatore che misura un aspetto specifico del funzionamento di un servizio.
- SLO - un obiettivo definito per un indicatore selezionato di affidabilità.
- Sampling - una tecnica per limitare la quantità di dati di telemetria raccolti selezionando una parte rappresentativa degli eventi.
- OpenTelemetry - un insieme aperto di standard e strumenti a supporto della strumentazione e dell'esportazione dei dati di telemetria.
Riepilogo
Un guasto dell'applicazione non inizia sempre con un server non disponibile o un messaggio di errore. A volte il sistema funziona formalmente, ma una funzione chiave diventa troppo lenta, una parte delle transazioni non va a buon fine oppure l'integrazione fallisce solo in condizioni specifiche.
Il monitoring aiuta a rilevare le anomalie. L'osservabilità permette di capire cosa ha portato alla loro comparsa e quale sia stato il loro impatto sul funzionamento dell'applicazione. Log, metriche, tracing e alert ben progettati creano insieme la base per una diagnostica più efficace, uno sviluppo consapevole e la riduzione del rischio operativo.
Non si tratta di raccogliere quanti più dati possibile né di creare dashboard sempre più complesse. Si tratta di non chiedersi, nel momento in cui si verifica un problema, solo: «Il sistema funziona?», ma di poter stabilire: «Cosa è successo esattamente nel sistema, perché e cosa dovremmo fare dopo?»
Un'applicazione matura non è solo quella che funziona. È anche quella il cui comportamento si può comprendere, diagnosticare e migliorare.
