Osservabilità delle applicazioni: guida pratica per i responsabili tecnici

L’osservabilità delle applicazioni è la capacità di capire perché il software si comporta in un certo modo esaminando i segnali che produce: log, metriche, tracce e, quando utile, dati sull’esperienza reale degli utenti. Fornisce agli ingegneri il contesto necessario per analizzare un errore sconosciuto senza dover prima aggiungere log temporanei, ricostruire una richiesta da diversi strumenti scollegati o affidarsi alla persona che ricorda per caso come funziona il sistema.

Per i responsabili tecnici, l’osservabilità non è principalmente un acquisto di strumenti. È una capacità operativa. Collega il comportamento in produzione ai flussi di lavoro dei clienti e dell’azienda che dipendono da esso, offre ai team un metodo condiviso per diagnosticare i problemi e rende i rilasci e gli incidenti meno dipendenti da supposizioni.

Il punto di partenza sensato raramente è “strumentare tutto”. Inizia con due o tre flussi critici: i percorsi in cui un errore, una latenza o dati inesatti hanno un effetto significativo sui clienti, sui ricavi, sulle operazioni o sull’erogazione del servizio. Crea una visibilità utile in queste aree, stabilisci responsabilità e pratiche di risposta, quindi amplia l’ambito in modo deliberato.

 

L’osservabilità delle applicazioni in breve

Domanda	Risposta pratica
Che cos’è l’osservabilità delle applicazioni?	La capacità di analizzare il comportamento delle applicazioni usando dati telemetrici correlati, inclusi log, metriche, tracce e segnali pertinenti sull’esperienza degli utenti.
Da dove dovrebbe iniziare un team?	Inizia con due o tre flussi utente o operativi fondamentali per l’azienda, invece di tentare subito di strumentare l’intero sistema.
Quali dati telemetrici sono essenziali?	I log forniscono i dettagli degli eventi, le metriche mostrano le tendenze e lo stato del servizio, mentre le tracce mostrano come le singole richieste attraversano servizi e dipendenze.
Perché usare OpenTelemetry?	Fornisce un framework ampiamente adottato e indipendente dai fornitori per generare ed esportare dati telemetrici, contribuendo a separare la strumentazione dalla piattaforma backend utilizzata per analizzarli.
Che cosa dovrebbero rappresentare gli avvisi?	Condizioni che hanno un impatto sugli utenti o sono importanti dal punto di vista operativo, collegate agli obiettivi dei livelli di servizio, non ogni variazione di una metrica o ogni errore isolato.
Chi è responsabile dell’osservabilità?	I team applicativi sono responsabili del comportamento dei propri servizi; i team platform, DevOps o SRE rendono più semplici da adottare gli standard, gli strumenti e le pratiche operative affidabili.

Che cos’è l’osservabilità delle applicazioni?

Spesso l’osservabilità viene confusa con il monitoraggio. Il monitoraggio è importante, ma di solito risponde a una domanda più circoscritta: qualcosa è al di fuori di un limite previsto? Un monitor può dirti che il tasso di errore è aumentato, che la profondità della coda sta crescendo o che la latenza ha superato una soglia.

L’osservabilità aiuta un team ad analizzare perché è successo. Permette di collegare un sintomo visibile all’utente a una richiesta, a un servizio, a una dipendenza, a una query del database, alla versione di un rilascio o a una modifica della configurazione che ha contribuito al problema.

Questa distinzione diventa più importante man mano che i sistemi diventano distribuiti. In un’applicazione semplice, un ingegnere può riuscire a esaminare il log di un solo servizio e identificare il problema. In un sistema con API, code, servizi cloud, dipendenze di terze parti, elaborazione di eventi e diversi componenti applicativi, le informazioni sono solitamente distribuite in più punti. L’osservabilità fornisce il contesto necessario per collegarle.

Una pratica efficace di osservabilità combina:

• Strumentazione: generazione di dati telemetrici che rappresentano importanti comportamenti del sistema e dell’azienda.
• Correlazione: trasmissione del contesto della traccia e della richiesta attraverso i confini tra i servizi, così da poter esaminare insieme gli eventi correlati.
• Analisi: strumenti utili per consentire agli ingegneri di esplorare il comportamento durante incidenti, rilasci e attività sulle prestazioni.
• Risposta operativa: definizione di chi riceve i segnali, di come ne valuta l’impatto e di quale azione può intraprendere.
• Miglioramento continuo: utilizzando gli incidenti, i problemi di supporto e l’esperienza di consegna per migliorare nel tempo la strumentazione e i runbook.

