Osserva il servizio e i suoi utenti

Parti dalla domanda

Il monitoraggio verifica condizioni note. L’osservabilità aiuta a indagare sul comportamento del sistema, inclusi guasti non previsti. Più dashboard non forniscono automaticamente risposte migliori.

Per un servizio fittizio di esportazione, parti da una domanda dell’utente: un utente autorizzato può ricevere l’esportazione corretta entro il tempo concordato? Scegli poi segnali che rispondano alla domanda e aiutino a spiegare i guasti.

OpenTelemetry offre strumentazione e standard per la telemetria. Può inviare segnali a backend compatibili. Servono comunque archiviazione, query, controlli di accesso, conservazione e persone che agiscano sulle prove. Introduzione all’osservabilità.

Collega forme diverse di prova

Una metrica misura una quantità nel tempo. Un log registra un evento. Una trace collega operazioni correlate mentre una richiesta attraversa il sistema. Uno span rappresenta un’operazione all’interno di una trace.

Per il lavoro asincrono, mantieni una correlazione sicura tra il job inviato e l’esecuzione del worker. Una risposta HTTP 202 può significare che il lavoro è stato accettato. Non dimostra che l’esportazione sia terminata.

Invia avvisi quando serve agire

Definisci lo SLI e il suo denominatore prima di fissare lo SLO. Nell’esempio, conta le esportazioni ammesse completate correttamente entro la durata concordata. Definisci come includere nella misura i job di lunga durata e quelli abbandonati.

Un error budget descrive i guasti consentiti nella finestra dello SLO. Un burn rate descrive quanto rapidamente i guasti consumino quel budget. Le indicazioni di Google usano più finestre per bilanciare rilevamento tempestivo e rumore degli avvisi. Avvisi basati sugli SLO.

Allerta una persona quando la condizione richiede un intervento tempestivo. Invia il lavoro meno urgente a una coda. Ogni avviso richiede responsabile, descrizione dell’impatto, collegamento all’indagine e istruzioni di risposta. Riesamina gli avvisi che ripetutamente non portano ad azioni.

Non usare una soglia generica per ogni servizio. Impatto sugli utenti, traffico, orari aziendali e capacità di risposta influiscono sulla decisione.

Proteggi la pipeline di telemetria

La telemetria può contenere dati personali, token, parametri delle richieste e documenti riservati. Definisci i campi ammessi prima della raccolta. Limita accesso e conservazione. Rimuovi i segreti prima dell’esportazione a un backend esterno. Telemetria sensibile.

Non usare l’email di un cliente o un ID univoco di job come etichetta di una metrica. Etichette senza limiti aumentano il numero di serie temporali e possono esporre identificatori. Usa dimensioni controllate per le metriche. Inserisci gli identificatori di correlazione approvati in log o trace con accesso controllato.

Misura la pipeline stessa. Verifica errori di acquisizione, dati scartati e tempo trascorso dall’ultima osservazione. Un grafico degli errori piatto può significare assenza di errori oppure di telemetria in arrivo. Mostra la distinzione.

Indaga su un guasto concreto

Il servizio fittizio restituisce HTTP 202 per ogni richiesta. Il tempo di permanenza dei job in coda sale da secondi a 15 minuti. I log dei worker mostrano timeout ripetuti del database. Le trace campionate collocano la maggior parte del tempo dei worker nelle chiamate al database.

Queste prove sostengono un’indagine mirata. Non stabiliscono se la causa sia una modifica alle query, connessioni esaurite o capacità del database. Confronta le ipotesi con il metodo di debug.

Taiga Monitoring offre una vista dello stato del prodotto con segnali di disponibilità ed esperienza nel browser. Completa l’osservabilità infrastrutturale e applicativa; non sostituisce questi sistemi. Monitoring.