Strumenta con OpenTelemetry, non con SDK di vendor
Strumenta il codice contro l'API vendor-neutral di OpenTelemetry così la telemetria che emetti è disaccoppiata da qualsiasi singolo backend. Questo significa poter cambiare o aggiungere backend - o inviare a più contemporaneamente - modificando la configurazione degli exporter anziché re-strumentare il codice applicativo. Esporta via OTLP attraverso il Collector; non sparpagliare le chiamate API di un agente proprietario nella tua logica di business, perché ti vincola al vendor e rende la migrazione una riscrittura.
Mantieni le etichette delle metriche a bassa cardinalità
Tratta ogni etichetta di metrica come un moltiplicatore del conteggio delle serie temporali e usa solo dimensioni con un piccolo insieme limitato di valori, come il metodo HTTP, la classe di status o il template di route. Etichetta le richieste con route="/users/{id}"; non etichettare con l'URL concreto /users/12345, con l'ID utente grezzo o con l'ID richiesta, perché ogni valore unico crea una nuova serie e un'etichetta illimitata può mandare in crash il backend delle metriche. Spingi il dettaglio ad alta cardinalità nei log o negli attributi di traccia.
Definisci gli SLO dai sintomi rivolti all'utente
Basa i tuoi target di affidabilità su indicatori che l'utente sperimenta davvero - rapporto di richieste riuscite, latenza end-to-end - piuttosto che su cause interne come CPU o restart dei pod. Esprimi un SLI come eventi buoni su eventi validi e imposta uno SLO con una finestra esplicita (per esempio 99,9% su 30 giorni); non fissare un target arbitrario "a cinque nove" ovunque, perché ogni nove in più è molto più costoso e uno SLO irrealisticamente stringente genera alert costanti e ignorabili.
Fai alerting sui sintomi e sul burn rate dello SLO, non sulle cause
Fai scattare il pager per cose che sono sia urgenti sia che colpiscono l'utente, idealmente guidate da quanto velocemente stai consumando l'error budget. Usa alert multi-finestra e multi-burn-rate così un consumo severo avvisa subito e uno graduale avvisa con calma; non fare alerting su ogni metrica interna che supera una soglia statica (CPU alta, una singola richiesta fallita), perché gli alert basati sulle cause sono rumorosi, spesso non azionabili e addestrano i responder a ignorare il pager.
Usa il logging strutturato con ID di correlazione
Emetti i log come record chiave-valore strutturati (di solito JSON) e includi il trace_id e lo span_id attivi in ogni riga. Logga {"level":"error","trace_id":"...","order_id":"...","msg":"pagamento rifiutato"} così puoi filtrare e saltare alla traccia; non scrivere stringhe libere come Errore nell'elaborazione dell'ordine 42 che richiedono regex fragili per essere analizzate e non possono essere correlate a una traccia. La struttura è ciò che trasforma i log da muro di testo a dati interrogabili.
Campiona le tracce deliberatamente, mantenendo quelle interessanti
Decidi una strategia di campionamento apposta anziché registrare tutto o niente. Usa il campionamento tail-based per mantenere tutte le tracce di errore e le richieste lente scartando una grande frazione dei successi di routine, così il costo resta limitato ma le tracce diagnosticamente preziose sopravvivono; non affidarti solo a un basso tasso head fisso, perché scarta gli errori allo stesso tasso dei successi e perdi proprio le tracce che ti servono durante un incidente.
Standardizza su semantic conventions e attributi di resource
Usa le semantic conventions di OpenTelemetry per i nomi degli attributi (http.request.method, db.system) e imposta attributi di resource coerenti (service.name, service.version, deployment.environment) su ogni segnale. Adotta i nomi standard così i backend e le dashboard condivise funzionano senza configurazione per servizio; non inventare chiavi di attributo per ogni team, perché una nomenclatura incoerente rompe la correlazione tra servizi e costringe a parsing su misura per ogni sorgente.
Centralizza la policy di telemetria nel Collector
Esegui un OpenTelemetry Collector (come agente per nodo e/o gateway) e mettici batching, retry, redazione, sampling e routing. Applica la pulizia della PII e il sampling una volta sola nella pipeline del Collector così ogni servizio eredita la policy; non integrare endpoint dei backend, rapporti di sampling e regole di redazione in ogni applicazione, perché cambiare policy richiederebbe poi di ridistribuire ogni servizio.
Ripulisci i dati sensibili prima che lascino il processo
Tratta la telemetria come un rischio di esfiltrazione dati e rimuovi segreti e PII presto. Reda token, password, dettagli di pagamento completi e dati personali nell'SDK o nel Collector prima dell'export, ed evita di metterli negli attributi di span, nei campi di log o nelle etichette delle metriche; non loggare corpi di richiesta grezzi o header di autorizzazione "per debugging", perché la telemetria è ampiamente accessibile e spesso conservata, trasformando una comodità in una violazione di conformità.
Imposta retention e downsampling per segnale
Adatta per quanto tempo conservi ciascun segnale al suo costo e valore investigativo anziché applicare un'unica retention uniforme. Conserva le metriche ad alta risoluzione per una finestra breve e fai downsampling ad aggregati più grossolani per i trend di lungo termine, conserva le tracce di errore più a lungo di quelle di routine, e stratifica la retention dei log per importanza; non conservare ogni segnale grezzo a piena fedeltà per sempre, perché il costo di archiviazione cresce senza limite e la maggior parte dei dati vecchi ad alta risoluzione non viene mai interrogata.
Propaga il contesto attraverso ogni confine, incluso l'asincrono
Assicurati che il contesto di traccia fluisca sia attraverso le chiamate sincrone sia attraverso gli hop asincroni così le tracce restano connesse end-to-end. Propaga l'header W3C traceparent sull'HTTP in uscita e porta il contesto attraverso code di messaggi e thread pool usando il meccanismo di contesto dell'SDK; non dare per scontato che l'auto-instrumentation copra ogni percorso - thread pool custom, batch job e alcuni client di messaging perdono silenziosamente il contesto e spezzano una richiesta in più tracce scollegate.
Rendi la telemetria azionabile con runbook e ownership
Abbina a ogni alert un owner chiaro e un runbook che descriva le cause probabili e i primi passi. Collega l'alert a una dashboard mirata al servizio impattato e a una procedura di risposta documentata; non far scattare un alert in un canale condiviso senza owner e senza guida, perché un alert che nessuno possiede e nessuno sa come gestire non riduce il tempo di recovery ed erode la fiducia nel sistema.
Testa la tua observability come testi il tuo codice
Verifica che l'instrumentation funzioni davvero prima di farci affidamento durante un incidente. Asserisci nei test che gli span e le metriche chiave siano emessi con gli attributi attesi, esegui game-day che esercitano alert e dashboard, e aggiungi un heartbeat dead-man's-switch per rilevare i guasti silenziosi della telemetria; non scoprire durante un outage che una metrica non era mai stata collegata, che un'etichetta era scritta male o che un alert non è mai scattato - un'observability rotta è peggio di nessuna observability perché dà falsa fiducia.