Perché l’osservabilità delle applicazioni è importante per l’azienda

I responsabili non hanno bisogno dell’osservabilità semplicemente perché un sistema dispone di microservizi o perché il pannello di un fornitore appare impressionante. Ne hanno bisogno quando i flussi di lavoro importanti sono difficili da diagnosticare, gli incidenti che impattano i clienti richiedono troppo tempo per essere compresi, i rilasci generano incertezza o i team di supporto non dispongono delle prove necessarie per distinguere un problema dell’utente da un problema del sistema.

Quando è progettata attorno a flussi di lavoro significativi, l’osservabilità può aiutare i team a:

• Ridurre il tempo dedicato a trovare le prove pertinenti durante gli incidenti
• Identificare se un rilascio, una dipendenza, una modifica alla configurazione o un andamento del traffico è associato a un peggioramento
• Dare priorità agli interventi sull’affidabilità in base all’impatto sui clienti e sulle operazioni
• Rendere la risposta durante i turni di reperibilità meno dipendente dalla conoscenza individuale dei sistemi
• Migliorare il dialogo tra i responsabili di ingegneria, prodotto, supporto e azienda
• Riconoscere i modelli ricorrenti di errore prima che diventino problemi operativi normalizzati

Il valore per l’azienda deriva da decisioni più rapide e affidabili, non dalla raccolta del maggior volume possibile di telemetria. Un’organizzazione può generare enormi quantità di log e metriche restando comunque incapace di rispondere a una domanda fondamentale come: “Perché oggi i clienti non riescono a completare questo flusso di lavoro?”

L’osservabilità dovrebbe quindi iniziare dai flussi di lavoro che contano. Gli esempi possono includere la creazione di un account, il checkout, l’elaborazione dei pagamenti, la programmazione di appuntamenti, l’importazione di dati, un processo di instradamento degli ordini o un report rivolto ai clienti. I flussi esatti dipendono dal prodotto e dal modello operativo dell’organizzazione.

Log, metriche, tracce e segnali dell’esperienza utente

I diversi tipi di telemetria rispondono a domande diverse. Il valore deriva dal loro utilizzo congiunto e con un contesto coerente, non dal trattarne uno come sostituto degli altri.

Log: che cosa è successo?

I log registrano eventi discreti. Sono utili quando un’indagine richiede un contesto dettagliato: un messaggio di errore, un errore di convalida, una risposta di una dipendenza, una decisione di autorizzazione o un evento specifico dell’applicazione.

I buoni log di produzione sono strutturati, ricercabili e intenzionali. Dovrebbero includere un contesto sufficiente per indagare un problema, evitando al contempo informazioni sensibili non necessarie. Registrare dati personali, finanziari, di autenticazione o di pagamento grezzi in sistemi ad ampio accesso crea una categoria di rischio diversa.

Metriche: il sistema sta andando verso i problemi?

Le metriche misurano valori nel tempo: frequenza delle richieste, tasso di errore, profondità della coda, utilizzo della CPU, connessioni al database, transazioni riuscite o completamento dei flussi di lavoro. Sono utili per identificare modelli, stabilire baseline, definire obiettivi del servizio e rilevare un problema in sviluppo.

Per i flussi di lavoro rivolti ai clienti, percentili come la latenza p50, p95 e p99 sono generalmente più utili delle sole medie. Una media può sembrare accettabile mentre una parte significativa dei clienti sperimenta interazioni lente o non riuscite.

Tracce: dove è andata la richiesta?

Le tracce seguono una singola richiesta o un evento attraverso servizi e dipendenze. In un sistema distribuito, una traccia può rivelare come il tempo e gli errori sono distribuiti tra chiamate API, code, database, processi in background e servizi di terze parti.

Il contesto della traccia deve attraversare i confini in modo coerente. Se la traccia termina quando una richiesta entra in una coda di messaggi o chiama un servizio esterno critico, il team perde visibilità proprio nel punto in cui spesso iniziano le indagini più difficili.

Monitoraggio degli utenti reali: quale esperienza ha avuto l’utente?

Il monitoraggio degli utenti reali, la telemetria del browser e il contesto della sessione possono aggiungere una preziosa prospettiva dal lato del cliente. I servizi backend possono apparire in buone condizioni mentre gli utenti riscontrano errori del browser, rendering lento, interazioni non riuscite, problemi geografici, barriere di accessibilità o problemi specifici del dispositivo.

