Nota di traduzione.: L'autore di questo materiale è Cindy Sridharan, ingegnere dell'azienda imgix, che si occupa di sviluppo API e, in particolare, di test dei microservizi. In questo articolo condivide la sua visione approfondita dei problemi attuali nel campo della tracciatura distribuita, dove, secondo lei, c'è una mancanza di strumenti veramente efficaci per affrontare le questioni urgenti.
[L'illustrazione è stata presa da sulla tracciatura distribuita.]
Si ritiene che sia difficile da implementare, e che il suo ritorno . La
difficoltà non sono affatto queste "questioni di apprendimento" — in effetti, esistono sfide tecniche e (se consideriamo realmente gli ) politiche significative da affrontare per considerare questi problemi risolti.
Tuttavia, se si suppone che tutti questi problemi siano risolti, è molto probabile che nulla cambi sostanzialmente dal punto di vista dell'esperienza dell'utente finale. La tracciatura potrebbe comunque non fornire benefici pratici nei più comuni scenari di debug — anche dopo essere stata implementata.
Una tracciatura così diversa
La tracciatura distribuita comprende diversi componenti disgiunti:
- l'integrazione delle applicazioni e del middleware con strumenti di monitoraggio;
- la trasmissione del contesto distribuito;
- la raccolta delle tracciature;
- la conservazione delle tracciature;
- il loro recupero e visualizzazione.
Molti discorsi sul tracing distribuito si riducono a considerarlo come un'operazione unaria, il cui unico scopo è aiutare nella diagnosi completa del sistema. Questo è in gran parte legato a come storicamente si sono formate le idee sul tracing distribuito. , fatto quando sono stati aperti i sorgenti di Zipkin, si accennava che [Zipkin] rende Twitter più veloce.Le prime offerte commerciali per il tracing sono state anche promosse come .
Nota di traduzione.: Per rendere il testo seguente più comprensibile, definiamo due termini di base secondo :
- Span — l'elemento base del tracing distribuito. Rappresenta la descrizione di un certo flusso di lavoro (ad esempio, una richiesta al database) con nome, orari di inizio e fine, tag, log e contesto.
- Gli span di solito contengono riferimenti ad altri span, permettendo di unire molti span in Trace — una visualizzazione della vita della richiesta mentre si sposta attraverso un sistema distribuito.
I trace contengono dati incredibilmente preziosi che possono aiutare in attività come: test in produzione, esecuzione di test di recupero da errori, test con inserimento di errori, ecc. In effetti, alcune aziende già usano il tracing per scopi simili. Iniziamo con il fatto che ha altre applicazioni oltre al semplice spostamento degli span nel sistema di archiviazione:
- Ad esempio, Uber i risultati del tracing per distinguere il traffico di test da quello di produzione.
- Facebook i dati dei trace per analizzare i percorsi critici e per commutare il traffico durante i test regolari di recovery.
- Anche il social network i notebook Jupyter, che consentono agli sviluppatori di eseguire richieste arbitrarie sui risultati del tracing.
- I sostenitori di (Lineage Driven Failure Injection) tracciano distribuiti per test di inserimento errori.
Nessuna delle opzioni sopra elencate appartiene totalmente allo scenario di debug, in cui un ingegnere cerca di risolvere un problema guardando il trace.
Quando si tratta comunque di uno scenario di debug, l'interfaccia principale rimane il diagramma traceview (sebbene alcuni lo chiamino anche «diagramma di Gantt» o «diagramma a cascata»). Con traceview intendo tutti gli span e i metadati correlati che insieme compongono la trace. Ogni sistema di tracciamento open source e ogni soluzione commerciale per il tracciamento offre una traceview interfaccia utente per la visualizzazione, la dettagliatura e il filtro delle trace.
Il problema con tutti i sistemi di tracciamento che ho avuto modo di esaminare fino ad ora è che la visualizzazione finale (traceview) riflette praticamente completamente le caratteristiche del processo di generazione della trace. Anche quando vengono offerte visualizzazioni alternative: mappe di intensità (heatmap), topologie di servizi, istogrammi di latenza, in definitiva si riducono comunque a traceview.
In passato ho che la maggior parte delle "innovazioni" nel campo del tracciamento riguardo all'UI/UX sembrano essere limitate di metadati aggiuntivi nella trace, inserendo informazioni ad alta cardinalità (high-cardinality) o fornendo la possibilità di dettagli sulle singole span o di eseguire query tra e all'interno della trace. In questo modo traceview rimane il principale strumento di visualizzazione. Finché questa situazione persisterà, il tracciamento distribuito occuperà (nel migliore dei casi) il quarto posto come strumento di debugging, dopo metriche, log e stack trace, e nel peggiore dei casi si rivelerà una mera perdita di denaro e tempo.
Il problema con il traceview
Scopo traceview è fornire un quadro completo del percorso di una singola richiesta attraverso tutti i componenti di un sistema distribuito a cui è collegata. Alcuni sistemi di tracciamento più avanzati consentono di dettagliare singole span e visualizzare la suddivisione temporale all'interno di un processo (quando le span hanno confini funzionali).
La premessa fondamentale dell'architettura a microservizi è l'idea che la struttura organizzativa cresce insieme alle esigenze dell'azienda. I sostenitori dei microservizi affermano che la distribuzione di varie attività aziendali su servizi separati consente a piccoli team autonomi di sviluppatori di controllare l'intero ciclo di vita di tali servizi, dando loro la possibilità di creare, testare e distribuire questi servizi in modo indipendente. Tuttavia, un inconveniente di questa distribuzione è la perdita di informazioni su come ogni servizio interagisce con gli altri. In tali condizioni, il tracciamento distribuito si propone come uno strumento indispensabile per di debug interazioni complesse tra i servizi.
Se hai davvero , nessuna persona è in grado di mantenere a mente la sua visione completa. In realtà, sviluppare uno strumento sulla base dell'assunto che sia possibile è una sorta di antipattern (un approccio inefficace e improduttivo). Idealmente, per il debug serve uno strumento che aiuti a ristretta l'area di ricerca, affinché gli ingegneri possano concentrarsi su un sottoinsieme di misurazioni (servizi/utenti/host, ecc.) pertinenti allo scenario del problema in esame. Nel determinare la causa di un guasto, gli ingegneri non hanno l'obbligo di comprendere cosa stava accadendo in tutti i servizi contemporaneamente, poiché tale requisito violerebbe l'idea stessa dell'architettura a microservizi.
Tuttavia, traceview rappresenta proprio questo. Sì, alcuni sistemi di tracciamento offrono traceview compatti, quando il numero di span nella traccia è così alto che non può essere visualizzato in un'unica visualizzazione. Tuttavia, a causa dell'elevato volume di informazioni contenute anche in una visualizzazione ridotta, gli ingegneri sono comunque costretti a "filtrare" manualmente, restringendo il campione a un insieme di servizi sorgente dei problemi. Purtroppo, in questo campo, le macchine sono notevolmente più veloci dell'uomo, meno soggette a errori e i loro risultati sono più ripetibili.
Un'altra ragione per cui considero il metodo traceview sbagliato è che si presta male al debug basato su ipotesi. Alla base, il debug è iterativo il processo che inizia con un'ipotesi, seguito dalla verifica di varie osservazioni e fatti ottenuti dal sistema lungo diversi vettori, conclusioni/generalizzazioni e una successiva valutazione della verità dell'ipotesi.
Capacità veloce e a buon mercato testare le ipotesi e migliorare di conseguenza il modello mentale è fondamentale per il debugging. Qualsiasi strumento di debug deve essere interattivo e restringere lo spazio di ricerca o, in caso di una falsa pista, consentire all'utente di tornare indietro e concentrarsi su un'altra area del sistema. Lo strumento ideale farebbe questo in anticipo, attirando immediatamente l'attenzione dell'utente su aree potenzialmente problematiche.
Purtroppo, traceview non può essere considerato uno strumento con interfaccia interattiva. Il massimo a cui si può aspirare nel suo utilizzo è scoprire una certa fonte di ritardi elevati e rivedere tutti i tag e i log a essa associati. Questo non aiuta l'ingegnere a identificare pattern nel traffico, come le specifiche della distribuzione dei ritardi, o a scoprire correlazioni tra diverse misurazioni. può aiutare a bypassare alcuni di questi problemi. Infatti, di analisi di successo utilizzando il machine learning per identificare anomalie nei span e per identificare un sottoinsieme di tag che potrebbero essere collegati a comportamenti anomali. Tuttavia, finora non ho visto visualizzazioni convincenti dei risultati ottenuti con machine learning o analisi dei dati applicata agli span, che fossero significativamente diverse da traceview o DAG (grafico aciclico diretto).
Gli span sono troppo a basso livello
Il problema fondamentale con traceview è che gli span sono troppo a basso livello come primitivi sia per l'analisi dei ritardi (latency) che per l'analisi delle cause radice. È come analizzare singole istruzioni del processore nel tentativo di risolvere un'eccezione, sapendo che ci sono strumenti di livello più alto come backtrace, con cui è molto più comodo lavorare.
Inoltre, mi permetto di affermare quanto segue: idealmente non abbiamo affatto bisogno di una visione completa che si è verificato durante il ciclo di vita della richiesta, presentata dagli strumenti moderni per il tracciamento. Invece, è necessaria una forma di astrazione di livello superiore che contenga informazioni su cosa è andato storto (simile a un backtrace), insieme a un certo contesto. Anziché osservare l'intero tracciato, preferisco vedere il pezzo, dove accade qualcosa di interessante o insolito. Attualmente, la ricerca avviene manualmente: l'ingegnere ottiene il tracciato e analizza autonomamente gli span in cerca di qualcosa di interessante. Questo approccio, dove le persone scrutano gli span in tracce separate nella speranza di scoprire attività sospette, non è assolutamente scalabile (soprattutto quando devono riflettere su tutti i metadati codificati in vari span, come ID span, nome del metodo RPC, durata dello span, log, tag, ecc.).
Alternative a traceview
I risultati del tracciamento sono più utili quando possono essere visualizzati in modo da fornire una rappresentazione non banale di ciò che accade nelle parti interconnesse del sistema. Finché questo non avviene, il processo di debug rimane in gran parte inerte e dipende dalla capacità dell'utente di individuare le giuste correlazioni, controllare le parti giuste del sistema o riunire i pezzi di un mosaico—diversamente da strumento, che aiuta l'utente a formulare queste ipotesi.
Non sono un designer visivo né un esperto di UX, ma nella sezione successiva voglio condividere alcune idee su come potrebbero apparire tali visualizzazioni.
Focus su servizi specifici
In un contesto in cui il settore si sta consolidando attorno ai concetti , sembra ragionevole che i singoli team debbano principalmente monitorare la conformità dei propri servizi a questi obiettivi. Ne consegue che una visualizzazione orientata al servizio è la più adatta per tali team.
I tracciati, specialmente senza campionamento, sono una miniera d'informazioni su ogni componente di un sistema distribuito. Queste informazioni possono essere fornite a un intelligente elaboratore, che fornirà agli utenti risultati orientati al servizio. Possono essere identificati in anticipo—ancora prima che l'utente guardi i tracciati:
- Diagrammi di distribuzione dei ritardi solo per richieste anomale (richieste anomale);
- Diagrammi di distribuzione dei ritardi nei casi in cui non vengono raggiunti gli obiettivi SLO del servizio;
- I tag più "comuni", "interessanti" e "strani" nelle richieste che si ripetono più spesso si ripetono;
- Suddivisione dei ritardi per i casi in cui le dipendenze del servizio non raggiungono gli obiettivi SLO stabiliti;
- Suddivisione dei ritardi per diversi servizi downstream.
Su alcune di queste domande, le metriche integrate semplicemente non possono rispondere, costringendo gli utenti a esaminare attentamente gli span. Di conseguenza, abbiamo un meccanismo estremamente ostile per l'utente.
A questo proposito, sorge la domanda: cosa ne è delle interazioni complesse tra vari servizi controllati da team diversi? Non è traceview il modo più appropriato per illuminare tale situazione?
Gli sviluppatori mobili, i proprietari di servizi stateless, i proprietari di servizi stateful gestiti (come i database) e i proprietari di piattaforme potrebbero essere interessati a un'altra rappresentazione del sistema distribuito; traceview è una soluzione troppo generica per queste esigenze fondamentalmente diverse. Anche in un'architettura di microservizi molto complessa, i proprietari dei servizi non hanno bisogno di una conoscenza approfondita di più di due o tre servizi upstream e downstream. In sostanza, nella maggior parte degli scenari, agli utenti basta rispondere a domande riguardanti un insieme limitato di servizi..
È come osservare un piccolo sottoinsieme di servizi attraverso una lente d'ingrandimento per uno studio meticoloso. Questo permetterà all'utente di porre domande più urgenti riguardanti l'interazione complessa tra questi servizi e le loro immediate dipendenze. È simile a un backtrace nel mondo dei servizi, dove l'ingegnere sa cosa non solo come, ma ha anche una certa comprensione di ciò che accade nei servizi circostanti per comprendere. perché.
L'approccio che propongo è l'opposto totale dell'approccio "dall'alto verso il basso", basato su traceview, in cui l'analisi inizia con l'intero trace, per poi scendere gradualmente ai singoli span. Al contrario, l'approccio "dal basso verso l'alto" inizia analizzando una piccola area, vicina alla potenziale causa dell'incidente, e poi l'area di ricerca si espande se necessario (con possibile coinvolgimento di altri team per analizzare un più ampio spettro di servizi). Questo secondo approccio è meglio adattato per una verifica rapida delle ipotesi iniziali. Una volta ottenuti risultati concreti, si può passare a un'analisi più mirata e dettagliata.
Costruzione della topologia
Le visualizzazioni legate a un servizio specifico possono rivelarsi incredibilmente utili se l'utente sa qual è il servizio o gruppo di servizi responsabile dell'aumento delle latenze o fonte di errori. Tuttavia, in un sistema complesso, identificare il servizio colpevole può rivelarsi un compito non banale durante un guasto, soprattutto se non ci sono messaggi di errore dai servizi.
La costruzione della topologia dei servizi può aiutare molto a determinare quale servizio mostra un picco nella frequenza degli errori o un aumento della latenza, portando a un evidente deterioramento delle prestazioni del servizio. Parlando di costruzione della topologia, non intendo una mappa dei servizi, che mostri ogni servizio presente nel sistema e noto per le sue . Una tale rappresentazione non è migliore di traceview basato su grafi aciclici orientati. Invece, mi piacerebbe vedere una topologia dei servizi generata dinamicamente, basata su specifici attributi, come la frequenza degli errori, il tempo di risposta o qualsiasi parametro definito dall'utente che aiuti a chiarire la situazione con determinati servizi sospetti.
Prendiamo un esempio. Immaginiamo un ipotetico sito di notizie. Il servizio della homepage (<front page>) scambia dati con Redis, con il servizio di raccomandazioni, con il servizio pubblicitario e con il servizio video. Il servizio video acquisisce i video da S3, mentre i metadati provengono da DynamoDB. Il servizio di raccomandazioni riceve i metadati da DynamoDB, carica i dati da Redis e MySQL e invia messaggi a Kafka. Il servizio pubblicitario riceve dati da MySQL e invia messaggi a Kafka.
Di seguito è riportata un'immagine schematica di questa topologia (molti programmi commerciali per la tracciatura costruiscono la topologia). Può essere utile se si ha bisogno di comprendere le dipendenze dei servizi. Tuttavia, durante di debug, quando un certo servizio (ad esempio, il servizio video) mostra un tempo di risposta aumentato, una tale topologia non è particolarmente utile.
Schema dei servizi di un ipotetico sito di notizie
Sarebbe stata più appropriata una diagramma rappresentato di seguito. In essa, il servizio problematico (video) è mostrato proprio al centro. L'utente lo nota immediatamente. Da questa visualizzazione risulta chiaro che il servizio video sta funzionando in modo anomalo a causa dell'aumento del tempo di risposta di S3, che influisce sulla velocità di caricamento di una parte della homepage.
Topologia dinamica che mostra solo i servizi "interessanti"
Le schemi topologici generati dinamicamente possono rivelarsi più efficaci rispetto alle mappe statiche dei servizi, specialmente in infrastrutture elastiche e autoscalabili. La possibilità di confrontare e abbinare le topologie dei servizi consente all'utente di porre domande più pertinenti. Domande più precise sul sistema portano con maggiore probabilità a una migliore comprensione del funzionamento del sistema.
Visualizzazione comparativa
Un'altra visualizzazione utile sarà la visualizzazione comparativa. Al momento, le trace non si adattano molto bene a un confronto fianco a fianco, quindi di solito si confrontano gli span. E l'idea principale di questo articolo è proprio che gli span sono troppo a basso livello per estrarre le informazioni più preziose dai risultati della tracciatura.
Il confronto di due trace non richiede visualizzazioni sostanzialmente nuove. In effetti, è sufficiente qualcosa come un istogramma che rappresenta le stesse informazioni del traceview. È sorprendente, ma anche questo metodo semplice può portare a risultati molto più fruttuosi rispetto allo studio di due trace separatamente. Un'ulteriore potenza deriverebbe dalla possibilità visualizzare confronto dei trace nel complesso. Sarebbe estremamente utile vedere come la recente modifica della configurazione del database con l'inclusione del GC (garbage collection) influisce sui tempi di risposta del servizio downstream nell'arco di alcune ore. Se ciò che descrivo qui sembra simile a un'analisi A/B dell'impatto delle modifiche infrastrutturali in molti servizi attraverso i risultati di tracciamento, allora non sei molto lontano dalla verità.
Conclusione
Non metto in dubbio l'utilità del tracciamento stesso. Credo sinceramente che non ci sia altro metodo per raccogliere dati così ricchi, casuali e contestuali come quelli contenuti nel trace. Tuttavia, considero anche che tutte le soluzioni di tracciamento utilizzino questi dati in modo estremamente inefficace. Finché gli strumenti di tracciamento saranno bloccati nella rappresentazione del traceview, saranno limitati nella loro capacità di massimizzare l'uso delle informazioni preziose che possono essere estratte dai dati contenuti nei trace. Inoltre, c'è il rischio di sviluppare un'interfaccia visiva completamente poco amichevole e poco intuitiva che limiterà gravemente la capacità dell'utente di risolvere i problemi nell'applicazione.
Il debug di sistemi complessi, anche con l'uso degli strumenti più recenti, è incredibilmente difficile. Gli strumenti devono aiutare il programmatore a formulare e verificare un'ipotesi, fornendo attivamente informazioni rilevanti, evidenziando anomalie e notando caratteristiche nella distribuzione delle latenze. Affinché il tracciamento diventi lo strumento preferito dagli sviluppatori per risolvere guasti in produzione o per affrontare problemi che coinvolgono diversi servizi, sono necessarie interfacce utente e visualizzazioni originali, maggiormente in linea con il modello mentale degli sviluppatori che creano e gestiscono questi servizi.
Saranno necessari sforzi mentali significativi per progettare un sistema in grado di rappresentare vari segnali disponibili nei risultati di tracciamento in un modo ottimizzato per facilitare l'analisi e le deduzioni. È necessario pensare a come astrarre la topologia del sistema durante il debug in modo da aiutare l'utente a superare le zone cieche senza dover esaminare singoli trace o span.
Abbiamo bisogno di buone possibilità di astrazione e suddivisione in livelli (soprattutto nell'interfaccia utente). Quelle che si integrino bene nel processo di debug basato su ipotesi, dove è possibile porre domande in modo iterativo e verificare le ipotesi. Non risolveranno automaticamente tutti i problemi di osservabilità, ma aiuteranno gli utenti a raffinarsi nell'intuizione e a formulare domande più ponderate. Invito a un approccio più riflessivo e innovativo nel campo della visualizzazione. Qui c'è una vera prospettiva per ampliare gli orizzonti.
P.S. dal traduttore
Leggi anche nel nostro blog:
- «»;
- «»;
- «».
Fonte: habr.com
