Qual è la differenza tra monitoring e observability?
Il monitoring è l'atto di raccogliere e fare alerting su un insieme predefinito di metriche e condizioni che già sai di dover sorvegliare - risponde a domande note come "la CPU è sopra il 90%?". L'observability è la proprietà più ampia di poter porre domande nuove e impreviste su un sistema a partire dalla sua telemetria senza rilasciare nuova instrumentation. Nella pratica il monitoring è una capacità che costruisci su un sistema osservabile: ti serve telemetria ricca e contestuale (log, metriche, tracce) prima di poter sia sorvegliare i guasti noti sia indagare quelli nuovi.
Quali sono i tre pilastri dell'observability?
I tre pilastri sono log, metriche e tracce, ognuno dei quali risponde a una domanda diversa. Le metriche ti dicono che qualcosa non va e quanto, con numeri economici e aggregabili ideali per dashboard e alert; i log ti dicono cosa è successo in un evento specifico con contesto di alto dettaglio; le tracce ti dicono dove nel percorso di chiamate distribuito si è verificato il problema e quanto è durato ogni passo. I pilastri sono più potenti quando correlati - per esempio saltando da un picco di una metrica di latenza a una traccia di esempio e poi ai log di quella richiesta.
Mi servono ancora i log se ho metriche e tracce?
Sì - i tre segnali sono complementari, non intercambiabili. Le metriche sono numeri pre-aggregati che mostrano trend e scatenano alert in modo economico, e le tracce mostrano la struttura e i tempi di una richiesta tra i servizi, ma nessuno dei due cattura il contesto arbitrario e di alto dettaglio di un evento discreto come fa un log. I log restano il posto migliore per informazioni verbose, ad alta cardinalità e ad-hoc come un messaggio di errore completo, uno snippet di payload o una decisione di business che non sta in un'etichetta di metrica o in un attributo di span.
Come scelgo tra metriche, log e tracce per un certo dato?
Usa le metriche per valori numerici a bassa cardinalità che aggreghi e su cui fai alert (tasso di richieste, rapporto di errore, profondità di coda), usa le tracce per comprendere latenza e causalità tra i servizi, e usa i log per dettaglio verboso o ad alta cardinalità legato a un evento specifico. Il fattore decisivo è di solito la cardinalità e l'aggregazione: tutto ciò che ha molti valori unici (ID utente, ID richiesta, URL completi) appartiene ai log o agli attributi di traccia, mai alle etichette delle metriche, dove farebbe esplodere il conteggio delle serie temporali.
Cos'è OpenTelemetry e perché dovrei usarlo?
OpenTelemetry è uno standard CNCF vendor-neutral che fornisce API, SDK e il Collector per generare ed esportare tracce, metriche e log in un formato comune (OTLP). Il suo beneficio principale è il disaccoppiamento: strumenti il codice una volta sola contro un'API aperta e stabile, e puoi cambiare backend di observability - o inviare a più contemporaneamente - senza re-strumentare. È il risultato della fusione di OpenTracing e OpenCensus ed è ormai lo standard di fatto, supportato da praticamente ogni backend moderno.
Cosa fa l'OpenTelemetry Collector e mi serve davvero?
Il Collector è un processo standalone che riceve telemetria, la elabora attraverso una pipeline configurabile di receiver, processor ed exporter, e la inoltra a uno o più backend. Ti permette di centralizzare le policy - batching, retry, redazione di campi sensibili, sampling, arricchimento di attributi e fan-out - senza modificare il codice applicativo o ridistribuire i servizi per cambiare backend. Non è strettamente necessario per un sistema piccolo, ma eseguire un Collector come agente (per nodo) o gateway (centralizzato) è il pattern di produzione raccomandato.
Come riduco il costo del mio stack di observability?
Il costo è guidato per lo più dal volume dei dati e dalla cardinalità, quindi le leve a maggior impatto sono il campionamento delle tracce, lo scarto o l'aggregazione di metriche e log a basso valore, e la rimozione delle etichette ad alta cardinalità. Usa il campionamento tail-based per mantenere errori e tracce lente scartando quelle di routine, fai downsampling delle metriche vecchie, imposta la retention per segnale in base al valore investigativo, e sposta i campi ad alta cardinalità dalle metriche ai log o agli attributi di traccia. Fare questo filtraggio centralmente nel Collector tiene la policy in un unico posto.
Qual è la differenza tra campionamento head-based e tail-based?
Il campionamento head-based decide se mantenere una traccia al suo inizio, prima che l'esito sia noto, poi propaga quella decisione a valle; è economico e produce tracce complete ma non può mantenere preferenzialmente errori o richieste lente. Il campionamento tail-based bufferizza tutti gli span di una traccia finché non finisce, poi applica regole come "mantieni tutti gli errori e qualsiasi cosa sopra 1 secondo", catturando le tracce interessanti al costo di memoria e di una distribuzione del Collector più complessa. Molti team combinano un basso tasso head con regole tail per errori e alta latenza.
Cosa sono SLI, SLO ed error budget?
Un SLI è un indicatore di qualità misurato, di solito un rapporto tra eventi buoni ed eventi validi, come richieste riuscite su totali. Un SLO è un target per quell'indicatore su una finestra, per esempio 99,9% su 30 giorni. L'error budget è la carenza ammessa - il restante 0,1% - che il team può spendere in rilasci e rischio; quando si esaurisce, la regola è rallentare e dare priorità all'affidabilità rispetto alle nuove funzionalità, dando a sviluppo e operations una decisione condivisa e basata sui dati.
Quanti "nove" mi servono davvero?
Dipende dal costo del downtime e dalle aspettative degli utenti, non dal puntare il più in alto possibile - ogni nove aggiuntivo è drasticamente più costoso. Come riferimento, il 99,9% consente circa 43 minuti di downtime al mese, il 99,99% circa 4,3 minuti e il 99,999% circa 26 secondi. Fissa lo SLO dall'impatto reale sull'utente e dal costo di business, perché sovradimensionare l'affidabilità spreca sforzo ingegneristico che potrebbe andare alle funzionalità, e uno SLO troppo stringente genera alert fatigue.
Perché l'alta cardinalità manda in crash il mio backend delle metriche?
Ogni combinazione unica di nome di metrica e valori di etichetta crea una serie temporale separata che il backend deve indicizzare e tenere in memoria, quindi allegare un valore ad alta cardinalità come un ID utente o un ID richiesta moltiplica senza limite il conteggio delle serie. Questa "esplosione di cardinalità" può esaurire memoria e archiviazione e mettere giù il sistema di monitoraggio stesso - ironicamente causando un outage nello strumento pensato per rilevare gli outage. Mantieni le etichette delle metriche a bassa cardinalità e spingi il dettaglio ad alta cardinalità nei log o negli attributi di traccia.
Quali metriche dovrei strumentare per prime su un nuovo servizio?
Inizia dai golden signals - latenza, traffico, errori e saturazione - o equivalentemente dal metodo RED (Rate, Errors, Duration) per i servizi guidati dalle richieste. Danno un'ampia copertura della salute rivolta all'utente con sforzo minimo: puoi capire se il servizio è su, quanto è occupato, quanto spesso fallisce e quanto è lento. Aggiungi il metodo USE (Utilization, Saturation, Errors) per risorsa quando devi diagnosticare i colli di bottiglia infrastrutturali sottostanti.
Come correlo log, metriche e tracce?
La correlazione si basa su identificatori condivisi e metadati coerenti: inietta il trace_id e lo span_id attivi in ogni riga di log, usa gli stessi attributi di resource OpenTelemetry (service.name, service.version, deployment.environment) su tutti i segnali, e allega exemplar agli histogram così un data point di metrica si collega a una traccia di esempio. Con questi in atto puoi passare da un picco di latenza su una dashboard a una traccia rappresentativa, e da quella traccia alle righe di log esatte della richiesta, in un unico flusso.
Cosa rende un buon alert?
Un buon alert è azionabile, urgente e legato a un sintomo rivolto all'utente piuttosto che a una causa interna, così che far scattare il pager a una persona sia giustificato e il responder sappia all'incirca cosa fare. Fare alerting sul burn rate dello SLO - con regole multi-finestra e multi-burn-rate che avvisano rapidamente per consumi severi e lentamente per quelli graduali - dà alta precisione e recall evitando il rumore. Gli alert non azionabili andrebbero declassati a dashboard o ticket, perché l'alert fatigue porta i responder a perdere gli incidenti reali.
Cos'è la propagazione del contesto e perché la mia traccia si rompe tra i servizi?
La propagazione del contesto è il passaggio del contesto di traccia - il trace ID e lo span ID corrente - da un servizio al successivo, tipicamente tramite l'header HTTP W3C traceparent, così gli span a valle si attaccano alla stessa traccia. Una traccia si spezza in pezzi scollegati quando un hop non propaga questo header: un client che non lo inietta, un proxy che lo rimuove, o un confine asincrono (una coda o un thread pool) che perde il contesto. La soluzione è assicurarsi che ogni framework, client e livello di messaging nel percorso legga e scriva gli header standard.
Dovrei usare un modello pull o push per raccogliere le metriche?
La raccolta pull-based (Prometheus che fa scrape di un endpoint /metrics) permette al sistema di monitoraggio di controllare i tempi e rilevare direttamente la liveness del target, e semplifica la service discovery per i servizi a lunga vita. La raccolta push-based (inviare OTLP a un Collector o push gateway) si adatta a job effimeri, funzioni serverless e client dietro NAT che non possono essere fatti scrape in modo affidabile. Molti stack di produzione usano entrambi - facendo scrape dei servizi a lunga vita e push della telemetria dai carichi effimeri - spesso unificandoli tramite l'OpenTelemetry Collector.
Il tracing di OpenTelemetry è stabile e pronto per la produzione?
La specifica di tracing di OpenTelemetry, l'API e gli SDK per i linguaggi principali hanno raggiunto uno stato stabile (1.0), rendendo il tracing pronto per la produzione e sicuro su cui basare instrumentation che non si romperà sotto le garanzie di stabilità. Anche le metriche hanno raggiunto la stabilità, mentre i log e il più recente segnale di profiling sono maturati più tardi e in alcuni linguaggi potrebbero ancora evolvere. Controlla le pagine di stato per componente e linguaggio prima di basarti su un segnale, ma tracing e metriche sono ampiamente usati in produzione oggi.