Punti chiave
- Il tracing end-to-end completo è raramente realizzabile nei sistemi distribuiti: fattori come linguaggi diversi, API esterne, componenti legacy e servizi di breve durata creano lacune che non sempre è possibile colmare.
- I dati di tracing mancanti generano problemi più grandi: una visibilità incompleta allunga i tempi di risoluzione e riduce la fiducia nei dati di monitoraggio.
- Una visibilità parziale è comunque utile: standardizzare ciò che si può misurare e correlarlo con i log permette ai team di colmare le lacune per deduzione.
- Le dipendenze esterne richiedono un approccio diverso: per i componenti fuori dal tuo controllo, segui la traccia fin dove arriva e poi usa i dati correlati per dedurre cosa sta succedendo.
Il tracing end-to-end è diventato sempre più importante per i team tecnologici e DevOps che devono mantenere sia strumenti interni sia applicazioni rivolte al pubblico, ma può risultare complesso nei sistemi basati su microservizi distribuiti.
Questa guida spiega cosa può accadere quando il tracing end-to-end si interrompe (o non è possibile) nei sistemi distribuiti e cosa si può fare al riguardo.
Che cos’è il tracing end-to-end
Il tracing end-to-end è il tracciamento completo di una richiesta o di una transazione, dalla richiesta iniziale al suo completamento, attraverso ogni componente di un sistema. Viene usato comunemente per il debug del codice applicativo e per misurare le prestazioni, oltre che per individuare ed eliminare i colli di bottiglia.
Il tracing end-to-end è fondamentale nei sistemi distribuiti basati su microservizi, dove è necessario seguire l’intero percorso di una richiesta attraverso più servizi modulari, invece di limitarsi a registrare l’attività di un’unica base di codice in esecuzione.
Per esempio, quando un utente completa l’acquisto del carrello su un’app di e-commerce basata su microservizi, premendo il pulsante “Paga ora” viene avviata una richiesta. Questa richiesta arriva al web server, che chiama un servizio di elaborazione dei pagamenti il quale, se l’operazione va a buon fine, chiama un servizio email per inviare la conferma d’ordine. Il percorso può non essere lineare né rispettare una sequenza precisa: se viene richiesta anche la conferma d’ordine via SMS, i servizi email e SMS possono essere chiamati contemporaneamente. Tracciare questa richiesta è più complesso che in un’unica base di codice monolitica, dove tutto avviene in un solo punto e in un ordine preciso.
Perché il tracing end-to-end è difficile da realizzare nei sistemi distribuiti
La complessità aumenta nei sistemi distribuiti composti da componenti diversi, che usano linguaggi, librerie e piattaforme differenti. Anche la natura effimera della scalabilità dei microservizi rappresenta una sfida: i nodi vengono creati e distrutti in base alla domanda, e alcuni esistono solo il tempo necessario a servire una singola richiesta. Quando un nodo viene rimosso, con esso spariscono anche i dati di tracing che non sono ancora stati salvati altrove.
Tra gli altri problemi frequenti che rendono difficile il tracing end-to-end ci sono:
- Sistemi che non supportano affatto il tracing
- Servizi esterni (ad esempio API di comunicazione) privi di visibilità
- Componenti legacy
- Formati di dati non uniformi
I database rappresentano una sfida particolare. Privilegiano le prestazioni ed eseguono le query in parallelo per ottimizzare letture e scritture: questo rende difficile capire quale richiesta specifica stia causando un problema di prestazioni nei momenti di attività intensa.
Problema: i sistemi distribuiti creano lacune di osservabilità
Un tracing end-to-end completo richiede visibilità su ogni componente. Nei sistemi distribuiti questi componenti possono essere molto diversi tra loro, per esempio:
- Codice personalizzato in esecuzione in container, in cui l’attività può essere monitorata nel dettaglio
- Servizi cloud-native come i worker serverless, che possono offrire informazioni limitate
- API di terze parti che non offrono alcuna osservabilità
Questi componenti possono essere in esecuzione sullo stesso host oppure distribuiti, a seconda della tua applicazione. Anche quelli che si trovano nello stesso ambiente possono non integrarsi direttamente, perché usano linguaggi e sistemi operativi diversi e richiedono librerie differenti per monitorare l’attività. Persino i sistemi distribuiti progettati fin dall’inizio tenendo conto dell’osservabilità possono col tempo sviluppare lacune man mano che evolvono.
Soluzione: migliorare la visibilità senza un tracing completo
Non bisogna rinunciare al tracing end-to-end solo perché non si riesce a tracciare tutto. Anche quando un tracing completo non è realizzabile per alcuni sistemi, puoi assicurarti di raccogliere in modo coerente tutti i dati disponibili: lavora con ciò che hai.
Questo significa fare in modo che ciò che può essere misurato venga misurato in modo standardizzato, così da poter essere analizzato e non andare sprecato. Dove hai il controllo, aumenta l’integrazione e la strumentazione per raccogliere quante più informazioni diagnostiche possibili.
Problema: l’impatto dei dati di tracing mancanti
A loro volta, i dati incompleti creano problemi specifici, tra cui:
- Difficoltà nell’individuare le cause principali
- Tempi più lunghi per risolvere gli incidenti
- Interpretazioni errate del comportamento del sistema
- Minore fiducia nei dati di monitoraggio
Tutto questo può compromettere l’utilità dei dati di alta qualità che riesci comunque a raccogliere.
Soluzione: lavorare con una visibilità parziale
Le lacune possono essere colmate per deduzione. Per esempio, il monitoraggio delle prestazioni delle applicazioni può fornire informazioni che aiutano a dedurre cosa accade all’interno dei componenti “black box”, mentre le query dei database possono essere profilate separatamente negli ambienti di test, quando non è pratico isolare l’attività in produzione.
Questi dati possono essere correlati con quelli di tracing e con i log, permettendoti di individuare schemi ricorrenti e colmare le lacune.
Problema: confini del sistema e dipendenze esterne
Le dipendenze esterne come le API, i sistemi in esecuzione in ambienti eterogenei e i sistemi legacy che non possono essere aggiornati con funzionalità di tracing rendono difficile seguire una richiesta per tutto il suo ciclo di vita.
Soluzione: il ruolo del contesto nel tracing distribuito
Segui il più possibile, fin dove puoi, usando gli strumenti di tracing, e colma le lacune correlando le statistiche come descritto sopra. Questo è possibile solo se conosci a fondo il sistema che stai monitorando: così puoi concentrarti sulle informazioni giuste senza inseguire false piste e senza provare a risolvere problemi che non dipendono da te.
Migliorare l’osservabilità per il tracing end-to-end nei sistemi distribuiti
Le applicazioni non esistono nel vuoto: servono a supportare utenti reali nelle loro attività quotidiane, e proprio quegli utenti possono spesso aiutare a individuare comportamenti anomali. Il tracing end-to-end può essere agevolato scegliendo una soluzione di monitoraggio dell’infrastruttura in grado anche di acquisire ed elaborare dati provenienti da altre fonti di monitoraggio e di inviare avvisi quando vengono rilevate anomalie. In combinazione con l’helpdesk, sia le misure automatizzate sia gli utenti finali possono segnalare problemi applicativi e avviare un’indagine immediata, aumentando la probabilità che i dati rilevanti vengano acquisiti.