Questi segnali dovrebbero essere raccolti con adeguati controlli di privacy, conservazione e accesso. L’obiettivo è comprendere l’esperienza di un flusso di lavoro, non acquisire più dati dei clienti di quanti l’organizzazione ne abbia bisogno.

Regola pratica: Includi fin dall’inizio nella telemetria la versione del deployment, l’ambiente, il nome del servizio e l’identificativo del flusso di lavoro pertinente. Senza questo contesto, correlare una regressione a uno specifico rilascio o cambiamento del sistema diventa inutilmente difficile.

Inizia dai flussi critici, non dalla copertura universale

Spesso i team cercano di introdurre l’osservabilità strumentando ogni servizio, creando dashboard per ogni metrica e generando avvisi per ogni condizione insolita. Questo approccio può creare costi elevati per la telemetria, avvisi rumorosi, etichette incoerenti e una raccolta di dashboard su cui nessuno fa affidamento durante un incidente.

Un approccio più pratico inizia da due o tre flussi importanti per gli utenti o per le operazioni. Per ciascuno, definisci:

• Il risultato per l’utente o per l’azienda che il flusso dovrebbe produrre
• I componenti applicativi, gli archivi dati, le code e le dipendenze esterne coinvolti
• I segnali che indicano il completamento riuscito, il degrado o il fallimento
• I limiti accettabili di prestazioni e affidabilità
• Il team o il ruolo responsabile di intervenire quando tali limiti vengono superati
• Le informazioni necessarie per indagare e ripristinare un errore

Ad esempio, un flusso di invio degli ordini potrebbe richiedere visibilità sulle richieste degli utenti, sulla latenza dell’API, sulla convalida dell’inventario, sulle risposte del fornitore di pagamenti, sugli eventi di creazione dell’ordine, sui messaggi asincroni di evasione e sulla conferma finale mostrata al cliente. L’obiettivo non è acquisire ogni dettaglio possibile. È fornire prove sufficienti per determinare dove il flusso ha avuto esito negativo e che cosa dovrebbe accadere dopo.

Questo approccio è strettamente correlato a una buona architettura di streaming degli eventiSe il lavoro importante fluisce in modo asincrono attraverso code o eventi, i team hanno bisogno di un modo per seguire un evento dalla sua origine, passando per elaborazione, nuovi tentativi, errori e completamento.

Strumentazione con OpenTelemetry

OpenTelemetry è un framework open source per l'osservabilità e un insieme di specifiche per generare, raccogliere ed esportare dati di telemetria. Aiuta i team a standardizzare la strumentazione tra i servizi, mantenendo al contempo flessibilità nelle piattaforme utilizzate per archiviare, interrogare e visualizzare i dati risultanti.

La strumentazione indipendente dal fornitore non significa che tutte le piattaforme siano intercambiabili. I backend di osservabilità differiscono per costi, usabilità, conservazione, capacità di interrogazione, integrazione con l'ecosistema, controlli di sicurezza e oneri operativi. Significa invece che cambiare o combinare piattaforme backend non richiede necessariamente di riscrivere da zero la strumentazione dell'applicazione.

Diverse scelte di implementazione determinano se OpenTelemetry rimarrà utile con la crescita dell'adozione:

• Strumentazione automatica rispetto a manuale: la strumentazione automatica può fornire rapidamente una copertura di base; la strumentazione manuale aggiunge il contesto aziendale necessario per comprendere i flussi di lavoro di dominio importanti.
• Propagazione del contesto delle tracce: assicurarsi che gli identificatori delle tracce attraversino le chiamate HTTP, i messaggi asincroni, i processori di job e i confini esterni supportati.
• Convenzioni semantiche: stabilire una denominazione coerente per servizi, ambienti, distribuzioni, operazioni e attributi prima che ogni team inventi un formato diverso.
• Correlazione delle distribuzioni: associare rilasci, versioni, flag delle funzionalità e modifiche dell'ambiente ai dati di telemetria, così che i team possano analizzare efficacemente le regressioni.
• Gestione dei dati: definire ciò che non deve mai essere incluso in span, log o etichette delle metriche, in particolare dati personali, credenziali, token e informazioni di pagamento.
• Campionamento: acquisire dati sufficienti e rappresentativi, inclusi quelli relativi agli errori, per analizzare i comportamenti importanti senza raccogliere indefinitamente ogni evento.

