Notu. transl.: La aŭtoro de ĉi tiu materialo estas Cindy Sridharan, inĝeniero ĉe imgix, kiu specialiĝas pri API-disvolviĝo kaj, precipe, pri mikroserva testado. En ĉi tiu materialo, ŝi dividas sian detalan vizion pri aktualaj problemoj en la kampo de distribuita spurado, kie, laŭ ŝia opinio, mankas vere efikaj iloj por solvi urĝajn problemojn.
[Ilustraĵo prenita de pri distribuita spurado.]
Ĝi kredas ke malfacile efektivigebla, kaj la reveno sur ĝi . Estas multaj kialoj kial paŭsado estas problema, ofte citante la laboron implikitan en agordo de ĉiu sistema komponento por transdoni la taŭgajn titolojn kun ĉiu peto. Kvankam ĉi tiu problemo ekzistas, ĝi neniel estas nesuperebla. Cetere, ĝi ne klarigas kial programistoj ne tre ŝatas spuradon (eĉ kiam ĝi jam funkcias).
La ĉefa defio kun distribuita spurado ne estas kolekti datumojn, normigi formatojn por distribui kaj prezenti rezultojn, aŭ determini kiam, kie kaj kiel specimeni. Mi ne provas imagi bagatela ĉi tiuj "komprenebloproblemoj" estas, fakte, sufiĉe signifaj teknikaj kaj (se ni konsideras vere Malferma Kodon) ) politikaj defioj kiuj devas esti venkitaj por ke tiuj problemoj estu konsiderataj solvitaj.
Tamen, se ni imagas, ke ĉiuj ĉi tiuj problemoj estas solvitaj, estas alta probablo, ke nenio ŝanĝiĝos signife rilate al sperto de fina uzanto. Spurado eble ankoraŭ ne estas de praktika uzo en la plej oftaj sencimigaj scenaroj—eĉ post kiam ĝi estis deplojita.
Tia malsama spuro
Distribuita paŭsaĵo inkludas plurajn malsimilajn komponentojn:
- ekipi aplikojn kaj mezvarojn per kontroliloj;
- distribuita kunteksta translokigo;
- kolekto de spuroj;
- stokado de spuroj;
- ilia eltiro kaj bildigo.
Multe da parolado pri distribuita spurado inklinas trakti ĝin kiel specon de nevaria operacio, kies sola celo estas helpi plene diagnozi la sistemon. Tio estas plejparte pro kiel ideoj pri distribuita spurado estis historie formitaj. EN , farita kiam la Zipkin-fontoj estis malfermitaj, estis menciite ke ĝi [Zipkin] igas Twitter pli rapida. La unuaj komercaj proponoj por spurado ankaŭ estis reklamitaj kiel .
Notu. transl.: Por plifaciligi plian tekston, ni difinu du bazajn terminojn laŭ :
- interspaco — la baza elemento de distribuita spurado. Ĝi estas priskribo de certa laborfluo (ekzemple, datumbaza demando) kun nomo, komenco kaj fintempoj, etikedoj, protokoloj kaj kunteksto.
- Interspacoj tipe enhavas ligilojn al aliaj interspacoj, permesante al multoblaj interspacoj esti kombinitaj en Streku — bildigo de la vivo de peto dum ĝi moviĝas tra distribuita sistemo.
Spuroj enhavas nekredeble valorajn datumojn, kiuj povas helpi kun taskoj kiel produktadtestado, katastrofa reakiro, erara injektotestado ktp. Fakte, iuj kompanioj jam uzas spuradon por similaj celoj. Ni komencu per havas aliajn uzojn krom simple movi interspacojn al la stokadsistemo:
- Ekzemple, Uber spuri rezultojn por diferenci inter prova trafiko kaj produktadtrafiko.
- Facebook spurdatenoj por analizo de kritika vojo kaj por trafikŝanĝo dum regulaj provoj pri katastrofa reakiro.
- Ankaŭ socia reto Jupyter-kajeroj, kiuj permesas al programistoj fari arbitrajn demandojn pri spurrezultoj.
- Sekvantoj (Lineage Driven Failure Injekto) disdonitaj spuroj por testado kun erara injekto.
Neniu el la supre listigitaj elektoj validas tute por la scenaro elpurigi, dum kiu la inĝeniero provas solvi la problemon rigardante la spuron.
Kiam ĝi venas tamen atingas la sencimigan skripton, la primara interfaco restas la diagramo spurvido (kvankam kelkaj ankaŭ nomas ĝin " Diagramo de Gantt " aŭ "akvofaldiagramo"). Sub spurvido я ĉiuj interspacoj kaj akompanaj metadatenoj kiuj kune konsistigas la spuron. Ĉiu malfermfonta spursistemo, same kiel ĉiu komerca spura solvo, ofertas a spurvido uzantinterfaco por bildigi, detaligi kaj filtri spurojn.
La problemo kun ĉiuj spursistemoj, kiujn mi ĝis nun vidis, estas, ke la rezulta bildigo (spurvido) preskaŭ tute reflektas la trajtojn de la procezo de generado de spuroj. Eĉ kiam alternativaj bildigoj estas proponitaj: varmomapoj, servaj topologioj, latenciaj histogramoj, ili ankoraŭ finfine venas al spurvido.
En la pasinteco mi ke la plej multaj "novaĵoj" en UI/UX-spurado ŝajnas esti limigitaj al pliaj metadatenoj en spuro, investante en ili informojn kun alta kardinaleco (alta kardinaleco) aŭ disponigante la kapablon bori malsupren en specifajn interspacojn aŭ ruli demandojn inter- kaj intra-spuro... En kio spurvido restas la ĉefa bildilo. Dum ĉi tiu stato daŭras, distribuita spurado (en la plej bona kazo) okupos la 4-an lokon kiel sencimiga ilo, post metrikoj, ŝtipoj kaj stakspuroj, kaj plej malbone ĝi rezultos esti malŝparo de mono kaj tempo.
Problemo kun traceview
Intenco spurvido — provizi kompletan bildon de la movado de ununura peto tra ĉiuj komponentoj de la distribuita sistemo al kiu ĝi rilatas. Iuj pli altnivelaj spursistemoj permesas vin trabori en individuajn interspacojn kaj vidi paneon laŭlonge de la tempo interne unu procezo (kiam interspacoj havas funkciajn limojn).
La baza kondiĉo de mikroserva arkitekturo estas la ideo, ke la organiza strukturo kreskas kun la bezonoj de la kompanio. Propagandantoj de mikroservoj argumentas ke distribui diversajn komercajn taskojn en individuajn servojn permesas al malgrandaj, sendependaj evoluigteamoj kontroli la tutan vivociklon de tiaj servoj, donante al ili la kapablon sendepende konstrui, testi kaj deploji tiujn servojn. Tamen, la malavantaĝo de ĉi tiu distribuo estas la perdo de informoj pri kiel ĉiu servo interagas kun aliaj. En tiaj kondiĉoj, distribuita spurado asertas esti nemalhavebla ilo por elpurigi kompleksaj interagoj inter servoj.
Se vi vere , tiam eĉ ne unu homo kapablas teni ĝin en sia kapo kompleta bildo. Fakte, disvolvi ilon bazitan sur la supozo, ke ĝi eĉ eblas, estas io de kontraŭŝablono (neefika kaj neproduktiva aliro). Ideale, senararigado postulas ilon kiu helpas mallarĝigu vian serĉareon, tiel ke inĝenieroj povas temigi subaron de grandeco (servoj/uzantoj/gastigantoj, ktp.) signifa al la problemscenaro estanta pripensita. Kiam oni determinas la kaŭzon de fiasko, inĝenieroj ne devas kompreni kio okazis dum la ĉiuj servoj samtempe, ĉar tia postulo kontraŭdus la ideon mem de mikroserva arkitekturo.
Tamen, traceview estas nome Ĉi tio. Jes, iuj spursistemoj ofertas kunpremitajn spurvidojn kiam la nombro da interspacoj en la spuro estas tiom granda ke ili ne povas esti montrataj en unu bildigo. Tamen, pro la granda kvanto de informoj enhavita eĉ en tia senvestigita bildigo, inĝenieroj ankoraŭ devigita "kribri" ĝin, mane malvastigante la elekton al aro da servoj, kiuj estas fontoj de problemoj. Bedaŭrinde, en ĉi tiu kampo, maŝinoj estas multe pli rapidaj ol homoj, malpli inklinaj al eraroj, kaj iliaj rezultoj estas pli ripeteblaj.
Alia kialo, ke mi pensas, ke traceview estas malĝusta, estas ĉar ĝi ne estas bona por hipotezo-movita senararigado. Ĉe ĝia kerno, senararigado estas ripeta procezo komencanta per hipotezo, sekvita per konfirmo de diversaj observoj kaj faktoj akiritaj de la sistemo laŭ malsamaj vektoroj, konkludoj/ĝeneraligoj kaj plia takso de la vero de la hipotezo.
Ebleco rapida kaj malmultekosta testi hipotezojn kaj plibonigi la mensan modelon sekve estas bazŝtono senararigado Ajna sencimiga ilo devus esti interaga kaj malvastigu la serĉan spacon aŭ, en la kazo de falsa konduko, permesu al la uzanto reiri kaj koncentriĝi sur malsama areo de la sistemo. La perfekta ilo faros tion proaktive, tuj altirante la atenton de la uzanto al eblaj problemaj areoj.
Ve, spurvido ne povas esti nomata ilo kun interaga interfaco. La plej bona, kiun vi povas esperi kiam vi uzas ĝin, estas trovi iun fonton de pliigita latenteco kaj rigardi ĉiujn eblajn etikedojn kaj protokolojn asociitajn kun ĝi. Ĉi tio ne helpas la inĝenieron identigi ŝablonoj en trafiko, kiel ekzemple la specifaĵoj de la prokrasta distribuo, aŭ detekti korelaciojn inter malsamaj mezuradoj. povas helpi ĉirkaŭi iujn ĉi tiujn problemojn. Vere, sukcesa analizo uzante maŝinlernadon por identigi nenormalajn interspacojn kaj identigi subaron de etikedoj kiuj povas esti asociitaj kun nenormala konduto. Tamen, mi ankoraŭ ne vidis konvinkajn bildigojn de maŝinlernado aŭ datumminado-trovoj aplikitaj al interspacoj kiuj estas signife malsamaj de spurvido aŭ DAG (direktita acikla grafeo).
Interspacoj estas tro malalta nivelo
La fundamenta problemo kun traceview estas tio etendiĝas estas tro malaltnivelaj primitivuloj por kaj latenta analizo kaj analizo de radika kaŭzo. Estas kiel analizi individuajn procesorajn komandojn por provi solvi escepton, sciante, ke ekzistas multe pli altnivelaj iloj kiel retrospuro, kun kiuj estas multe pli oportune labori.
Cetere, mi prenos la liberecon aserti la jenon: ideale, ni ne bezonas plena bildo okazis dum la peta vivociklo, kiu estas reprezentita per modernaj spuriloj. Anstataŭe, iu formo de pli altnivela abstraktado estas postulata, kiu enhavas informojn pri kio fuŝiĝis (simila al retrospuro), kune kun iu kunteksto. Anstataŭ rigardi la tutan spuron, mi preferas vidi ĝin parto de, kie okazas io interesa aŭ nekutima. Nuntempe, la serĉo estas farita permane: la inĝeniero ricevas la spuron kaj sendepende analizas la interspacojn serĉante ion interesan. La aliro de homoj rigardantaj interspacojn en individuaj spuroj esperante detekti suspektindan agadon tute ne skalas (precipe kiam ili devas kompreni ĉiujn metadatenojn kodigitajn en malsamaj interspacoj, kiel span ID, RPC-metodonomo, span-daŭro. 'a, ŝtipoj, etikedoj, ktp.).
Alternativoj al traceview
Spurrezultoj estas plej utilaj kiam ili povas esti bildigitaj en maniero kiel kiu disponigas ne-trivialan komprenon pri kio okazas en interligitaj partoj de la sistemo. Ĝis tio okazas, la sencimiga procezo plejparte restas inerta kaj dependas de la kapablo de la uzanto rimarki la ĝustajn korelaciojn, kontroli la ĝustajn partojn de la sistemo aŭ kunmeti la pecojn de la enigmo - kontraste al instrumento, helpante la uzanton formuli tiujn hipotezojn.
Mi ne estas vida dezajnisto aŭ UX-specialisto, sed en la sekva sekcio mi volas kundividi kelkajn ideojn pri kiel ĉi tiuj bildigoj povus aspekti.
Fokuso sur specifaj servoj
En tempo, kiam la industrio solidiĝas ĉirkaŭ ideoj , ŝajnas racie, ke individuaj teamoj devas prioritati certigi, ke iliaj servoj kongruas kun ĉi tiuj celoj. Tio sekvas servo orientita bildigo plej taŭgas por tiaj teamoj.
Spuroj, precipe sen specimenigo, estas trezoro da informoj pri ĉiu komponanto de distribuita sistemo. Ĉi tiuj informoj povas esti provizitaj al ruza procesoro, kiu provizos uzantojn servo orientita trovoj. Ili povas esti identigitaj anticipe - eĉ antaŭ ol la uzanto rigardas la spurojn:
- Diagramoj pri latencia distribuo nur por tre elstaraj petoj (eksteraj petoj);
- Diagramoj de prokrasta distribuo por kazoj kiam servo SLO-celoj ne estas atingitaj;
- La plej "oftaj", "interesaj" kaj "strangaj" etikedoj en demandoj kiuj plej ofte estas ripetitaj;
- Latencia paŭzo por kazoj kie Rimarkoj servoj ne atingas siajn SLO-celojn;
- Latencia paŭzo por diversaj kontraŭfluaj servoj.
Kelkaj el ĉi tiuj demandoj simple ne estas responditaj per enkonstruitaj metrikoj, devigante uzantojn ekzameni interspacojn. Kiel rezulto, ni havas ekstreme uzanto-malamikan mekanismon.
Ĉi tio levas la demandon: kio pri kompleksaj interagoj inter diversaj servoj kontrolitaj de malsamaj teamoj? Ĉu ne? spurvido ĉu ne estas konsiderata la plej taŭga ilo por reliefigi tian situacion?
Poŝtelefonaj programistoj, posedantoj de sennaciaj servoj, posedantoj de administritaj ŝtataj servoj (kiel datumbazoj) kaj platformaj posedantoj eble interesiĝas pri io alia prezento distribuita sistemo; spurvido estas tro ĝenerala solvo por ĉi tiuj esence malsamaj bezonoj. Eĉ en tre kompleksa mikroserva arkitekturo, servposedantoj ne bezonas profundan scion pri pli ol du aŭ tri kontraŭfluaj kaj kontraŭfluaj servoj. Esence, en la plej multaj scenaroj, uzantoj nur bezonas respondi demandojn pri limigita aro de servoj.
Estas kiel rigardi malgrandan subaron de servoj tra lupeo por ekzameni ĝin. Ĉi tio permesos al la uzanto demandi pli urĝajn demandojn pri la kompleksaj interagoj inter ĉi tiuj servoj kaj iliaj tujaj dependecoj. Ĉi tio similas al backtrace en la servomondo, kie la inĝeniero scias ke malĝusta, kaj ankaŭ havas iom da kompreno pri kio okazas en ĉirkaŭaj servoj por kompreni kial.
La aliro, kiun mi reklamas, estas la ĝusta malo de la desupra, traceview-bazita aliro, kie la analizo komenciĝas per la tuta spuro kaj poste iom post iom funkcias ĝis individuaj interspacoj. En kontrasto, desupra aliro komenciĝas analizante malgrandan areon proksime al la ebla kaŭzo de la okazaĵo, kaj tiam vastigas la serĉspacon laŭbezone (kun la potencialo alporti aliajn teamojn por analizi pli larĝan gamon da servoj). La dua aliro estas pli taŭga por rapide testado de komencaj hipotezoj. Post kiam konkretaj rezultoj estos akiritaj, eblos pluiri al pli fokusita kaj detala analizo.
Konstruante topologion
Servospecifaj vidoj povas esti nekredeble utilaj se la uzanto scias kiu servo aŭ grupo de servoj respondecas pri pliigo de latenteco aŭ kaŭzado de eraroj. Tamen, en kompleksa sistemo, identigi la ofendan servon povas esti ne-triviala tasko dum fiasko, precipe se neniuj erarmesaĝoj estis raportitaj de la servoj.
Konstrui servan topologion povas esti granda helpo por eltrovi, kiu servo spertas pikon en eraraj indicoj aŭ pliiĝon en latenteco, kiu igas la servon rimarkeble degradi. Kiam mi parolas pri konstruado de topologio, mi ne volas diri mapo de servoj, montrante ĉiun servon havebla en la sistemo kaj konata pro ĝia . Ĉi tiu vido ne estas pli bona ol spurvido bazita sur direktita acikla grafeo. Anstataŭe mi ŝatus vidi dinamike generita serva topologio, surbaze de certaj atributoj kiel erarfrekvenco, respondtempo, aŭ iu ajn uzant-difinita parametro kiu helpas klarigi la situacion kun specifaj suspektindaj servoj.
Ni prenu ekzemplon. Ni imagu hipotezan novaĵejon. Hejmpaĝa servo ( frontpaĝo ) interŝanĝas datumojn kun Redis, kun rekomendservo, kun reklamservo kaj videoservo. La videoservo prenas filmetojn de S3 kaj metadatenojn de DynamoDB. La rekomendservo ricevas metadatenojn de DynamoDB, ŝarĝas datumojn de Redis kaj MySQL, kaj skribas mesaĝojn al Kafka. La reklamservo ricevas datumojn de MySQL kaj skribas mesaĝojn al Kafka.
Malsupre estas skema reprezentado de ĉi tiu topologio (multaj komercaj vojprogramoj konstruas la topologion). Ĝi povas esti utila se vi bezonas kompreni servajn dependecojn. Tamen, dum elpurigi, kiam certa servo (diru, videoservo) elmontras pliigitan respondtempon, tia topologio ne estas tre utila.
Servodiagramo de hipoteza novaĵejo
La ĉi-suba diagramo estus pli taŭga. Estas problemo kun la servo (video) bildigita ĝuste en la centro. La uzanto tuj rimarkas ĝin. De ĉi tiu bildigo, evidentiĝas, ke la videoservo funkcias nenormale pro pliiĝo de la responda tempo de S3, kiu influas la ŝarĝan rapidon de parto de la ĉefa paĝo.
Dinamika topologio montranta nur "interesajn" servojn
Dinamike generitaj topologioj povas esti pli efikaj ol senmovaj servmapoj, precipe en elastaj, aŭto-skalaj infrastrukturoj. La kapablo kompari kaj kontrasti servtopologiojn permesas al la uzanto demandi pli signifajn demandojn. Pli precizaj demandoj pri la sistemo pli verŝajne kondukos al pli bona kompreno pri kiel la sistemo funkcias.
Kompara ekrano
Alia utila bildigo estus kompara ekrano. Nuntempe spuroj ne tre taŭgas por flank-al-flankaj komparoj, do komparoj kutime estas etendiĝas. Kaj la ĉefa ideo de ĉi tiu artikolo estas ĝuste, ke interspacoj estas tro malaltaj por ĉerpi la plej valorajn informojn el la spurrezultoj.
Kompari du spurojn ne postulas fundamente novajn bildigojn. Fakte, io kiel histogramo reprezentanta la saman informon kiel spurvido sufiĉas. Mirinde, eĉ ĉi tiu simpla metodo povas alporti multe pli da fruktoj ol simple studi du spurojn aparte. Eĉ pli potenca estus la ebleco bildigi komparo de spuroj Entute. Estus ege utile vidi kiel lastatempe deplojita datumbaza agorda ŝanĝo por ebligi GC (rubaĵkolekto) influas la respondtempon de kontraŭflua servo je skalo de pluraj horoj. Se tio, kion mi priskribas ĉi tie, sonas kiel A/B-analizo de la efiko de infrastrukturaj ŝanĝoj en multaj servoj uzante la spurrezultojn, tiam vi ne estas tro malproksime de la vero.
konkludo
Mi ne pridubas la utilecon de la spuro mem. Mi sincere kredas, ke ne ekzistas alia metodo por kolekti datumojn tiel riĉajn, kaŭzajn kaj kuntekstan kiel tiu enhavita en spuro. Tamen mi ankaŭ kredas, ke ĉiuj spuraj solvoj uzas ĉi tiujn datumojn ege malefike. Dum spuraj iloj restos blokitaj sur la traceview-reprezento, ili estos limigitaj en sia kapablo utiligi la valorajn informojn, kiuj povas esti ĉerpitaj el la datumoj enhavitaj en la spuroj. Krome, ekzistas risko plue evoluigi tute malafablan kaj neintuician vidan interfacon, kiu severe limigos la kapablon de la uzanto solvi erarojn en la aplikaĵo.
Sencimigi kompleksajn sistemojn, eĉ per la plej novaj iloj, estas nekredeble malfacila. Iloj devas helpi la programiston formuli kaj testi hipotezon, aktive provizante rilataj informoj, identigante eksteraĵojn kaj notante trajtojn en la distribuado de prokrastoj. Por ke spurado iĝu la elektebla ilo por programistoj kiam solvi problemojn pri produktado aŭ solvanta problemojn, kiuj ampleksas plurajn servojn, necesas originalaj uzantinterfacoj kaj bildigoj, kiuj pli kongruas kun la mensa modelo de la programistoj, kiuj kreas kaj funkciigas tiujn servojn.
Necesos grava mensa penado por desegni sistemon, kiu reprezentos la diversajn signalojn disponeblajn en la spurrezultoj en maniero optimumigita por facileco de analizo kaj inferenco. Vi devas pensi pri kiel abstrakti la sisteman topologion dum senararigado en maniero kiel kiu helpas la uzanton venki blindajn punktojn sen rigardi individuajn spurojn aŭ interspacojn.
Ni bezonas bonajn abstraktadon kaj tavoligkapablojn (precipe en la UI). Tiuj, kiuj bone konvenus en hipotez-movitan sencimigan procezon, kie vi povas ripete demandi kaj testi hipotezojn. Ili ne aŭtomate solvos ĉiujn observeblajn problemojn, sed ili helpos uzantojn akrigi sian intuicion kaj formuli pli inteligentajn demandojn. Mi postulas pli pripenseman kaj novigan aliron al bildigo. Estas vera perspektivo ĉi tie vastigi horizontojn.
PS de tradukisto
Legu ankaŭ en nia blogo:
- «»;
- «»;
- «".
fonto: www.habr.com