Il dashboard è verde, eppure i clienti si lamentano che il checkout non funziona. Se ti sei trovato in questa posizione, capisci già la differenza tra monitoraggio e osservabilità. Il tuo monitoraggio ha controllato solo ciò che pensavi di controllare e questo fallimento è qualcosa di nuovo.

Questa guida spiega entrambe le idee senza usare il linguaggio del marketing e segue un incidente immaginario dall’allarme alla causa principale. I registri, la traccia e i numeri sono inventati per illustrare il processo. Dovresti anche sapere che venditori e professionisti tracciano questa linea in modo diverso e alcuni la considerano in parte una distinzione di marketing. Ci concentriamo sulla parte pratica.

La risposta breve

Il Monitoraggio è un’attività. Decidi in anticipo cosa guardare, come CPU, tasso di errore o spazio su disco, e imposti le soglie che attivano gli avvisi. Risponde: “È accaduto ciò che temevo?”

Osservabilità è una proprietà del tuo sistema. Il termine deriva dalla teoria del controllo, dove descrive quanto bene si possa dedurre lo stato interno di un sistema dai suoi output esterni. In pratica risponde: “Cosa sta succedendo e perché, anche per problemi che non avevo mai previsto?”

Pensa a un’auto. Le spie sul cruscotto stanno monitorando. Coprono una serie di problemi noti. La porta diagnostica completa di un meccanico, che consente a qualcuno di porre nuove domande su qualsiasi parte del motore, è più vicina all’osservabilità.

Monitoraggio e osservabilità fianco a fianco

Questa non è una scelta tra i due. Hai ancora bisogno di avvisi che ti dicano quando guardare.

Perché il solo monitoraggio non basta

Con un’applicazione su un server, l’elenco delle cose che possono andare storte è piuttosto breve, quindi puoi controllarle tutte. Un sistema moderno può avere dozzine di servizi, code e API di terze parti, oltre a container che vanno e vengono. I guasti diventano combinazioni che nessuno aveva previsto: una regione, un tipo di cliente, una versione specifica dell’app e un’unica dipendenza lenta.

Non puoi scrivere in anticipo una dashboard per una domanda a cui non hai pensato. Hai bisogno di dati che ti permettano di chiederli in seguito.

Log, metriche e tracce

Questi tre tipi di telemetria sono spesso chiamati i pilastri dell’osservabilità. Ognuno risponde a una domanda diversa:

Metriche

http_requests_total{service="checkout", status="500"} 1832
http_request_duration_seconds{service="checkout", quantile="0.95"} 2.4

Le metriche sono economiche da archiviare e veloci da interrogare, il che le rende ideali per dashboard e avvisi. Diffidare delle etichette ad alta cardinalità, come l’ID utente, in molti sistemi metrici, perché possono aumentare notevolmente i costi.

Tracce

Una traccia segue una richiesta tra i servizi. Ogni passaggio è un intervallo con un’ora di inizio e una durata:

POST /checkout                      2410 ms
├─ auth-service: verify token         18 ms
├─ cart-service: load cart            42 ms
├─ pricing-service: calculate       2290 ms   <-- slow
│  └─ SELECT coupons ...            2265 ms
└─ payment-service: not reached

Una traccia rende evidente un passaggio lento, che è molto difficile da vedere in log separati da servizi separati.

Registri

I registri forniscono i dettagli di ciò che è accaduto in un dato momento. Vediamo come renderli utili in un momento.

Una procedura dettagliata sull’incidente

Ecco come i pezzi si incastrano, in un esempio immaginario.

Il monitoraggio ha gestito il passaggio 1. Tutto ciò che è seguito era osservabilità. Nota come ogni domanda deriva dalla risposta precedente. Nessuno avrebbe potuto creare in anticipo una dashboard per la “query sui coupon dell’app mobile dalla campagna di oggi”. Per quanto riguarda la correzione stessa, la nostra guida all’ottimizzazione delle query SQL mostra come leggere questo tipo di piano.

Registri migliori

I registri di testo semplice sono fatti per gli occhi umani e difficili da interrogare. I log strutturati utilizzano campi su cui una macchina può filtrare:

# Hard to search
ERROR Payment failed for user 42 after 3 tries

# Easy to search
{"level":"error","event":"payment_failed","user_id":"42",
 "attempts":3,"provider":"acme","trace_id":"a1b2c3","duration_ms":2410}

Con il secondo modulo puoi subito chiedere “quanti guasti per fornitore nell’ultima ora?” Il campo trace_id è particolarmente prezioso, poiché collega una riga di registro all’intera richiesta, attraverso ogni servizio toccato.