Per un monolite legacy, modifiche estese al codice non sono sempre la scelta migliore da cui iniziare. Strumentate un percorso di richiesta critico, i principali confini di integrazione e le code di lavoro o i job che supportano il flusso di lavoro. Questo produce evidenze utili riducendo al contempo il rischio che un'iniziativa di strumentazione su larga scala si trasformi in un progetto di riscrittura.

La documentazione di OpenTelemetry è il riferimento tecnico principale per le relative specifiche, gli SDK, i collector, le opzioni di strumentazione e le convenzioni semantiche.

SLO, alert e costo della telemetria

Gli obiettivi di livello del servizio, o SLO, forniscono a un team una definizione condivisa dell'affidabilità accettabile per un servizio o un flusso di lavoro. Uno SLO utile riflette ciò che sperimentano gli utenti o i team dipendenti, come il completamento corretto del checkout, la disponibilità dell'API, il completamento dei job in background o una latenza di risposta entro una soglia concordata.

È utile distinguere tre concetti:

• SLI: l'indicatore del livello di servizio misurato, come richieste riuscite, completamento del flusso di lavoro o latenza p95.
• SLO: l'obiettivo di affidabilità per quell'indicatore in un periodo definito.
• Budget degli errori: la quantità di inaffidabilità che il servizio può assorbire rimanendo entro il proprio obiettivo.

Non tutte le metriche richiedono uno SLO e non tutti gli SLO richiedono un pager. Iniziate dai servizi e dai percorsi in cui un guasto prolungato ha una conseguenza chiara per il cliente, per le operazioni o per l'aspetto finanziario.

Anche gli alert dovrebbero essere proporzionati. Un alert utile fornisce al destinatario un motivo per agire. Se un alert non indica impatto, urgenza, responsabilità o un passo successivo pratico, probabilmente diventerà rumore.

Errori comuni nella gestione degli alert:

• Inviare pagine alle persone per ogni errore isolato anziché per un degrado prolungato che abbia un impatto sugli utenti
• Configurare alert sui sintomi dell'infrastruttura senza collegarli allo stato di salute del servizio o del flusso di lavoro
• Inviare alert a team che non possono intraprendere azioni significative
• Creare dashboard e alert senza una risposta o un runbook documentati
• Lasciare attivi alert obsoleti dopo la modifica di servizi, soglie o condizioni operative

Il costo della telemetria richiede la stessa disciplina. Le dimensioni ad alta cardinalità, come ID utente o ID richiesta univoci associati a ogni etichetta delle metriche, possono generare costi considerevoli di archiviazione e interrogazione. Gli identificatori dettagliati possono essere comunque utili nelle tracce e nei log strutturati per flussi critici selezionati. La decisione dovrebbe essere ponderata: utilizzare dimensioni che supportino l'analisi, applicare il campionamento dove appropriato, impostare politiche di conservazione e valutare i costi insieme al valore operativo.

L'osservabilità richiede responsabilità e pratica nella gestione degli incidenti

La telemetria diventa utile solo quando le persone possono agire sulla base delle informazioni che fornisce. Una dashboard senza un responsabile, un avviso senza un percorso di escalation o una traccia che richiede l'accesso di uno specialista durante ogni incidente non creano una capacità operativa efficace.

Le responsabilità devono essere esplicite senza trasformare un unico team della piattaforma nel collo di bottiglia permanente per ogni indagine. In molte organizzazioni:

• I team applicativi sono responsabili dello stato di salute, della strumentazione, dei runbook e degli obiettivi di servizio delle applicazioni che sviluppano e supportano.
• I team Platform, DevOps o SRE forniscono strumenti condivisi, standard, modelli di onboarding, controlli degli accessi e indicazioni operative.
• I responsabili di prodotto e delle operations aiutano a identificare quali percorsi sono importanti, cosa significhi una prestazione accettabile e come valutare l'impatto sui clienti o sulle attività operative.
• Gli stakeholder di sicurezza e conformità guidano i requisiti relativi alla gestione dei dati, alla conservazione, agli accessi e agli audit, quando pertinenti.

I team hanno inoltre bisogno di tempo per fare pratica. Una revisione dell'incidente non dovrebbe essere una ricerca di colpe. Dovrebbe esaminare ciò che il sistema ha rivelato, ciò che è stato difficile determinare, quali decisioni sono state ritardate e quale modifica alla strumentazione, al runbook, all'architettura o al processo renderebbe più semplice gestire il prossimo incidente.

