Noat. transl.: De skriuwer fan dit materiaal is Cindy Sridharan, in yngenieur by imgix dy't spesjalisearre is yn API-ûntwikkeling en, yn it bysûnder, mikroservice-testen. Yn dit materiaal dielt se har detaillearre fisy op aktuele problemen op it mêd fan ferdield tracing, wêr't, nei har miening, in gebrek is oan echt effektive ark foar it oplossen fan driuwende problemen.
[Yllustraasje nommen út oer ferspraat tracing.]
It is leauwe dat dreech út te fieren, en it rendemint derop . D'r binne in protte redenen wêrom't tracing problematysk is, faaks ferwizend nei de arbeid dy't belutsen is by it konfigurearjen fan elke systeemkomponint om de passende kopteksten mei elk fersyk te stjoeren. Hoewol dit probleem bestiet, is it perfoarst net te oerkommen. Trouwens, it ferklearret net wêrom't ûntwikkelders net echt fan tracing hâlde (sels as it al funksjonearret).
De wichtichste útdaging mei ferdield tracing is net sammeljen fan gegevens, standerdisearring fan formaten foar it fersprieden en presintearjen fan resultaten, of bepale wannear, wêr en hoe te stekproef. Ik besykje my net foar te stellen triviale dizze "fersteanberensproblemen" binne yn feite frij wichtige technyske en (as wy wirklik Open Source beskôgje) ) politike útdagings dy't oerwûn wurde moatte om dizze problemen as oplost beskôge te wurden.
As wy ús lykwols yntinke dat al dizze problemen oplost binne, is der in grutte kâns dat neat signifikant feroaret yn termen fan ein brûkersûnderfining. Tracing kin noch altyd net fan praktysk nut wêze yn 'e meast foarkommende debuggen-senario's - sels nei't it is ynset.
Sa'n oar spoar
Ferspraat tracing omfettet ferskate ûnderskate komponinten:
- tapassing fan applikaasjes en middleware mei kontrôle ark;
- ferspraat kontekst oerdracht;
- kolleksje fan spoaren;
- spoar opslach;
- harren winning en fisualisaasje.
In soad praat oer ferspraat tracing hat de neiging om it te behanneljen as in soarte fan unêre operaasje wêrfan it ienige doel is om it systeem folslein te diagnostizen. Dit is foar in grut part te tankjen oan hoe't ideeën oer ferspraat tracing histoarysk foarme binne. YN , makke doe't de Zipkin boarnen waarden iepene, It waard neamd dat it [Zipkin] makket Twitter flugger. De earste kommersjele oanbod foar tracing waarden ek befoardere as .
Noat. transl.: Om fierdere tekst makliker te begripen, lit ús twa basisbegripen definiearje neffens :
- span - it basiselemint fan ferspraat tracing. It is in beskriuwing fan in bepaalde workflow (bygelyks in databankfraach) mei in namme, start- en eintiden, tags, logs en kontekst.
- Spannen befetsje typysk keppelings nei oare spans, wêrtroch meardere spans kinne wurde kombineare yn Spoar - fisualisaasje fan it libben fan in fersyk as it beweecht troch in ferspraat systeem.
Spoaren befetsje ongelooflijk weardefolle gegevens dy't kinne helpe mei taken lykas produksje testen, disaster recovery testen, flater ynjeksje testen, ensfh. Yn feite brûke guon bedriuwen al tracing foar ferlykbere doelen. Litte wy begjinne mei hat oare gebrûk neist gewoan ferpleatse spanten nei it opslachsysteem:
- Bygelyks, Uber tracing resultaten om ûnderskied te meitsjen tusken testferkear en produksjeferkear.
- facebook spoargegevens foar krityske paadanalyse en foar ferkearswikseling tidens reguliere ramphersteltests.
- Ek sosjale netwurk Jupyter-notebooks wêrtroch ûntwikkelders willekeurige fragen kinne útfiere op spoarresultaten.
- Folgers (Lineage Driven Failure Injection) ferspraat spoaren foar testen mei flater ynjeksje.
Gjin fan 'e hjirboppe neamde opsjes jildt folslein foar it senario debug, wêrby't de yngenieur besiket it probleem op te lossen troch nei it spoar te sjen.
As it komt dochs berikt it debuggen skript, bliuwt de primêre ynterface it diagram traceview (hoewol't guon it ek neame "Gantt-diagram" of "wetterfal diagram"). Ûnder traceview я alle spanten en byhearrende metadata dy't mei-inoar it spoar útmeitsje. Elk iepen boarne tracingsysteem, lykas elke kommersjele tracing-oplossing, biedt in traceview brûkersynterface foar fisualisearjen, detaillearjen en filterjen fan spoaren.
It probleem mei alle tracing systemen Ik haw sjoen oant no ta is dat de resultearjende fisualisaasje (traceview) hast folslein wjerspegelet de skaaimerken fan de spoar generaasje proses. Sels as alternative fisualisaasjes foarsteld wurde: waarmtekaarten, tsjinsttopologyen, latencyhistogrammen, komme se úteinlik dochs del op traceview.
Yn it ferline I dat de measte "ynnovaasjes" yn UI / UX tracing lykje te wêzen beheind ta ekstra metadata yn spoar, ynvestearje yn harren ynformaasje mei hege kardinaliteit (hege kardinaliteit) of it leverjen fan de mooglikheid om te boarjen yn spesifike oerienkomsten of queries útfiere inter- en intra-trace... Wherein traceview bliuwt de primêre fisualisaasje ark. Salang't dizze stân fan saken oanhâldt, sil ferspraat tracing (op syn bêst) nimme 4e plak as debuggen ark, nei metrics, logs en stack spoaren, en yn it slimste gefal sil blike te wêzen in fergriemerij fan jild en tiid.
Probleem mei traceview
Doel traceview - in folslein byld leverje fan 'e beweging fan ien fersyk oer alle komponinten fan it ferspraat systeem wêrmei it is relatearre. Guon mear avansearre tracing systemen kinne jo boarje del yn yndividuele oerspanningen en besjoch in ferdieling oer de tiid binnen ien proses (wannear oerspant funksjonele grinzen hawwe).
It basisútgongspunt fan arsjitektuer fan mikrotsjinsten is it idee dat de organisaasjestruktuer groeit mei de behoeften fan it bedriuw. Foarstanners fan mikrotsjinsten beweare dat it fersprieden fan ferskate saaklike taken yn yndividuele tsjinsten lytse, autonome ûntwikkelingsteams mooglik makket om de heule libbenssyklus fan sokke tsjinsten te kontrolearjen, en jouwe se de mooglikheid om selsstannich dy tsjinsten te bouwen, te testen en yn te setten. It neidiel fan dizze ferdieling is lykwols it ferlies fan ynformaasje oer hoe't elke tsjinst mei oaren omgiet. Yn sokke omstannichheden beweart ferspraat tracing in ûnmisber ark foar debug komplekse ynteraksjes tusken tsjinsten.
As jo echt , dan is net ien by steat om it yn 'e holle te hâlden kompleet foto. Yn feite is it ûntwikkeljen fan in ark basearre op de oanname dat it sels mooglik is wat fan in anty-patroan (in net-effektyf en ûnproduktive oanpak). Ideaallik fereasket debuggen in ark dat helpt beheine jo sykgebiet, sadat yngenieurs kinne rjochtsje op in subset fan ôfmjittings (tsjinsten / brûkers / hosts, ensfh) relevant foar it probleem senario wurdt beskôge. By it bepalen fan 'e oarsaak fan in mislearring, binne yngenieurs net ferplichte om te begripen wat der bard is tidens de alle tsjinsten tagelyk, om't sa'n eask it idee fan mikrotsjinst-arsjitektuer yn tsjinspraak soe wêze.
Traceview is lykwols nammentlik Dit. Ja, guon tracingsystemen biede komprimearre traceviews as it oantal spans yn it trace sa grut is dat se net yn ien fisualisaasje kinne wurde werjûn. Lykwols, fanwege de grutte hoemannichte ynformaasje befette sels yn sa'n stripped-down fisualisaasje, yngenieurs noch twongen "sifje" it, de seleksje manuell beheine ta in set tsjinsten dy't boarnen fan problemen binne. Spitigernôch, op dit fjild, masines binne folle flugger as minsken, minder gefoelich foar flaters, en harren resultaten binne mear repeatable.
In oare reden dat ik tink dat traceview ferkeard is, is om't it net goed is foar hypoteze-oandreaune debuggen. Yn har kearn is debuggen iteratyf in proses dat begjint mei in hypoteze, folge troch ferifikaasje fan ferskate waarnimmings en feiten krigen fan it systeem lâns ferskate vectoren, konklúzjes / generalisaasjes en fierdere beoardieling fan 'e wierheid fan' e hypoteze.
kâns fluch en goedkeap testen hypotezen en ferbetterjen fan de mentale model dêrop is hoekstien debuggen Elk debuggen-ark moat wêze ynteraktyf en beheine de sykromte of, yn it gefal fan in falske lead, lit de brûker weromgean en fokusje op in oar gebiet fan it systeem. It perfekte ark sil dit dwaan proaktyf, fuortendaliks de oandacht fan 'e brûker te tekenjen op potinsjele probleemgebieten.
Och, traceview kin net neamd wurde in ark mei in ynteraktive ynterface. It bêste wêrop jo kinne hoopje as jo it brûke is om wat boarne te finen fan ferhege latency en te sjen nei alle mooglike tags en logs dy't dermei ferbûn binne. Dit helpt de yngenieur net te identifisearjen patroanen yn ferkear, lykas de specifics fan de fertraging ferdieling, of detect korrelaasjes tusken ferskillende mjittingen. kin helpe om guon fan dizze problemen te kommen. Werklik, suksesfolle analyze mei help fan masine learen te identifisearjen anomalous spans en identifisearje in subset fan tags dy't kin wurde assosjearre mei anomalous gedrach. Ik haw lykwols noch twingende fisualisaasjes sjoen fan befinings fan masine learen of data mining tapast op spanten dy't signifikant ferskille fan in traceview of in DAG (rjochte acyclyske grafyk).
Spannen binne te leech nivo
It fûnemintele probleem mei traceview is dat spant binne te leech-nivo-primitiven foar sawol latency-analyze as root-oarsaakanalyse. It is as it parsearjen fan yndividuele prosessorkommando's om te besykjen in útsûndering op te lossen, wittende dat d'r ark binne op folle heger nivo lykas backtrace dy't folle handiger binne om mei te wurkjen.
Boppedat sil ik de frijheid nimme it folgjende te beweare: ideaal, wy hoege net folsleine foto barde tidens de libbenssyklus fan fersyk, dy't wurdt fertsjintwurdige troch moderne tracing-ark. Ynstee dêrfan is ien of oare foarm fan abstraksje op heger nivo nedich dy't ynformaasje befettet oer wat gong ferkeard (lykas backtrace), tegearre mei wat kontekst. Ynstee fan it hiele spoar te sjen, sjoch ik it leaver part fan, dêr't wat nijsgjirrich of ûngewoan bart. Op it stuit wurdt it sykjen mei de hân útfierd: de yngenieur ûntfangt it spoar en analysearret selsstannich de spanten op syk nei wat ynteressant. De oanpak fan minsken dy't starre nei spanten yn yndividuele spoaren yn 'e hope op it ûntdekken fan fertochte aktiviteit skaal hielendal net (benammen as se sin moatte meitsje fan alle metadata kodearre yn ferskate spans, lykas span ID, RPC-metoadenamme, spantiid 'a, logs, tags, ensfh.).
Alternativen foar traceview
Trace-resultaten binne it nuttichst as se kinne wurde visualisearre op in manier dy't net-triviale ynsjoch leveret yn wat der bart yn meiinoar ferbûne dielen fan it systeem. Oant dit bart, bliuwt it debuggenproses foar in grut part inert en hinget ôf fan it fermogen fan de brûker om de juste korrelaasjes op te merken, de juste dielen fan it systeem te kontrolearjen, of de puzelstikken byinoar te setten - yn tsjinstelling ta tool, helpt de brûker dizze hypotezen te formulearjen.
Ik bin gjin fisuele ûntwerper of UX-spesjalist, mar yn 'e folgjende seksje wol ik in pear ideeën diele oer hoe't dizze fisualisaasjes der útsjen kinne.
Fokus op spesifike tsjinsten
Yn in tiid dat de yndustry konsolidearret om ideeën , liket it ridlik dat yndividuele teams prioriteit moatte soargje dat har tsjinsten ôfstimd binne mei dizze doelen. It folget dat service rjochte fisualisaasje is it bêste geskikt foar sokke teams.
Spoaren, benammen sûnder sampling, binne in skat oan ynformaasje oer elke komponint fan in ferspraat systeem. Dizze ynformaasje kin wurde fiede nei in slûchslimme prosessor dy't brûkers sil leverje service rjochte befinings. Se kinne fan tefoaren identifisearre wurde - sels foardat de brûker nei de spoaren sjocht:
- Diagrammen foar ferdieling fan latency allinich foar heul promininte oanfragen (outlier fersiken);
- Diagrammen fan fertraging ferdieling foar gefallen doe't tsjinst SLO doelen wurde net berikt;
- De meast "gewoane", "ynteressante" en "raar" tags yn queries dat meast faak wurde werhelle;
- Wachttiid ôfbraak foar gefallen dêr't ôfhinklikens tsjinsten berikke har SLO-doelen net;
- Wachttiid ferdieling foar ferskate downstream tsjinsten.
Guon fan dizze fragen wurde gewoan net beantwurde troch ynboude metriken, wêrtroch brûkers twinge om spanten te besjen. As gefolch hawwe wy in ekstreem brûker-fijannich meganisme.
Dit ropt de fraach op: hoe sit it mei komplekse ynteraksjes tusken ferskate tsjinsten kontrolearre troch ferskate teams? Is it net traceview wurdt net beskôge as it meast geskikte ynstrumint om sa'n situaasje te markearjen?
Mobile ûntwikkelders, eigners fan steatleaze tsjinsten, eigners fan beheare steatlike tsjinsten (lykas databases) en platfoarmeigners kinne ynteressearre wêze yn wat oars presintaasje ferdield systeem; traceview is in te generike oplossing foar dizze fûneminteel ferskillende behoeften. Sels yn in heul komplekse mikroservicearsjitektuer hawwe tsjinsteigners gjin djippe kennis nedich fan mear as twa of trije streamop- en streamôfwerts tsjinsten. Yn essinsje hoege brûkers yn 'e measte senario's allinich fragen te beantwurdzjen oangeande beheinde set fan tsjinsten.
It is as it besjen fan in lytse subset fan tsjinsten troch in fergrutglês om 'e wille fan it ûndersiikjen. Dit sil de brûker mear driuwende fragen kinne stelle oangeande de komplekse ynteraksjes tusken dizze tsjinsten en har direkte ôfhinklikens. Dit is fergelykber mei backtrace yn 'e tsjinstenwrâld, wêr't de yngenieur wit dat ferkeard, en hat ek wat begryp fan wat der bart yn omlizzende tsjinsten te begripen wêrom.
De oanpak dy't ik befoarderje is it krekte tsjinoerstelde fan 'e top-down, traceview-basearre oanpak, wêrby't de analyze begjint mei it heule spoar en dan stadichoan trochwurket nei yndividuele spans. Yn tsjinstelling, begjint in bottom-up oanpak mei it analysearjen fan in lyts gebiet tichtby de potinsjele oarsaak fan it ynsidint, en wreidet dan de sykromte út as nedich (mei it potensjeel om oare teams yn te bringen om in breder oanbod fan tsjinsten te analysearjen). De twadde oanpak is better geskikt foar it fluch testen fan earste hypotezen. Sadree't konkrete resultaten binne krigen, sil it mooglik wêze om troch te gean nei in mear rjochte en detaillearre analyse.
Bouwe in topology
Servicespesifike werjeften kinne ongelooflijk nuttich wêze as de brûker it wit wat in tsjinst of groep fan tsjinsten is ferantwurdlik foar it fergrutsjen fan latency of wêrtroch flaters. Yn in kompleks systeem kin it identifisearjen fan 'e misledigjende tsjinst lykwols in net-triviale taak wêze by in mislearring, foaral as der gjin flaterberjochten waarden rapporteare fan 'e tsjinsten.
It bouwen fan in tsjinsttopology kin in grutte help wêze by it útfine hokker tsjinst in pyk yn flatersifers ûnderfynt of in ferheging fan latency dy't feroarsaket dat de tsjinst merkber degradearret. As ik praat oer it bouwen fan in topology, bedoel ik it net tsjinsten map, werjaan fan elke tsjinst beskikber yn it systeem en bekend om har . Dizze werjefte is net better dan traceview basearre op in rjochte acyclyske grafyk. Ynstee soe ik graach sjen dynamysk oanmakke tsjinst topology, basearre op bepaalde attributen lykas flaterrate, antwurdtiid, of elke troch de brûker definieare parameter dy't helpt om de situaasje te ferdúdlikjen mei spesifike fertochte tsjinsten.
Litte wy in foarbyld nimme. Litte wy ús in hypotetyske nijsside foarstelle. Thússide tsjinst (Foarside) wikselt gegevens út mei Redis, mei in oanbefellingstsjinst, mei in reklametsjinst en in fideotsjinst. De fideotsjinst nimt fideo's fan S3 en metadata fan DynamoDB. De oanbefellingstsjinst ûntfangt metadata fan DynamoDB, laadt gegevens fan Redis en MySQL, en skriuwt berjochten nei Kafka. De reklametsjinst ûntfangt gegevens fan MySQL en skriuwt berjochten nei Kafka.
Hjirûnder is in skematyske foarstelling fan dizze topology (in protte kommersjele routingprogramma's bouwe de topology). It kin nuttich wêze as jo tsjinstôfhinklikens moatte begripe. Lykwols, tidens debug, as in beskate tsjinst (sizze, in fideotsjinst) ferhege responstiid eksposearret, is sa'n topology net heul nuttich.
Servicediagram fan in hypotetyske nijsside
It diagram hjirûnder soe better geskikt wêze. Der is in probleem mei de tsjinst (video) ôfbylde rjochts yn it sintrum. De brûker fernimt it fuortendaliks. Ut dizze fisualisaasje wurdt dúdlik dat de fideotsjinst abnormaal wurket troch in ferheging fan S3-antwurdtiid, dy't ynfloed hat op de laden snelheid fan in diel fan 'e haadside.
Dynamyske topology dy't allinich "ynteressante" tsjinsten werjaan
Dynamysk oanmakke topologyen kinne effisjinter wêze dan statyske tsjinstkaarten, fral yn elastyske, auto-skaaljende ynfrastruktuer. De mooglikheid om tsjinsttopologyen te fergelykjen en te kontrastearjen lit de brûker mear relevante fragen stelle. Mear krekte fragen oer it systeem liede wierskynliker ta in better begryp fan hoe't it systeem wurket.
Fergelykjende werjefte
In oare nuttige fisualisaasje soe in ferlykjende werjefte wêze. Op it stuit binne spoaren net heul geskikt foar side-by-side fergelikingen, dus fergelikingen binne normaal spant. En it haadgedachte fan dit artikel is krekt dat spanten te leech binne om de meast weardefolle ynformaasje út 'e spoarresultaten te heljen.
It fergelykjen fan twa spoaren fereasket gjin fûnemintele nije fisualisaasjes. Yn feite is soksawat as in histogram dat deselde ynformaasje fertsjintwurdiget as in traceview genôch. Ferrassend, sels dizze ienfâldige metoade kin bringe folle mear fruit dan gewoan bestudearjen fan twa spoaren apart. Noch machtiger soe de mooglikheid wêze fisualisearjen ferliking fan spoaren Yn totaal. It soe ekstreem nuttich wêze om te sjen hoe't in resint ynset databankkonfiguraasjewiziging om GC (garbage collection) yn te skeakeljen de reaksjetiid fan in streamôfwerts tsjinst beynfloedet op in skaal fan ferskate oeren. As wat ik hjir beskriuw klinkt as in A/B-analyse fan 'e ynfloed fan feroaringen yn ynfrastruktuer yn in protte tsjinsten mei help fan de spoar resultaten, dan binne jo net te fier fan 'e wierheid.
konklúzje
Ik twifelje net oan it nut fan 'e tracing sels. Ik leau oprjocht dat d'r gjin oare metoade is foar it sammeljen fan gegevens sa ryk, kausaal en kontekstueel as dat yn in spoar is. Ik leau lykwols ek dat alle tracing-oplossingen dizze gegevens ekstreem yneffisjint brûke. Salang't tracing-ark bliuwe fêst op 'e traceview-fertsjintwurdiging, sille se beheind wêze yn har fermogen om it measte te meitsjen fan' e weardefolle ynformaasje dy't kin wurde helle út 'e gegevens yn' e spoaren. Derneist is d'r it risiko om in folslein ûnfreonlike en unintuitive fisuele ynterface fierder te ûntwikkeljen dy't de mooglikheid fan 'e brûker om flaters yn' e applikaasje serieus te beheinen.
Debuggen fan komplekse systemen, sels mei de lêste ark, is ongelooflijk lestich. Tools moatte de ûntwikkelder helpe om in hypoteze te formulearjen en te testen, aktyf leverjen relevante ynformaasje, it identifisearjen fan outliers en it notearjen fan funksjes yn 'e ferdieling fan fertragingen. Foar tracing om it ark fan kar te wurden foar ûntwikkelders by it oplossen fan problemen mei produksjefouten of it oplossen fan problemen dy't meardere tsjinsten omfetsje, binne orizjinele brûkersynterfaces en fisualisaasjes nedich dy't mear oerienkomme mei it mentale model fan 'e ûntwikkelders dy't dizze tsjinsten oanmeitsje en operearje.
It sil wichtige mentale ynspannings nimme om in systeem te ûntwerpen dat de ferskate sinjalen dy't beskikber binne yn 'e spoarresultaten fertsjintwurdigje op in manier dy't is optimalisearre foar gemak fan analyse en konklúzje. Jo moatte tinke oer hoe't jo de systeemtopology kinne abstrahere tidens debuggen op in manier dy't de brûker helpt om bline flekken te oerwinnen sûnder te sjen nei yndividuele spoaren of span.
Wy hawwe goede abstraksje- en lagenmooglikheden nedich (benammen yn 'e UI). Ien dy't goed passe yn in hypoteze-oandreaune debuggenproses wêr't jo iteratyf fragen kinne stelle en hypotezen testen. Se sille net automatysk alle problemen mei observabiliteit oplosse, mar se sille brûkers helpe om har yntuysje oan te skerpjen en tûkere fragen te formulearjen. Ik rop om in mear trochtochte en ynnovative oanpak fan fisualisaasje. D'r is hjir in echt perspektyf om de horizonten út te wreidzjen.
PS fan oersetter
Lês ek op ús blog:
- «";
- «";
- «".
Boarne: www.habr.com