Non registrare mai password, token o numeri di carte e fai attenzione ai dati personali. Come spiega la nostra guida, i JWT possono essere riutilizzati da chiunque li legga da un registro.

I segnali d’oro

Non sai cosa monitorare? Il libro Site Reliability Engineering di Google suggerisce quattro segnali per i sistemi rivolti all’utente:

Utilizza i percentili per la latenza, poiché le medie nascondono richieste lente, come abbiamo mostrato in test di carico e test di stress.

Avvisi di cui le persone si fidano

Se gli avvisi vengono attivati continuamente, le persone smettono di leggerli. Quelli bravi seguono alcune regole:

• Avviso sui sintomi avvertiti dagli utenti. “Errori di pagamento superiori al 2%” batte “CPU all’85%”. Una CPU elevata che non danneggia nessuno non dovrebbe svegliare nessuno.
• Rendi ogni avviso utilizzabile. Se nessuno ha bisogno di fare nulla, rendilo un elemento della dashboard o rimuovilo.
• Collegamento a un runbook. Indica al risponditore dove cercare e cosa provare.
• Rivedili regolarmente. Elimina o correggi eventuali avvisi ignorati il ​​mese scorso.

Obiettivi del livello di servizio

Uno SLO trasforma “il sito deve essere veloce e affidabile” in un obiettivo misurabile, ad esempio “il 99,9% delle richieste di pagamento ha esito positivo nell’arco di 30 giorni”. Ciò consente circa lo 0,1% di errori, noto come budget di errore. Se ne hai abbastanza, puoi spedire più velocemente e, se è quasi esaurito, puoi dare priorità all’affidabilità. È un modo utile per risolvere le controversie tra velocità di consegna e stabilità.

OpenTelemetry e strumenti

OpenTelemetry è uno standard open source e indipendente dal fornitore per la generazione e l’esportazione di dati di telemetria. È un progetto della Cloud Native Computing Foundation. Strumentarlo significa che puoi modificare il tuo backend in un secondo momento senza riscrivere il codice. Non è un prodotto di archiviazione o dashboard in sé, quindi abbinalo a uno:

Controlla tu stesso le caratteristiche attuali e i prezzi, poiché questi prodotti cambiano spesso. I costi possono aumentare rapidamente con il volume dei dati, quindi utilizza il campionamento e imposta limiti di conservazione.

Come iniziare

1. Inizia con i segnali d’oro per il tuo servizio più importante.
2. Aggiungi uno o due avvisi sui sintomi notati dagli utenti.
3. Passa ai log strutturati, con un ID richiesta in ogni riga.
4. Aggiungi il tracciamento al percorso principale dell’utente con OpenTelemetry, poiché la strumentazione automatica può coprire molti framework comuni.
5. Collega le distribuzioni ai tuoi grafici, in modo da poter vedere se un rilascio dalla tua pipeline CI/CD ha causato una modifica.
6. Impara da ogni incidente. Dopo ciascuno, chiedi quali dati avrebbero reso più rapida la risoluzione e aggiungili.

Un piccolo team con un servizio non ha bisogno di una piattaforma enorme. Metriche di base, registri validi e alcuni avvisi potrebbero essere sufficienti. Il tracciamento guadagna terreno man mano che il numero di servizi cresce.

Errori comuni

• Acquistare uno strumento e chiamarlo osservabilità. Il valore deriva da una buona strumentazione e dal modo in cui si utilizzano i dati.
• Trattare i tre pilastri come una lista di controllo. Separare i dati senza alcun modo per collegarli ti costringe a cercare tra le schede. Gli ID condivisi contano.
• Raccogliere tutto. La telemetria non filtrata diventa costosa e aggiunge rumore.
• Troppe dashboard. Alcune visualizzazioni attendibili superano cento che nessuno apre.
• Pensare che sostituisca i test. Hai ancora bisogno di test prima del rilascio. Tuttavia, i rilasci Canary si abbinano bene a questi segnali.

Considerazioni finali

Il monitoraggio ti dice che qualcosa è andato storto e l’osservabilità ti dà i mezzi per scoprirne il motivo. Il test pratico è semplice: quando si presenta un problema sconosciuto, riesci a trovarne la causa senza inviare nuovo codice? La prossima volta che ti trovi coinvolto in un incidente, scrivi tutte le domande a cui non puoi rispondere. Quella lista è la tua tabella di marcia.

Domande frequenti

Continua a imparare