Ciò dipende dal fatto che i team di ingegneria dispongano di sufficiente autonomia per indagare e agire entro limiti concordati. Il nostro articolo su autonomia ingegneristica e cultura del team esplora perché responsabilità chiare e fiducia siano importanti quando i team sono responsabili dei risultati, non solo delle attività assegnate.

Un piano pratico per l'implementazione dell'osservabilità delle applicazioni

L'osservabilità delle applicazioni viene implementata al meglio per fasi. L'obiettivo è stabilire un modello tecnico e operativo riutilizzabile prima di estenderlo all'intero ambiente.

1. Scegli i flussi critici. Identifica due o tre percorsi utente o operativi in cui un guasto crea un impatto significativo. Lasciati guidare dalla cronologia degli incidenti, dal volume delle richieste di supporto, dalle dipendenze aziendali e dai rischi di delivery imminenti.
2. Mappa il flusso. Documenta le applicazioni, i servizi, gli archivi dati, le code, l'infrastruttura, le dipendenze esterne, i team e i passaggi di responsabilità coinvolti dall'avvio al completamento corretto.
3. Definisci i segnali di successo e di errore. Identifica gli eventi, le metriche, le tracce e i risultati visibili all'utente necessari per determinare se il flusso è integro.
4. Stabilisci le responsabilità e le aspettative di risposta. Definisci il responsabile del servizio, il percorso di reperibilità o escalation, i destinatari degli avvisi, i diritti decisionali e i primi passaggi di indagine o ripristino.
5. Strumenta il percorso critico. Aggiungi la strumentazione OpenTelemetry o compatibile ai confini applicativi, di integrazione e di elaborazione asincrona. Applica nomi, attributi e contesto di deployment coerenti.
6. Crea dashboard e avvisi mirati. Crea viste per il flusso e avvisi associati a un degrado significativo. Evita dashboard generiche che tentano di rappresentare ogni condizione possibile.
7. Testa l'indagine e il ripristino. Utilizza un guasto controllato, un test di carico, un rilascio o un'esercitazione sugli incidenti per verificare che il team sappia trovare le informazioni pertinenti e seguire il percorso di risposta.
8. Rivedi ed estendi. Migliora etichette, campionamento, avvisi, runbook, accessi e controlli dei costi prima di passare ai flussi di lavoro adiacenti.

Ogni implementazione ha dipendenze che vanno oltre la tecnologia. Gli ingegneri devono avere accesso ai segnali di produzione. Gli stakeholder di prodotto e delle operations devono contribuire a definire risultati utente significativi. I team hanno bisogno di tempo per esaminare i risultati e adeguare il sistema. Un piano che consideri solo l'impegno necessario per la strumentazione, ignorando responsabilità, accessi, processo decisionale e pratica nella gestione degli incidenti, di solito si bloccherà dopo la creazione della prima dashboard.

Dove gli sforzi di osservabilità generalmente falliscono

La maggior parte dei problemi di osservabilità è prevedibile. Affrontarli tempestivamente è meno costoso che cercare di recuperare l'adozione dopo che i team hanno perso fiducia nei segnali.

Strumentare tutto per prima cosa

Una copertura ampia sembra completa, ma spesso comporta costi elevati e poca chiarezza. Inizia dai flussi critici, verifica che il team sappia usare i segnali, poi amplia l'adozione seguendo un modello coerente.

Raccogliere dati senza contesto

Una metrica o un log è molto meno utile quando non può essere collegato al contesto di servizio, ambiente, versione, richiesta, flusso di lavoro, tenant o dipendenza. Definisci le convenzioni prima che le etichette incoerenti diventino costose da ripulire.

Avvisi senza un percorso d'azione

Se un avviso non ha un responsabile, un runbook, un percorso di escalation o una soglia decisionale, diventa un'altra fonte di rumore. La soluzione non consiste semplicemente nell'alzare o abbassare la soglia. Consiste nel progettare l'avviso intorno a una decisione operativa.

Considerare l'osservabilità solo come un progetto di piattaforma

Gli strumenti centralizzati sono preziosi, ma i team più vicini all'applicazione comprendono quali eventi di dominio, modalità di errore e risultati per gli utenti siano importanti. L'osservabilità funziona al meglio quando gli standard della piattaforma e la responsabilità a livello applicativo si rafforzano a vicenda.

