Nota. transl.: L'autore di stu materiale hè Cindy Sridharan, un ingegnere in imgix chì hè specializatu in u sviluppu di l'API è, in particulare, a prova di microserviziu. In questu materiale, hà sparte a so visione dettagliata di i prublemi attuali in u campu di a traccia distribuita, induve, in u so parè, ci hè una mancanza di strumenti veramente efficaci per risolve i prublemi pressanti.
[Illustrazione presa da circa a traccia distribuita.]
Hè cume chì difficiuli di implementà, è u ritornu nantu à questu . Ci hè parechje motivi per quessa chì a traccia hè problematica, spessu citendu u travagliu implicatu in a cunfigurazione di ogni cumpunente di u sistema per trasmette l'intestazione adattata cù ogni dumanda. Ancu s'ellu esiste stu prublema, ùn hè micca insurmountable. In modu, ùn spiega micca perchè i sviluppatori ùn piace micca veramente traccia (ancu quandu hè digià funziona).
A sfida principale cù a traccia distribuita ùn hè micca a cullizzioni di dati, a standardizazione di formati per a distribuzione è a presentazione di i risultati, o a determinazione di quandu, induve è cumu per campionà. Ùn sò micca pruvatu à imaginà triviale sti "prublemi di comprensibilità" sò, in fattu, assai tecnichi significativi è (se cunsideremu veramente Open Source) ) sfidi pulitichi chì ci vole à superà per chì sti prublemi sò cunsiderati risolti.
Tuttavia, se imaginemu chì tutti questi prublemi sò risolti, ci hè una alta probabilità chì nunda ùn cambia significativamente in termini di sperienza d'utilizatore finale. A traccia pò ancu micca esse di usu praticu in i scenarii di debugging più cumuni, ancu dopu chì hè statu implementatu.
Una traccia cusì diversa
A traccia distribuita include parechji cumpunenti disparati:
- equipà l'applicazioni è i middleware cù strumenti di cuntrollu;
- trasferimentu di cuntestu distribuitu;
- cullizzioni di tracce;
- almacenamentu di traccia;
- a so estrazione è a visualizazione.
Parlanu assai di traccia distribuita tende à trattà cum'è una spezia di operazione unaria chì u solu scopu hè di aiutà à diagnosticà cumplettamente u sistema. Questu hè in gran parte dovutu à cumu l'idee nantu à a traccia distribuita sò state storicamente formate. IN , fattu quandu i fonti Zipkin sò stati aperti, hè statu mintuatu chì [Zipkin] rende Twitter più veloce. I primi offerte cummirciali per a traccia sò ancu promossi cum'è .
Nota. transl.: Per fà un testu più faciule da capisce, definiscemu dui termini basi secondu :
- Span - l'elementu basi di traccia distribuitu. Hè una descrizzione di un certu flussu di travagliu (per esempiu, una dumanda di basa di dati) cù un nome, tempi di iniziu è di fine, tags, logs è cuntestu.
- I Spans cuntenenu tipicamente ligami à altri spazii, chì permettenu parechje spazii per esse cumminati Trace - visualizazione di a vita di una dumanda cumu si move attraversu un sistema distribuitu.
Tracce cuntenenu dati incredibbilmente preziosi chì ponu aiutà cù attività cum'è teste di produzzione, teste di ricuperazione di disastru, teste di iniezione d'errore, etc. In fatti, alcune cumpagnie usanu digià a traccia per scopi simili. Cuminciamu cù hà altri usi oltri solu di trasfurmà spazii à u sistema di almacenamiento:
- Per esempiu, Uber risultati di traccia per diferenze trà u trafficu di prova è u trafficu di produzzione.
- Facebook dati di traccia per l'analisi di u percorsu criticu è per u cambiamentu di u trafficu durante i testi regulari di ricuperazione di disastru.
- Ancu rete suciale Notebooks Jupyter chì permettenu à i sviluppatori di eseguisce dumande arbitrarie nantu à i risultati di traccia.
- Followers (Iniezione di fallimentu guidata da a linea) tracce distribuite per a prova cù iniezione d'errore.
Nisuna di l'opzioni elencate sopra s'applica interamente à u scenariu debugging, durante quale l'ingegnere prova di risolve u prublema fighjendu a traccia.
Quandu vene ancu righjunghji u script di debugging, l'interfaccia primaria resta u diagramma traceview (Ancu se certi chjamanu ancu "diagramma di Gantt" o "diagramma cascata"). Sottu traceview я tutti i spans è accumpagnamentu metadata chì inseme custituiscenu a traccia. Ogni sistema di traccia open source, è ancu ogni suluzione di traccia cummerciale, offre un traceview interfaccia d'utilizatore per visualizà, dettagliate è filtrà e tracce.
U prublema cù tutti i sistemi di traccia chì aghju vistu finu à avà hè chì u risultatu visualizazione (traceview) quasi cumpletamenti riflette i funziunalità di u prucessu di generazione traccia. Ancu quandu visualizazioni alternative sò pruposte: mappe di calore, topologie di serviziu, histogrammi di latenza, sò sempre in fine. traceview.
In u passatu I chì a maiò parte di "innuvazioni" in u tracciatu UI / UX parenu esse limitati à metadati supplementari in traccia, investendu in elli infurmazioni cù alta cardinalità (alta cardinalità) o furnisce a capacità di drill down in spazii specifichi o eseguite dumande inter- è intra-trace... Induve traceview resta u primu strumentu di visualizazione. Finu à questu statu di l'affari cuntinueghja, a traccia distribuita pigliarà (in u megliu) u 4u postu cum'è un strumentu di debugging, dopu à metriche, logs è stack traces, è à u peghju serà una perdita di soldi è tempu.
Prublemu cù traceview
Purpose traceview - furnisce una stampa cumpleta di u muvimentu di una sola dumanda in tutti i cumpunenti di u sistema distribuitu à quale hè in relazione. Certi sistemi di traccia più avanzati permettenu di drill down in spans individuali è vede un sfondate cù u tempu ind'u un prucessu (quandu i spans anu cunfini funziunali).
A premessa basica di l'architettura di microservizi hè l'idea chì a struttura organizzativa cresce cù i bisogni di a cumpagnia. I sustenitori di i microservizi sustenenu chì a distribuzione di diverse attività cummerciale in servizii individuali permette à i picculi squadre di sviluppu autonomi di cuntrullà u ciclu di vita tutale di tali servizii, dendu l'abilità di custruisce, testà è implementà in modu indipendenti quelli servizii. In ogni casu, u svantaghju di sta distribuzione hè a perdita di l'infurmazioni nantu à cumu ogni serviziu interagisce cù l'altri. In tali cundizioni, a traccia distribuita pretende esse un strumentu indispensabile per debugging interazzione cumplessa trà servizii.
Sì veramente , tandu ùn una sola persona hè capaci di mantene in u so capu cumpletu stampa. In fatti, sviluppà un strumentu basatu annantu à l'assunzione chì hè ancu pussibule hè qualcosa di un anti-pattern (un approcciu inefficace è improduttivu). Ideale, u debugging richiede un strumentu chì aiuta restringe a vostra zona di ricerca, in modu chì l'ingegneri ponu fucalizza nantu à un subset di dimensioni (servizii / utilizatori / ospiti, etc.) pertinenti à u scenariu di prublema chì hè cunsideratu. Quandu determinanu a causa di un fallimentu, l'ingegneri ùn sò micca obligati à capisce ciò chì hè accadutu durante u tutti i servizii in una volta, postu chì una tale esigenza contraddissi l'idea stessa di l'architettura di microserviziu.
Tuttavia, traceview hè dì Questu. Iè, certi sistemi di traccia offrenu traceviews compressi quandu u nùmeru di spazii in a traccia hè cusì grande chì ùn ponu micca esse visualizati in una visualizazione. Tuttavia, per via di a grande quantità di informazioni cuntenute ancu in una visualizazione cusì spogliata, l'ingegneri sò sempre furzatu "sift" it, narrowing manually the selection to a set of services that are sources of problems. Sfurtunatamente, in questu campu, i machini sò assai più veloci di l'omu, menu propensi à l'errori, è i so risultati sò più ripetibili.
Un altru mutivu chì pensu chì traceview hè sbagliatu hè perchè ùn hè micca bonu per a debugging guidata da l'ipotesi. In u so core, u debugging hè iterativu un prucessu chì principia cù una ipotesi, seguita da a verificazione di diverse osservazioni è fatti ottenuti da u sistema à longu di diversi vettori, cunclusioni / generalizazioni è più valutazione di a verità di l'ipotesi.
uppurtunità veloce è prezzu pruvà ipotesi è migliurà u mudellu mentale in cunseguenza hè petra angulare debugging Ogni strumentu di debugging deve esse interattivu è restringe u spaziu di ricerca o, in u casu di un falsu piombo, permettenu à l'utilizatore per vultà è fucalizza nantu à una zona diversa di u sistema. U strumentu perfettu farà questu proattivamente, attirà subitu l'attenzione di l'utilizatori à e zone di prublemi potenziali.
Ahimè, traceview ùn pò esse chjamatu strumentu cù una interfaccia interattiva. U megliu chì pudete sperà quandu l'utilizanu hè di truvà una fonte di latenza aumentata è fighjate tutte e tags è logs pussibuli assuciati cù questu. Questu ùn aiuta micca l'ingegnere à identificà mudelli in u trafficu, cum'è i specifichi di a distribuzione di ritardu, o detect correlations between different measurements. pò aiutà à risolve certi di sti prublemi. Veramente, analisi di successu utilizendu l'apprendimentu di a macchina per identificà spazii anomali è identificà un subset di tags chì ponu esse assuciati cù un cumpurtamentu anomalu. Tuttavia, ùn aghju micca vistu visualizazioni convincenti di l'apprendimentu automaticu o di i risultati di data mining applicati à spazii chì sò significativamente differenti da una traccia o un DAG (graficu aciclicu direttu).
Spans sò troppu bassu livellu
U prublema fundamentale cù traceview hè chì spans sò primitivi troppu bassu per l'analisi di latenza è per l'analisi di a causa radicale. Hè cum'è analizà i cumandamenti individuali di u processatore per pruvà à risolve una eccezzioni, sapendu chì ci sò assai strumenti di livellu più altu cum'è backtrace chì sò assai più convenienti per travaglià.
Inoltre, piglieraghju a libertà di affirmà i seguenti: idealmente, ùn avemu micca bisognu stampa piena accadutu durante u ciclu di vita di a dumanda, chì hè rapprisintatu da strumenti di traccia muderni. Invece, una forma di astrazione di livellu più altu hè necessariu chì cuntene infurmazioni nantu à ciò chì andò male (simile à backtrace), cù qualchì cuntestu. Invece di fighjulà tutta a traccia, preferimu vede parte di, induve succede qualcosa interessante o inusual. Attualmente, a ricerca hè fatta manualmente: l'ingegnere riceve a traccia è analizà indipindentamente i spazii in cerca di qualcosa interessante. L'approcciu di e persone chì fighjanu à spans in tracce individuali in a speranza di detectà l'attività sospetta ùn hè micca scala à tutti (in particulare quandu anu da fà sensu di tutti i metadati codificati in diverse span, cum'è span ID, nome di u metudu RPC, durata di span). 'a, logs, tags, etc.).
Alternative à Traceview
I risultati di traccia sò più utili quandu ponu esse visualizati in una manera chì furnisce un insight non-trivial in ciò chì succede in parti interconnesse di u sistema. Finu à questu succede, u prucessu di debugging ferma largamente inertu è dipende da a capacità di l'utilizatore per avvistà e correlazioni ghjustificate, verificate e parti ghjusti di u sistema, o mette i pezzi di u puzzle inseme - in uppusizione à strumentu, aiutendu l'utilizatori à furmulà sti ipotesi.
Ùn sò micca un disegnatore visuale o un specialista UX, ma in a sezione dopu vogliu sparte uni pochi di idee nantu à ciò chì queste visualizazioni puderanu esse.
Focus nantu à servizii specifichi
In un tempu quandu l'industria si cunsolida intornu à l'idee , Sembra ragiunate chì e squadre individuali anu da priorità à assicurà chì i so servizii sò allinati cù questi scopi. Ne segue chì orientatu à u serviziu a visualizazione hè più adattata per tali squadre.
Tracce, soprattuttu senza sampling, sò un tesoru d'infurmazioni nantu à ogni cumpunente di un sistema distribuitu. Questa informazione pò esse alimentata à un processatore astutu chì furnisce l'utilizatori orientatu à u serviziu I scuperti ponu esse identificati in anticipu - ancu prima chì l'utilizatori fighjenu e tracce:
- Diagrammi di distribuzione di latenza solu per richieste assai prominenti (richiesti eccessivi);
- Diagrammi di distribuzione di ritardu per i casi quandu i scopi di u SLO di serviziu ùn sò micca ottenuti;
- I tag più "cumune", "interessante" è "stranu" in e dumande chì più spessu sò ripetuti;
- Ripartizione di latenza per i casi induve dipendenze i servizii ùn ghjunghjenu micca i so scopi SLO;
- Ripartizione di latenza per diversi servizii downstream.
Alcune di queste dumande ùn sò micca solu risposte da e metriche integrate, furzendu l'utilizatori à scrutinize spans. In u risultatu, avemu un mecanismu estremamente ostili à l'utilizatori.
Questu pone a quistione: chì ne di l'interazzioni cumplessi trà diversi servizii cuntrullati da diverse squadre? Ùn hè micca traceview ùn hè micca cunsideratu u strumentu più apprupriatu per mette in risaltu una tale situazione?
I sviluppatori mobili, i pruprietarii di servizii senza statu, i pruprietarii di servizii statali amministrati (cum'è e basa di dati) è i pruprietarii di e piattaforme ponu esse interessate in qualcosa d'altru. presentazione sistema distribuitu; traceview hè una suluzione troppu generica per questi bisogni fundamentale differenti. Ancu in una architettura di microserviziu assai cumplessa, i pruprietarii di servizii ùn anu micca bisognu di una cunniscenza prufonda di più di dui o trè servizii upstream è downstream. Essenzialmente, in a maiò parte di i scenarii, l'utilizatori solu bisognu di risponde à e dumande riguardanti un settore limitatu di servizii.
Hè cum'è guardà un picculu sottumessu di servizii à traversu una lente d'ingrandimentu per u sguardu. Questu permetterà à l'utilizatori di dumandà dumande più pressanti in quantu à l'interazzioni cumplessi trà questi servizii è e so dipendenze immediata. Questu hè simile à u backtrace in u mondu di i servizii, induve l'ingegnere sapi chì sbagghiatu, è hà dinù qualchi capiscitura di ciò chì succede in servizii circundante à capisce perchè.
L'approcciu chì prumuvutu hè l'esattu oppostu di l'approcciu basatu in traceview, induve l'analisi principia cù a traccia sana è poi gradualmente travaglia finu à spazii individuali. In cuntrastu, un accostu in fondu principia per analizà una piccula zona vicinu à a causa potenziale di l'incidentu, è poi allarga u spaziu di ricerca cum'è necessariu (cù u putenziale di purtà altre squadre per analizà una gamma più larga di servizii). U sicondu approcciu hè megliu adattatu per pruvà rapidamente l'ipotesi iniziali. Una volta ottenuti risultati concreti, serà pussibule passà à un analisi più focu è detallatu.
Custruì una topologia
I punti di vista specifichi di u serviziu ponu esse incredibbilmente utili se l'utilizatore sapi chì un serviziu o gruppu di servizii hè rispunsevuli di aumentà a latenza o di causà errori. In ogni casu, in un sistema cumplessu, identificà u serviziu offensive pò esse un compitu micca trivial durante un fallimentu, soprattuttu s'ellu ùn ci hè statu signalatu missaghju d'errore da i servizii.
A custruzzione di una topulugia di serviziu pò esse un grande aiutu per capisce quale serviziu hà avutu un piccu in i tassi d'errore o un aumentu di a latenza chì face chì u serviziu si degrade notevolmente. Quandu parlu di custruisce una topologia, ùn vogliu micca dì mappa di servizii, affissendu ogni serviziu dispunibule in u sistema è cunnisciutu per u so . Questa vista ùn hè micca megliu cà traceview basatu annantu à un graficu aciclicu direttu. Invece mi piacerebbe vede topologia di serviziu generata dinamicamente, basatu annantu à certi attributi cum'è a rata d'errore, u tempu di risposta, o qualsiasi paràmetru definitu da l'utilizatori chì aiuta à chjarificà a situazione cù servizii specifichi sospetti.
Pigliemu un esempiu. Imaginemu un situ di nutizie ipoteticu. Serviziu di a pagina iniziale (prima pagina) scambia dati cù Redis, cù un serviziu di ricunniscenza, cù un serviziu di publicità è un serviziu di video. U serviziu di video piglia video da S3 è metadata da DynamoDB. U serviziu di ricunniscenza riceve metadata da DynamoDB, carica dati da Redis è MySQL, è scrive missaghji à Kafka. U serviziu di publicità riceve dati da MySQL è scrive missaghji à Kafka.
A sottu hè una rapprisintazioni schematica di sta topulugia (parechji prugrammi di routing cummerciale custruiscenu a topologia). Pò esse utile s'ellu avete bisognu di capiscenu a dependenza di u serviziu. Tuttavia, durante debugging, Quandu un certu serviziu (per dì, un serviziu di video) mostra un tempu di risposta aumentatu, una tale topologia ùn hè micca assai utile.
Diagramma di serviziu di un situ di nutizie ipoteticu
U schema quì sottu seria megliu adattatu. Ci hè un prublema cù u serviziu (video) raffiguratu ghjustu in u centru. L'utilizatore l'avvisa immediatamente. Da questa visualizazione, diventa chjaru chì u serviziu di video funziona anormalmente per via di un aumentu di u tempu di risposta S3, chì afecta a velocità di carica di parte di a pagina principale.
Topulugia dinamica chì mostra solu servizii "interessanti".
Topologies generate dinamicamente ponu esse più efficaci cà e carte statiche di serviziu, in particulare in infrastrutture elastiche, auto-scaling. A capacità di paragunà è cuntrastà e topologie di serviziu permette à l'utilizatori di dumandà dumande più pertinenti. E dumande più precise nantu à u sistema sò più prubabile di guidà à una megliu comprensione di u funziunamentu di u sistema.
Display comparativu
Una altra visualizazione utile seria una visualizazione comparativa. Attualmente e tracce ùn sò micca assai adattati per paraguni side-by-side, cusì i paraguni sò generalmente spans. È l'idea principale di questu articulu hè precisamente chì i spazii sò troppu bassu per caccià l'infurmazioni più preziose da i risultati di traccia.
Paragunà dui tracce ùn hè micca bisognu di visualizazioni fundamentalmente novi. In fatti, qualcosa cum'è un histogramma chì rapprisenta a listessa infurmazione cum'è una traccia hè abbastanza. Sorprendentemente, ancu stu metudu simplice pò purtà assai più fruttu cà solu studià duie tracce per separatamente. Ancu più putente seria a pussibilità vede paragone di tracce In totale. Saria estremamente utile per vede cumu un cambiamentu di cunfigurazione di basa di dati implementatu recentemente per attivà GC (raccolta di basura) affetta u tempu di risposta di un serviziu downstream in una scala di parechje ore. Se ciò chì descrive quì sona cum'è un analisi A / B di l'impattu di i cambiamenti infrastrutturali in parechji servizii usendu i risultati di traccia, allora ùn site micca troppu luntanu da a verità.
cunchiusioni
Ùn aghju micca dubbitu l'utilità di a traccia stessa. Credu sinceramente chì ùn ci hè micca altru metudu per a cullizzioni di dati cusì ricchi, causali è contextuali cum'è quellu chì cuntene in una traccia. Tuttavia, crede ancu chì tutte e soluzioni di traccia utilizanu queste dati in modu estremamente inefficace. Sempre chì l'arnesi di traccia restanu appiccicati nantu à a rapprisentazione di traceview, seranu limitati in a so capacità di sfruttà l'infurmazioni preziosi chì ponu esse estratti da e dati cuntenuti in e tracce. Inoltre, ci hè u risicu di sviluppà più una interfaccia visuale completamente antipatica è intuitiva chì limitarà severamente a capacità di l'utilizatore per risolve errori in l'applicazione.
Debugging sistemi cumplessi, ancu cù l'ultimi strumenti, hè incredibilmente difficiule. L'arnesi duveranu aiutà u sviluppatore à formulà è pruvà una ipotesi, furnisce attivamente infurmazione pertinenti, identificendu outliers è nutà e caratteristiche in a distribuzione di ritardi. Per a traccia per diventà l'uttellu di scelta per i sviluppatori quandu risolve i fallimenti di produzzione o risolve i prublemi chì spannu parechji servizii, sò necessarie interfacce d'utilizatori originali è visualizazioni chì sò più coherenti cù u mudellu mentale di i sviluppatori chì creanu è operanu quelli servizii.
Ci hà da piglià un sforzu mentale significativu per disignà un sistema chì rapprisentarà i diversi signali dispunibili in i risultati di traccia in una manera chì hè ottimizzata per facilità di analisi è inferenza. Avete bisognu di pensà à a manera di astrazione di a topologia di u sistema durante a debugging in una manera chì aiuta l'utilizatori à superà i punti cechi senza fighjà tracce individuali o spazii.
Avemu bisognu di una bona astrazione è capacità di stratificazione (in particulare in l'UI). Quelli chì s'adattanu bè in un prucessu di debugging guidatu da l'ipotesi induve pudete dumandà iterativamente dumande è pruvà ipotesi. Ùn risolveranu micca automaticamente tutti i prublemi di osservabilità, ma aiutanu à l'utilizatori à affinà a so intuizione è à formulà e dumande più intelligenti. Chjamu per un approcciu più pensativu è innovativu per a visualizazione. Ci hè una vera prospettiva quì per espansione l'orizzonti.
PS da u traduttore
Leghjite puru nant'à u nostru blog:
- «";
- «";
- «».
Source: www.habr.com