Ohar. itzul.: Material honen egilea Cindy Sridharan da, imgixeko ingeniaria, API garapenean eta, bereziki, mikrozerbitzuen probetan aditua. Material honetan, trazadura banatuaren alorrean gaur egungo arazoei buruzko ikuspegi zehatza partekatzen du, non, bere ustez, larri diren arazoak konpontzeko tresna benetan eraginkorrak falta diren.
[Hortik hartutako ilustrazioa Banatutako trazadurari buruz.]
Da, uste gauzatzea zaila, eta horren bueltan . Arrazoi asko daude trazatzea problematikoa izateko, sarritan sistemaren osagai bakoitza konfiguratzeko esku hartzen duen lana aipatuz eskaera bakoitzarekin goiburu egokiak transmititzeko. Arazo hau existitzen bada ere, ez da inola ere gaindiezina. Bide batez, ez du azaltzen garatzaileei zergatik ez zaien asko gustatzen trazatzea (dagoeneko funtzionatzen ari denean ere).
Banatutako trazamenduaren erronka nagusia ez da datuak biltzea, emaitzak banatzeko eta aurkezteko formatuak estandarizatzea edo laginketa noiz, non eta nola egin zehaztea. Ez naiz imajinatzen saiatzen hutsala "ulergarritasun-arazo" hauek, izan ere, nahiko tekniko eta esanguratsuak dira (benetan Open Source kontuan hartzen badugu) ) gainditu beharreko erronka politikoak, arazo horiek konpondutzat jo daitezen.
Dena den, arazo hauek guztiak konponduta daudela imajinatzen badugu, probabilitate handia dago ezer nabarmen ez aldatzeko. azken erabiltzailearen esperientzia. Baliteke arazketa oraindik erabilgarri ez izatea arazketa-eszenatoki ohikoenetan, nahiz eta zabaldu ondoren.
Hain arrasto ezberdina
Banatutako trazadurak hainbat osagai ditu:
- aplikazioak eta middlewarea kontrol-tresnekin hornitzea;
- testuinguru banatua transferitzea;
- arrastoen bilketa;
- aztarnak biltegiratzea;
- haien erauzketa eta bistaratzea.
Banatutako trazatzeari buruz asko hitz egiten da sistema guztiz diagnostikatzen laguntzea helburu bakarra duen eragiketa ez-bateko moduko bat bezala tratatzeko. Hori, neurri handi batean, trazadura banatuari buruzko ideiak historikoki eratu direnaren ondorioz gertatzen da. IN , Zipkin iturriak ireki zirenean egina, hori aipatu zen horrek [Zipkin] Twitter azkarrago egiten du. Trazatzeko lehen eskaintza komertzialak ere sustatu ziren .
Ohar. itzul.: Testu gehiago ulertzeko errazagoa izan dadin, defini ditzagun oinarrizko bi terminoren arabera :
- span β Trazadura banatuaren oinarrizko elementua. Lan-fluxu jakin baten deskribapena da (adibidez, datu-basearen kontsulta bat) izena, hasiera eta amaiera orduak, etiketak, erregistroak eta testuingurua dituena.
- Tarteek normalean beste tarte batzuetarako estekak izaten dituzte, eta hainbat tarte konbina daitezke Jarraitu β eskaera baten bizitzaren bistaratzea sistema banatu baten bidez mugitzen den heinean.
Aztarnek datu izugarri baliotsuak dituzte, hala nola ekoizpen-probak, hondamendiak berreskuratzeko probak, akatsak injekzio-probak, etab. Izan ere, enpresa batzuek dagoeneko erabiltzen dute traza antzeko helburuetarako. Has gaitezen beste erabilera batzuk ditu biltegiratze sistemara tarteak mugitzeaz gain:
- Adibidez, Uber emaitzak trazatzea proba-trafikoa eta ekoizpen-trafikoa bereizteko.
- Facebook hondamendiak berreskuratzeko ohiko probetan bide kritikoen azterketarako eta trafikoa aldatzeko aztarna-datuak.
- Baita sare soziala ere Garatzaileei arrastoen emaitzetan kontsulta arbitrarioak egiteko aukera ematen duten Jupyter koadernoak.
- Jarraitzaileak (Leinuak bultzatutako hutsegite injekzioa) errore-injekzioarekin probak egiteko aztarnak banatuak.
Goian zerrendatutako aukeretako bat ere ez dago guztiz agertokiari arazketa, eta horretan ingeniaria arrastoari begiratuz arazoa konpontzen saiatzen da.
Etortzen denean oraindik arazketa-scriptera iristen da, interfaze nagusia diagrama izaten jarraitzen du arrastoa (batzuek ere esaten dioten arren "Gantt diagrama" edo "ur-jauziaren diagrama"). Azpian arrastoa Ρ elkarrekin arrastoa osatzen duten tarte eta metadatu osagarri guztiak. Kode irekiko trazatze-sistema guztiek, baita merkataritzako trazatze-soluzio guztiek ere, a arrastoa erabiltzailearen interfazea arrastoak ikusteko, xehetasunez eta iragazteko.
Orain arte ikusi ditudan trazatze-sistema guztien arazoa hori da bistaratzea (traceview) ia erabat islatzen ditu arrastoak sortzeko prozesuaren ezaugarriak. Bistaratze alternatiboak proposatzen direnean ere: bero-mapak, zerbitzu-topologiak, latentzia-histogramak, oraindik ere arrastoa.
Iraganean I UI/UX trazaketaren "berrikuntza" gehienak mugatuta daudela dirudi metadatu gehigarriak arrastoan, kardinaltasun handiko informazioa inbertituz (kardinaltasun handiko) edo tarte zehatzetan sakontzeko edo kontsultak egiteko gaitasuna ematea traza arteko eta barneko... Non arrastoa bisualizazio tresna nagusia izaten jarraitzen du. Egoera honek jarraitzen duen bitartean, banatutako trazatzeak (onenean) 4. postua hartuko du arazketa-tresna gisa, neurgailuen, erregistroen eta pilaren arrastoen ondoren, eta txarrenean dirua eta denbora galtzea izango da.
Traceview-ekin arazoa
patu arrastoa β Eskaera bakar baten mugimenduaren irudi osoa ematea erlazionatuta dagoen sistema banatuko osagai guztietan. Trazamendu sistema aurreratuago batzuek tarte indibidualetan sakondu eta denboran zehar matxura bat ikusteko aukera ematen dute barruan prozesu bat (tarteek muga funtzionalak dituztenean).
Mikrozerbitzuen arkitekturaren oinarrizko premisa antolakuntza-egitura enpresaren beharrekin batera hazten den ideia da. Mikrozerbitzuen aldekoek diotenez, negozio-zeregin desberdinak banakako zerbitzuetan banatzeak garapen-talde txiki eta autonomoei zerbitzu horien bizi-ziklo osoa kontrolatzeko aukera ematen die, zerbitzu horiek modu independentean eraiki, probatu eta zabaltzeko gaitasuna emanez. Dena den, banaketa honen desabantaila zerbitzu bakoitzak besteekin nola elkarreragiten duen informazioa galtzea da. Baldintza horietan, trazadura banatua ezinbesteko tresna dela aldarrikatzen du arazketa zerbitzuen arteko elkarrekintza konplexuak.
Benetan bada , orduan pertsona bakar bat ere ez da gai bere buruan gordetzeko osatu irudia. Izan ere, posible dela ustean oinarritutako tresna bat garatzea ereduaren aurkako zerbait da (ikuspegi eraginkorra eta ez-produktiboa). Egokiena, arazketak laguntzen duen tresna bat behar du murriztu bilaketa-eremua, ingeniariek kontuan hartzen den arazo-egoerari dagozkion dimentsioen azpimultzo batean (zerbitzuak/erabiltzaileak/ostalariak, etab.) bideratu ahal izateko. Hutsegite baten kausa zehazten denean, ingeniariek ez dute zertan gertatu den ulertzea beharrezkoa zerbitzu guztiak aldi berean, baldintza hori mikrozerbitzuen arkitekturaren ideia bera kontraesanean egongo litzatekeelako.
Hala ere, traceview da hots, Hau. Bai, trazatze-sistema batzuek arrasto-ikuspegi konprimituak eskaintzen dituzte arrastoaren tarte-kopurua hain handia denean, ezin diren bistaratze batean bistaratu. Hala ere, bistaratze txiki batean ere jasotako informazio kopuru handia dela eta, ingeniariek oraindik ere behartuta "Bahetu", aukeraketa eskuz murriztuz arazo iturri diren zerbitzu multzo batera. Zoritxarrez, arlo honetan, makinak gizakiak baino askoz azkarragoak dira, akatsak izateko joera gutxiago dute eta haien emaitzak errepikatuagoak dira.
Traceview oker dagoela uste dudan beste arrazoi bat hipotesiek gidatutako arazketarako ona ez delako da. Bere oinarrian, arazketa da errepikakorra Hipotesi batekin hasten den prozesu bat, sistematik bektore ezberdinen bidez lortutako hainbat behaketa eta gertakari egiaztatzen ondoren, ondorioak/orokortzeak eta hipotesiaren egiaren ebaluazio gehiago.
Aukera azkarra eta merkea hipotesiak probatzea eta horren arabera eredu mentala hobetzea da oinarri-harria arazketa Edozein arazketa tresna izan beharko luke interaktiboa eta bilaketa-espazioa murriztu edo, bide faltsu baten kasuan, erabiltzaileari atzera egin eta sistemaren beste eremu batean zentratu ahal izateko. Tresna ezin hobea izango da modu proaktiboan, erabiltzailearen arreta berehala erakarri litezkeen arazo-eremuetara.
Ai, arrastoa ezin da interfaze interaktiboa duen tresna deitu. Erabiltzean espero dezakezun onena latentzia handitzeko iturriren bat aurkitzea eta harekin lotutako etiketa eta erregistro posible guztiak aztertzea da. Horrek ez dio laguntzen ingeniariari identifikatzen ereduak trafikoan, hala nola, atzerapen banaketaren berezitasunak, edo neurketa ezberdinen arteko korrelazioak detektatu. arazo horietako batzuk konpontzen lagun dezake. Benetan, analisi arrakastatsua ikaskuntza automatikoa erabiliz tarte anomaliak identifikatzeko eta portaera anormalarekin lotu daitezkeen etiketen azpimultzo bat identifikatzeko. Hala ere, oraindik ez dut ikusi makina-ikaskuntzaren edo datu-meatzaritzaren aurkikuntzen bistaratze erakargarriak traceview edo DAG (zuzendutako grafiko azikliko) batetik nabarmen desberdinak diren tarteetan aplikatuta.
Tarteak maila baxuegia dira
Traceview-en oinarrizko arazoa hori da tarteak maila baxuegiko primitiboak dira bai latentzia-analisirako, bai erro-kausen azterketarako. Salbuespen bat konpontzen saiatzeko prozesadorearen komando indibidualak analizatzea bezalakoa da, jakinda badirela askoz ere maila altuko erremintak lan egiteko erosoagoak direnak.
Gainera, honako hau aldarrikatzeko askatasuna hartuko dut: ideala, ez dugu behar argazki osoa eskaeraren bizi-zikloan gertatu da, zeina trazatzeko tresna modernoek adierazten duten. Horren ordez, zeri buruzko informazioa duen goi-mailako abstrakzio moduren bat behar da gaizki joan zen (backtrace-ren antzekoa), testuinguru batzuekin batera. Aztarna osoa ikusi beharrean, nahiago dut ikusi ΡΠ°ΡΡΡ, non zerbait interesgarria edo ezohikoa gertatzen den. Gaur egun, bilaketa eskuz egiten da: ingeniariak arrastoa jasotzen du eta modu independentean aztertzen ditu tarteak zerbait interesgarriaren bila. Jarduera susmagarriak detektatzeko asmoz aztarna indibidualetan tarteei begira dauden pertsonen planteamendua ez da batere eskalatzen (batez ere tarte ezberdinetan kodetutako metadatu guztiei zentzua eman behar dietenean, hala nola tartearen IDa, RPC metodoaren izena, tartearen iraupena). 'a, erregistroak, etiketak, etab.).
Traceview-en alternatibak
Aztarna-emaitzak erabilgarrienak dira sistemaren ataletan gertatzen denari buruzko ikuspegi ez hutsala eskaintzen dutenean ikus daitezkeenean. Hau gertatu arte, arazketa-prozesuak bere horretan jarraitzen du geldoa eta erabiltzaileak korrelazio egokiak antzemateko, sistemaren zati egokiak egiaztatzeko edo puzzlearen piezak elkarrekin jartzeko duen gaitasunaren araberakoa da, ez bezala. tresna, erabiltzaileari hipotesi hauek formulatzen lagunduz.
Ez naiz diseinatzaile bisuala edo UX espezialista, baina hurrengo atalean ideia batzuk partekatu nahi ditut bistaratze hauek nolakoak izan daitezkeen.
Zerbitzu zehatzetan zentratu
Industria ideien inguruan sendotzen ari den garaian , arrazoizkoa dirudi talde indibidualek beren zerbitzuak helburu horiekin bat egiten dutela ziurtatzea lehenetsi behar izatea. Hortik dator zerbitzura zuzenduta bistaratzea da egokiena horrelako taldeentzat.
Aztarnak, batez ere laginketarik gabe, sistema banatu baten osagai bakoitzari buruzko informazio-altxor bat dira. Informazio hori erabiltzaileak hornituko dituen prozesadore maltzur bati eman diezaioke zerbitzura zuzenduta aurkikuntzak. Aldez aurretik identifikatu daitezke, erabiltzaileak aztarnak begiratu aurretik ere:
- Latentzia-banaketaren diagramak eskaera oso nabarmenetarako soilik (eskaerak kanpokoak);
- Atzerapen banaketaren diagramak zerbitzuaren SLO helburuak lortzen ez diren kasuetarako;
- Etiketa "ohiko", "interesgarri" eta "arraro" gehien egiten diren kontsultetan errepikatzen dira;
- Latentziaren matxura kasuetarako arabera zerbitzuek ez dituzte beren SLO helburuak lortzen;
- Beheko hainbat zerbitzuren latentzia-matxura.
Galdera hauetako batzuk ez dira integratutako metrikek erantzuten, erabiltzaileak tarteak aztertzera behartuz. Ondorioz, erabiltzaileen aurkako mekanismoa dugu.
Honek galdera planteatzen du: zer gertatzen da talde ezberdinek kontrolatutako hainbat zerbitzuren arteko interakzio konplexuekin? Ez al da arrastoa ez al da horrelako egoera nabarmentzeko tresnarik egokiena kontsideratzen?
Garatzaile mugikorrek, estaturik gabeko zerbitzuen jabeek, kudeatutako egoera zerbitzuen jabeek (adibidez, datu-baseak) eta plataformaren jabeek beste zerbaitetan interesa izan dezakete. aurkezpena sistema banatua; arrastoa oinarrizko beharrizan desberdin horietarako irtenbide generikoegia da. Nahiz eta mikrozerbitzuen arkitektura oso konplexuan, zerbitzuen jabeek ez dute behar bizpahiru zerbitzu baino gehiagoren ezagutza sakonik. Funtsean, agertoki gehienetan, erabiltzaileek horri buruzko galderak baino ez dituzte erantzun behar zerbitzu multzo mugatua.
Zerbitzuen azpimultzo txiki bat lupaz begiratzea bezalakoa da hura aztertzeko. Horri esker, erabiltzaileak galdera larriagoak egin ahal izango ditu zerbitzu horien arteko interakzio konplexuei eta haien berehalako mendekotasunei buruz. Hau zerbitzuen munduan backtrace-ren antzekoa da, non ingeniariak badaki duten oker, eta inguruko zerbitzuetan gertatzen ari dena ulertzen du zergatik.
Sustatzen ari naizen ikuspegia goitik beherako, traceview-en oinarritutako ikuspegiaren guztiz kontrakoa da, non analisia arrasto osoarekin hasten den eta, gero, pixkanaka-pixkanaka banakako tarteetara joaten den. Aitzitik, behetik gorako hurbilketa bat gertakariaren balizko kausatik hurbil dagoen eremu txiki bat aztertzen hasten da, eta, ondoren, bilaketa-espazioa zabaltzen du behar den moduan (beste talde batzuk ekartzeko aukerarekin, zerbitzu sorta zabalagoa aztertzeko). Bigarren ikuspegia hobe da hasierako hipotesiak azkar probatzeko. Emaitza zehatzak lortu ondoren, azterketa zehatzago eta zehatzago batera pasa ahal izango da.
Topologia bat eraikitzea
Zerbitzuaren ikuspegi espezifikoak oso erabilgarriak izan daitezke erabiltzaileak badaki bertan zerbitzu edo zerbitzu talde bat latentzia areagotzeaz edo akatsak sortzeaz arduratzen da. Hala ere, sistema konplexu batean, zerbitzu iraingarria identifikatzea lan hutsala izan daiteke hutsegite batean, batez ere zerbitzuetatik errore-mezurik jakinarazi ez bada.
Zerbitzu-topologia bat eraikitzea lagungarri izan daiteke zein zerbitzuk jasaten duen errore-tasen gorakada edo zerbitzua nabarmen degradatzen ari den latentzia handitzea. Topologia bat eraikitzeaz hitz egiten dudanean, ez dut esan nahi zerbitzuen mapa, sisteman eskuragarri dauden eta beregatik ezagunak diren zerbitzu guztiak erakutsiz . Ikuspegi hau ez da grafiko azikliko zuzendu batean oinarritutako traza-ikuspegia baino hobea. Horren ordez ikusi nahiko nuke dinamikoki sortutako zerbitzu topologia, zenbait atribututan oinarrituta, hala nola errore-tasa, erantzun-denbora edo erabiltzaileak definitutako edozein parametro, zerbitzu susmagarri zehatzekin egoera argitzen laguntzen duena.
Har dezagun adibide bat. Imajina dezagun albiste gune hipotetiko bat. Hasierako orriaren zerbitzua (lehen orrialdea) Redis-ekin datuak trukatzen ditu, gomendio zerbitzu batekin, publizitate zerbitzu batekin eta bideo zerbitzu batekin. Bideo-zerbitzuak S3-ko bideoak eta DynamoDB-ko metadatuak hartzen ditu. Gomendio-zerbitzuak DynamoDB-ren metadatuak jasotzen ditu, Redis eta MySQL-en datuak kargatzen ditu eta mezuak idazten ditu Kafkan. Publizitate zerbitzuak MySQL-ren datuak jasotzen ditu eta mezuak idazten dizkio Kafkari.
Jarraian topologia honen irudikapen eskematiko bat dago (bideratze-programa komertzialek eraikitzen dute topologia). Baliagarria izan daiteke zerbitzuen mendekotasunak ulertu behar badituzu. Hala ere, bitartean arazketa, zerbitzu jakin batek (demagun, bideo-zerbitzu batek) erantzun-denbora handiagoa erakusten duenean, topologia hori ez da oso erabilgarria.
Albiste gune hipotetiko baten zerbitzu-diagrama
Beheko diagrama hobeto legoke. Arazo bat dago zerbitzuarekin (Bideoa) erdian bertan irudikatuta. Erabiltzaileak berehala nabaritzen du. Ikuspegi honetatik, argi geratzen da bideo-zerbitzuak modu anormalean funtzionatzen duela S3 erantzun-denbora handitu delako, eta horrek orrialde nagusiaren zati baten karga-abiadurari eragiten dio.
Topologia dinamikoa zerbitzu "interesgarriak" soilik erakusten ditu
Dinamikoki sortutako topologiak zerbitzu-mapa estatikoak baino eraginkorragoak izan daitezke, batez ere eskalatze automatikoko azpiegitura elastikoetan. Zerbitzu-topologiak alderatu eta kontrastatu ahal izateko aukera ematen dio erabiltzaileari galdera garrantzitsuagoak egiteko. Sistemari buruzko galdera zehatzagoak litekeena da sistemaren funtzionamendua hobeto ulertzeko.
Bistaratzeko konparazioa
Beste bistaratze erabilgarri bat pantaila konparatiboa izango litzateke. Gaur egun aztarnak ez dira oso egokiak elkarren ondoan konparaketak egiteko, beraz, konparaketak izan ohi dira tarteak. Eta artikulu honen ideia nagusia da, hain zuzen, tarteak maila baxuegia direla arrastoen emaitzetatik informaziorik baliotsuena ateratzeko.
Bi aztarna alderatzeak ez du behar funtsean bistaratze berririk. Izan ere, nahikoa da traza-ikuskera baten informazio bera adierazten duen histograma antzeko zerbait. Harrigarria bada ere, metodo sinple honek ere fruitu gehiago ekar dezake bi aztarna bereizita aztertzea baino. Are indartsuagoa izango litzateke aukera ikusarazi arrastoen konparaketa Guztira. Oso erabilgarria izango litzateke ikustea duela gutxi zabaldutako datu-basearen konfigurazio-aldaketak GC (zabor bilketa) gaitzeko nola eragiten duen beherako zerbitzu baten erantzun-denboran hainbat orduko eskalan. Hemen deskribatzen dudana azpiegituren aldaketen eraginaren A/B azterketa bat dirudi zerbitzu askotan arrastoaren emaitzak erabiliz, orduan ez zaude egiatik urrunegi.
Ondorioa
Ez dut zalantzan jartzen trazatuaren beraren erabilgarritasuna. Zintzoki uste dut ez dagoela arrasto batean jasotako datuak bezain aberats, kausal eta testuinguruko beste metodorik. Hala ere, uste dut trazamendu-soluzio guztiek datu hauek oso modu eraginkorrean erabiltzen dituztela. Trazatze-tresnak traza-ikuspegiaren irudikapenean itsatsita jarraitzen duten bitartean, aztarnetan jasotako datuetatik atera daitekeen informazio baliotsuari etekinik handiena ateratzeko gaitasuna mugatua izango da. Horrez gain, erabiltzaileak aplikazioan akatsak konpontzeko gaitasuna larriki mugatuko duen bisual interfaze guztiz desegokia eta intuitiboa gehiago garatzeko arriskua dago.
Sistema konplexuak araztea, nahiz eta azken tresnak erabili, izugarri zaila da. Tresnek garatzaileari hipotesi bat formulatzen eta probatzen lagundu behar diote, aktiboki ematen informazio garrantzitsua, kanpo-egoerak identifikatuz eta atzerapenen banaketan ezaugarriak adieraziz. Ekoizpen-hutsegiteak konpontzerakoan edo hainbat zerbitzu hartzen dituzten arazoak konpontzerakoan garatzaileen traza aukera tresna bihur dadin, zerbitzu horiek sortzen eta kudeatzen dituzten garatzaileen eredu mentalarekin koherenteagoak diren jatorrizko erabiltzaile-interfazeak eta bistaratzeak behar dira.
Esfortzu mental handia beharko da arrastoaren emaitzetan eskuragarri dauden seinale desberdinak irudikatuko dituen sistema bat diseinatzeko, analisia eta inferentzia errazteko modu optimizatuan. Arazketan zehar sistemaren topologia nola abstraitu pentsatu behar duzu erabiltzaileari puntu itsuak gainditzen lagunduko dion aztarna edo tarte indibidualei begiratu gabe.
Abstrakzio eta geruzak egiteko gaitasun onak behar ditugu (bereziki UI-n). Hipotesiek gidatutako arazketa-prozesu batean ondo moldatuko liratekeenak, non iteratiboki galderak egin eta hipotesiak probatu ditzakezun. Ez dituzte automatikoki konponduko behagarritasun-arazo guztiak, baina erabiltzaileei intuizioa zorrozten eta galdera adimentsuak formulatzen lagunduko diete. Ikuspegiaren ikuspegi hausnartuagoa eta berritzaileagoa eskatzen dut. Benetako aukera bat dago hemen horizonteak zabaltzeko.
PS itzultzailetik
Irakurri ere gure blogean:
- «»;
- «»;
- Β«'.
Iturria: www.habr.com