Observability
L'observability (osservabilità) è il grado in cui lo stato interno di un sistema può essere dedotto dai suoi output esterni, principalmente la telemetria come log, metriche e tracce. Un sistema è osservabile quando puoi rispondere a domande nuove e impreviste sul suo comportamento senza dover rilasciare nuovo codice per emettere più dati. Il termine deriva dalla teoria del controllo, dove l'osservabilità misura quanto bene gli stati interni siano ricostruibili dagli output.
Telemetria
La telemetria è l'insieme dei dati che un sistema emette sul proprio comportamento, raccolti e trasmessi a un backend per l'analisi. Nella pratica moderna è raggruppata in segnali: log, metriche, tracce e, sempre più, profili continui. OpenTelemetry standardizza come questa telemetria viene generata, descritta ed esportata.
Metrica
Una metrica è una misurazione numerica catturata nel tempo, come il tasso di richieste, il conteggio degli errori o la latenza. Le metriche sono economiche da archiviare e aggregare perché sono numeri pre-aggregati con dimensioni a bassa cardinalità, il che le rende ideali per dashboard e alerting. I tipi classici di metrica sono counter, gauge e histogram.
Log
Un log è un record timestampato, tipicamente immutabile, di un evento discreto, che va da righe di testo non strutturato a JSON strutturato. I log portano un contesto di alto dettaglio difficile da pre-aggregare, il che li rende ottimi per il debugging di eventi specifici ma costosi ad alti volumi. Il logging strutturato allega campi chiave-valore così i log diventano interrogabili e correlabili.
Traccia (Trace)
Una traccia rappresenta il percorso end-to-end di una singola richiesta mentre attraversa un sistema distribuito, ed è composta da uno o più span. Mostra le relazioni causali e temporali tra le operazioni attraverso i confini dei servizi, rendendola lo strumento principale per comprendere la latenza nei microservizi. Ogni traccia è identificata da un trace ID univoco propagato tra i servizi.
Span
Uno span è l'unità base di una traccia: una singola operazione nominata e temporizzata, come un handler HTTP, una query a database o una chiamata RPC. Gli span portano un tempo di inizio, una durata, attributi, eventi, uno status e un riferimento allo span padre, formando un albero o un grafo orientato all'interno di una traccia. Il primo span di una traccia è lo span radice (root span).
Tracing distribuito
Il tracing distribuito è la pratica di seguire una richiesta attraverso tutti i servizi che tocca, propagando un contesto condiviso (trace ID e span ID) tra di essi. Ricostruisce l'intero grafo delle chiamate così gli ingegneri possono individuare quale servizio o operazione ha contribuito a latenza o errori. W3C Trace Context è il formato standard degli header per propagare questo contesto su HTTP.
Cardinalità
La cardinalità è il numero di valori unici che una dimensione o etichetta può assumere e, nelle metriche, è il numero di serie temporali uniche prodotte da tutte le combinazioni di etichette. Una cardinalità elevata (per esempio un'etichetta con ID utente) moltiplica drasticamente il costo di archiviazione e memoria ed è la causa più comune di sovraccarico del backend delle metriche. Scegliere etichette a bassa cardinalità è una competenza fondamentale nell'instrumentation.
Counter
Un counter è una metrica cumulativa che può solo aumentare (o azzerarsi al riavvio), usata per cose come il totale delle richieste servite o dei byte inviati. Quasi sempre leggi un counter tramite una funzione di rate piuttosto che il suo valore grezzo, perché il totale assoluto è raramente significativo di per sé. I reset vengono rilevati e gestiti dai motori di query come PromQL.
Gauge
Un gauge è una metrica che può salire o scendere, rappresentando un valore campionato in un istante, come l'uso corrente della memoria, la profondità di una coda o le connessioni attive. A differenza di un counter, il valore istantaneo di un gauge è direttamente significativo. I gauge sono tipicamente aggregati con funzioni come media, min, max o somma.
Histogram
Un histogram campiona le osservazioni (come le durate delle richieste) in bucket configurabili ed espone anche un conteggio e una somma, abilitando l'analisi della distribuzione della latenza e la stima dei quantili. Gli histogram di Prometheus espongono counter di bucket cumulativi aggregabili tra istanze prima di calcolare i quantili. Gli histogram nativi (esponenziali) riducono la necessità di scegliere a priori i confini dei bucket.
Quantile
Un quantile è un punto di taglio che divide una distribuzione in modo che una data frazione di osservazioni vi cada sotto; il quantile 0,99 (p99) è il valore sotto il quale si trova il 99% delle osservazioni. I quantili descrivono il comportamento di coda che le medie nascondono, motivo per cui gli SLO di latenza sono di solito espressi a p95 o p99. Con gli histogram di Prometheus i quantili si stimano dai bucket con la funzione histogram_quantile.
SLI (Service Level Indicator)
Un SLI è una misura quantitativa accuratamente definita di un aspetto del livello di servizio fornito, come il rapporto tra richieste riuscite e richieste totali. I buoni SLI sono espressi come rapporto tra eventi buoni ed eventi validi, il che li mantiene tra 0 e 100%. Gli SLI sono le misurazioni grezze su cui gli SLO fissano dei target.
SLO (Service Level Objective)
Un SLO è un valore o intervallo target per un SLI su una finestra temporale, per esempio "il 99,9% delle richieste riesce su 30 giorni". Gli SLO traducono l'affidabilità in un numero su cui l'intera organizzazione può ragionare e da bilanciare con la velocità di rilascio. Sono target interni, tipicamente più stringenti di qualsiasi SLA promesso esternamente.
SLA (Service Level Agreement)
Un SLA è un contratto con utenti o clienti che specifica le conseguenze (spesso economiche) del mancato rispetto di un livello di servizio. Gli SLA sono accordi di business, mentre gli SLO sono i target ingegneristici interni fissati deliberatamente più stretti così i problemi vengono colti prima della violazione dello SLA. Non ogni servizio ha bisogno di uno SLA, ma la maggior parte beneficia di SLO.
Error Budget
Un error budget è la quantità di inaffidabilità che uno SLO permette - per uno SLO di disponibilità del 99,9% è il restante 0,1% di guasti consentiti sulla finestra. Riformula l'affidabilità come un budget spendibile in rilasci ed esperimenti: quando il budget è esaurito, il team dà priorità alla stabilità rispetto alle nuove funzionalità. Gli error budget creano una regola decisionale condivisa e basata sui dati tra sviluppo e operations.
Burn Rate
Il burn rate è la velocità con cui un servizio consuma il suo error budget rispetto al tasso che lo esaurirebbe esattamente nella finestra dello SLO. Un burn rate di 1 significa che il budget durerà esattamente la finestra; un burn rate di 10 significa che si esaurirà in un decimo del tempo. Gli alert multi-finestra e multi-burn-rate avvisano rapidamente per consumi severi e lentamente per quelli graduali, bilanciando precisione e recall.
Golden Signals
I quattro golden signals della SRE di Google sono latenza, traffico, errori e saturazione - l'insieme minimo di metriche raccomandato per monitorare un servizio rivolto agli utenti. La latenza misura quanto durano le richieste, il traffico misura la domanda, gli errori misurano le richieste fallite e la saturazione misura quanto è pieno la risorsa più vincolata. Strumentare questi quattro dà un'ampia copertura con poco sforzo.
Metodo RED
Il metodo RED monitora un servizio con tre metriche: Rate (richieste al secondo), Errors (richieste fallite al secondo) e Duration (distribuzione della latenza). È un'impostazione centrata sulle richieste, adatta a strumentare microservizi e carichi guidati dalle richieste. RED complementa USE, che è centrato sulle risorse.
Metodo USE
Il metodo USE, coniato da Brendan Gregg, caratterizza ogni risorsa con Utilization, Saturation ed Errors. È pensato per diagnosticare i colli di bottiglia di sistema e hardware (CPU, memoria, disco, rete) chiedendo, per ogni risorsa, quanto è occupata, quanto lavoro extra è in coda e se produce errori. USE è centrato sulle risorse e si abbina naturalmente al metodo RED, centrato sulle richieste.
OpenTelemetry (OTel)
OpenTelemetry è un progetto CNCF e uno standard vendor-neutral che fornisce API, SDK e strumenti per generare, raccogliere ed esportare log, metriche e tracce. Definisce un modello dati e un protocollo comuni così l'instrumentation è disaccoppiata da qualsiasi backend specifico, permettendoti di cambiare vendor senza re-strumentare. È il risultato della fusione dei precedenti progetti OpenTracing e OpenCensus.
OTLP (OpenTelemetry Protocol)
OTLP è l'OpenTelemetry Protocol, il formato standard per trasmettere telemetria tra SDK, Collector e backend. È definito in Protocol Buffers e funziona su gRPC o HTTP, trasportando tracce, metriche e log in un unico formato unificato. La maggior parte dei backend di observability ora accetta OTLP nativamente.
OpenTelemetry Collector
L'OpenTelemetry Collector è un agente o gateway standalone vendor-agnostico che riceve, elabora ed esporta telemetria. La sua pipeline è costruita da receiver, processor ed exporter, permettendo di raggruppare (batch), filtrare, campionare, arricchire e distribuire i dati senza modificare il codice applicativo. Disaccoppia le applicazioni dai backend ed è il punto raccomandato per centralizzare le policy di telemetria.
Instrumentation
L'instrumentation è l'atto di aggiungere codice o configurazione che fa emettere telemetria a un sistema. È manuale quando scrivi span e metriche nel tuo codice, e automatica quando un agente o una libreria inietta telemetria nei framework noti senza modifiche al codice. Una buona instrumentation bilancia la copertura con il costo e la cardinalità.
Propagazione del contesto
La propagazione del contesto è il meccanismo che porta il contesto di traccia (e il baggage) attraverso i confini di processo e di servizio così gli span di servizi diversi si uniscono in un'unica traccia. Su HTTP avviene tipicamente con gli header W3C traceparent e tracestate. Senza propagazione ogni servizio produce tracce scollegate e si perde il quadro end-to-end.
W3C Trace Context
W3C Trace Context è uno standard che definisce gli header HTTP traceparent e tracestate per propagare gli identificatori di traccia tra i servizi in modo interoperabile. traceparent porta la versione, il trace ID, lo span ID padre e i trace flag; tracestate porta dati chiave-valore specifici del vendor. Standardizzare gli header permette a strumenti di vendor diversi di condividere una singola traccia.
Campionamento (Sampling)
Il campionamento è la pratica di registrare solo un sottoinsieme delle tracce per controllare costo e volume preservando un segnale rappresentativo. Il campionamento head-based decide all'inizio di una traccia, prima che l'esito sia noto; quello tail-based decide dopo il completamento della traccia, così può mantenere tutti gli errori e le richieste lente. La strategia giusta bilancia il costo con il rischio di scartare proprio le tracce di cui hai più bisogno.
Campionamento head-based
Il campionamento head-based prende la decisione di mantenere o scartare alla radice di una traccia, prima che l'esito della richiesta sia noto, e propaga quella decisione a tutti gli span a valle. È semplice ed economico e garantisce tracce complete, ma non può mantenere preferenzialmente errori o richieste lente perché la decisione avviene troppo presto. È spesso chiamato campionamento probabilistico quando basato su un rapporto fisso.
Campionamento tail-based
Il campionamento tail-based bufferizza tutti gli span di una traccia finché non è completa, poi applica regole per decidere quali tracce mantenere, come mantenere sempre le tracce con errori o con latenza sopra una soglia. Cattura le tracce più interessanti ma richiede di bufferizzare tracce complete (di solito nel Collector), il che costa memoria e complica le distribuzioni scalate orizzontalmente. È il modo standard per mantenere a costo accettabile le tracce rare ma importanti.
Exemplar
Un exemplar è un riferimento allegato a un data point di una metrica (tipicamente un bucket di histogram) che lo collega a una traccia specifica, di solito tramite un trace ID. Gli exemplar permettono di saltare da una metrica aggregata - per esempio un picco di latenza p99 - direttamente a una traccia di esempio che vi ha contribuito. Fanno da ponte tra i segnali delle metriche e delle tracce per un'analisi della causa più rapida.
Logging strutturato
Il logging strutturato emette gli eventi di log come record chiave-valore interpretabili dalla macchina (di solito JSON) invece che come testo libero. La struttura permette di filtrare, aggregare e correlare i log in modo affidabile - per esempio per trace_id o tenant - senza espressioni regolari fragili. È un prerequisito per trattare i log come dati interrogabili anziché come un muro di testo.
Livello di log
Un livello di log classifica la severità o importanza di un evento di log, con livelli comuni TRACE, DEBUG, INFO, WARN ed ERROR. I livelli permettono agli operatori di filtrare la verbosità dinamicamente, emettendo dettaglio in sviluppo e solo warning ed errori in produzione. Scegliere il livello giusto per ogni evento mantiene i log ricchi di segnale e a costo sostenibile.
Aggregazione
L'aggregazione è il processo di combinare molti data point di telemetria in valori riassuntivi, come sommare i conteggi delle richieste tra istanze o mediare l'uso della CPU su una flotta. Riduce il volume dei dati e rivela comportamenti a livello di sistema che i singoli data point nascondono. Serve attenzione perché alcune operazioni (come mediare i percentili) sono statisticamente non valide.
PromQL
PromQL è il linguaggio di query funzionale di Prometheus per selezionare e aggregare dati di serie temporali, con supporto per calcoli di rate, operatori di aggregazione e stima dei quantili. Opera su instant vector e range vector e alimenta sia le dashboard sia le regole di alerting. Le sue funzioni rate() e histogram_quantile() sono centrali nella maggior parte delle query di affidabilità.
Scrape
Uno scrape è la raccolta pull-based delle metriche di Prometheus, in cui il server invia periodicamente una richiesta HTTP all'endpoint /metrics di un target e ne analizza l'exposition. L'intervallo di scrape determina la risoluzione delle serie temporali e il costo di archiviazione. Lo scraping pull-based dà al sistema di monitoraggio il controllo sui tempi di raccolta e rende direttamente osservabile lo stato (up/down) del target.
Pull vs Push
La raccolta pull-based fa sì che il sistema di monitoraggio prelevi le metriche dai target (come Prometheus che fa scrape di /metrics), mentre quella push-based fa sì che le applicazioni inviino la telemetria a un collector o gateway (come fa il push OTLP). Il pull semplifica la discovery e il rilevamento di liveness; il push si adatta a job effimeri e funzioni serverless che potrebbero non essere raggiungibili durante lo scrape. Molti stack combinano entrambi, usando un push gateway o l'OTel Collector.
Alerting
L'alerting è il rilevamento automatico delle condizioni che richiedono attenzione umana, valutando regole sulla telemetria e notificando i responder quando si superano soglie o burn rate degli SLO. I buoni alert sono azionabili, urgenti e legati a sintomi rivolti all'utente piuttosto che a cause interne. L'alert fatigue da alert rumorosi e non azionabili è una causa primaria di incidenti reali mancati.
Dashboard
Una dashboard è una disposizione visiva curata di grafici e pannelli che presentano la telemetria per monitoraggio ed esplorazione. Le dashboard efficaci rispondono a una domanda specifica (come "questo servizio è sano?") e conducono dai segnali di alto livello al dettaglio. Le dashboard complementano, ma non sostituiscono, l'alerting e l'interrogazione ad-hoc.
Esplosione di cardinalità
Un'esplosione di cardinalità è una crescita incontrollata del numero di serie temporali uniche causata dall'allegare valori ad alta cardinalità (come ID utente, ID richiesta o URL completi) alle etichette delle metriche. Può esaurire la memoria e l'archiviazione di un backend delle metriche ed è una causa frequente di outage del sistema di monitoraggio stesso. La soluzione è spostare i dati ad alta cardinalità in log o tracce e mantenere le etichette delle metriche a bassa cardinalità.
MTTR (Mean Time To Recovery)
L'MTTR è il tempo medio impiegato a ripristinare il servizio dopo l'inizio di un incidente, una misura centrale della resilienza operativa. L'observability riduce l'MTTR accorciando le fasi di rilevamento e diagnosi, permettendo ai responder di trovare rapidamente il componente che sta fallendo. È spesso abbinato a MTTD (mean time to detect) e MTBF (mean time between failures).
Service Map
Una service map (o service graph) è una visualizzazione dei servizi in un sistema e delle relazioni di chiamata tra di essi, di solito derivata automaticamente dai dati di traccia. Mostra le dipendenze, i tassi di richiesta e i tassi di errore tra i servizi, rendendo visibili l'architettura e la propagazione dei guasti. È un punto di ingresso comune per navigare da un sintomo al servizio responsabile.
Baggage
Il baggage in OpenTelemetry è un insieme di coppie chiave-valore definite dall'utente propagate insieme al contesto di traccia attraverso i confini dei servizi, disponibili per tutti gli span a valle. Porta contesto di business trasversale - come un ID di tenant o di esperimento - così può essere aggiunto agli span o usato per decisioni di routing. Il baggage è propagato a tutti i servizi a valle, quindi deve evitare dati sensibili e dimensioni eccessive.
Profiling continuo
Il profiling continuo è la raccolta sempre attiva di profili di performance a basso overhead (come CPU e memoria) dalla produzione, sempre più trattato come un quarto segnale di observability. Individua quali funzioni o righe consumano risorse, complementando le tracce che mostrano dove va il tempo tra i servizi. OpenTelemetry ha standardizzato un segnale di profiling e un formato OTLP profiles.
Resource (OpenTelemetry)
In OpenTelemetry una Resource è un insieme immutabile di attributi che descrivono l'entità che produce telemetria, come service.name, service.version e deployment.environment. Gli attributi di resource sono allegati a tutti i segnali di quell'entità, abilitando la correlazione coerente di log, metriche e tracce verso un singolo servizio. Le semantic conventions definiscono i nomi standard degli attributi di resource.
Semantic Conventions
Le semantic conventions sono i nomi e i significati standardizzati di OpenTelemetry per gli attributi (come http.request.method o db.system) così la telemetria di sorgenti diverse è coerente e portabile. Seguirle permette a backend e dashboard di comprendere i dati senza configurazione per sorgente. Sono il vocabolario condiviso che rende pratica l'observability vendor-neutral.
Retention
La retention è per quanto tempo la telemetria viene conservata prima di essere eliminata o aggregata (downsampling), bilanciata con il costo di archiviazione e la necessità di indagare incidenti passati. I dati recenti ad alta risoluzione sono di solito conservati a breve termine, mentre le metriche aggregate possono essere downsamplate e conservate per la pianificazione di capacità. Segnali diversi meritano retention diverse perché i loro profili di costo e valore differiscono.
Correlazione
La correlazione è il collegamento di telemetria correlata tra segnali - per esempio saltare da un picco di una metrica alle tracce e ai log dello stesso momento e servizio. È abilitata da identificatori condivisi come trace_id, attributi di resource coerenti ed exemplar. Una forte correlazione è ciò che trasforma tre segnali separati in un unico flusso di indagine.