Ignorare i costi della telemetria e i rischi per i dati

La raccolta illimitata, le metriche ad alta cardinalità, la conservazione prolungata e i dati sensibili nei log possono compromettere il programma. Inserisci fin dall'inizio nella progettazione il campionamento, la conservazione, le regole sugli attributi, gli accessi e la revisione dei costi.

Quando un partner esterno può essere d'aiuto

Il supporto esterno può essere utile quando le lacune di osservabilità sono sintomi di un problema più ampio nella progettazione e nella distribuzione del software: applicazioni legacy difficili da strumentare, infrastrutture frammentate, responsabilità sui servizi poco chiare, pratiche di gestione degli incidenti assenti, un processo di rilascio inaffidabile o un rischio immediato per l'affidabilità che il team interno non può rimandare in sicurezza.

Ridiculous Engineering aiuta le organizzazioni a valutare la maturità attuale dell'osservabilità, identificare i flussi ad alto valore, definire modelli pratici di strumentazione, migliorare le pratiche di distribuzione e gestione degli incidenti e creare un modello di trasferimento che il team interno possa gestire. L'obiettivo non è creare una dipendenza permanente da una società di consulenza o da uno strumento specifico. È rendere i sistemi più facili da comprendere e i team più capaci di migliorarli.

Questo lavoro spesso si affianca a un più ampio miglioramento di DevOps, infrastruttura come codice, e pratiche di distribuzione affidabili.

Domande frequenti

Che cos'è l'osservabilità delle applicazioni?

L'osservabilità delle applicazioni è la capacità di comprendere il comportamento di un'applicazione esaminando dati di telemetria correlati, come log, metriche e tracce. Aiuta i team a indagare sul motivo per cui si è verificato un problema, sul punto in cui una richiesta o un evento ha avuto esito negativo e sulla condizione del sistema che ha contribuito al risultato.

Qual è la differenza tra osservabilità e monitoraggio?

Il monitoraggio identifica condizioni note che richiedono attenzione, come un tasso di errore elevato o una bassa disponibilità. L'osservabilità fornisce il contesto per indagare su comportamenti sconosciuti o complessi, esplorando log, metriche, tracce, rilasci, dipendenze ed eventi del flusso di lavoro correlati.

Quali sono i principali tipi di dati di osservabilità?

I tre tipi fondamentali di telemetria sono log, metriche e tracce. I team possono utilizzare anche il monitoraggio degli utenti reali, la telemetria del browser, i profili, gli eventi, il contesto della sessione e i test sintetici, quando questi segnali aiutano a spiegare l'esperienza di un flusso di lavoro critico.

Perché i team dovrebbero usare OpenTelemetry?

OpenTelemetry fornisce specifiche aperte, API, SDK, collector e convenzioni semantiche per la telemetria. Può aiutare i team a standardizzare la strumentazione e a ridurre la dipendenza da un unico backend di osservabilità, consentendo al contempo di scegliere strumenti adatti alle proprie esigenze operative.

Come si avvia un'iniziativa di osservabilità?

Inizia con due o tre flussi utente o operativi critici. Mappa i sistemi e le dipendenze coinvolti, definisci gli esiti positivi e negativi, identifica la telemetria necessaria per indagare sui problemi, assegna le responsabilità, strumenta il percorso critico e testa il processo di risposta prima di ampliare ulteriormente l'iniziativa.

Cosa causa l'aumento dei costi dell'osservabilità?

I costi possono aumentare a causa di un volume elevato di eventi, attributi ad alta cardinalità senza limiti, periodi di conservazione prolungati, raccolta duplicata, tracciamento completo e ad alta fedeltà su larga scala e raccolta di telemetria che nessun team utilizza. Il campionamento, le politiche di conservazione, regole chiare sugli attributi e revisioni regolari dei costi aiutano a mantenere la raccolta proporzionata al valore operativo.

Fonti

• Documentazione di OpenTelemetry
• Manuale SRE di Google: implementazione degli obiettivi del livello di servizio
• Manuale SRE di Google: monitoraggio degli SLO

Consigliato

• I giorni della canicola del DevOps: semplificare lo sviluppo e le operazioni
• Infrastructure as Code: guida per gli ingegneri DevOps nel 2026
• Distribuzioni senza tempi di inattività: guida pratica per ingegneri
• Streaming di eventi con Kafka: guida pratica per ingegneri
• Consulenza software e supporto alla distribuzione