Pastaba. vert.: Šios medžiagos autorė yra Cindy Sridharan, imgix inžinierė, kuri specializuojasi API kūrime ir ypač mikro paslaugų testavime. Šioje medžiagoje ji dalijasi savo išsamia vizija apie dabartines problemas paskirstytojo sekimo srityje, kur, jos nuomone, trūksta tikrai veiksmingų priemonių aktualioms problemoms spręsti.
[Iliustracija paimta iš apie paskirstytą sekimą.]
Manoma, kad sunku įgyvendinti, ir grąža . Yra daug priežasčių, kodėl sekimas yra problemiškas, dažnai nurodant darbą, susijusį su kiekvieno sistemos komponento konfigūravimu, kad būtų perduodamos atitinkamos antraštės su kiekviena užklausa. Nors ši problema egzistuoja, ji jokiu būdu nėra neįveikiama. Beje, tai nepaaiškina, kodėl kūrėjams nelabai patinka sekimas (net kai jis jau veikia).
Pagrindinis iššūkis, susijęs su paskirstytu sekimu, yra ne duomenų rinkimas, rezultatų paskirstymo ir pateikimo formatų standartizavimas arba duomenų, kada, kur ir kaip imti mėginius, nustatymas. Aš nesistengiu įsivaizduoti trivialus šios „suprantamumo problemos“ iš tikrųjų yra gana reikšmingos techninės ir (jei svarstysime tikrai atvirą kodą) ) politiniai iššūkiai, kuriuos reikia įveikti, kad šios problemos būtų laikomos išspręstomis.
Tačiau jei įsivaizduosime, kad visos šios problemos bus išspręstos, didelė tikimybė, kad niekas iš esmės nepasikeis. galutinio vartotojo patirtis. Sekimas vis tiek gali būti nepraktiškas pagal dažniausiai pasitaikančius derinimo scenarijus – net ir įdiegus.
Toks kitoks pėdsakas
Paskirstytas sekimas apima kelis skirtingus komponentus:
- taikomųjų programų ir tarpinės programinės įrangos aprūpinimas valdymo įrankiais;
- paskirstytas konteksto perdavimas;
- pėdsakų rinkimas;
- pėdsakų saugojimas;
- jų ištraukimas ir vizualizavimas.
Daug kalbų apie paskirstytą sekimą linksta tai traktuoti kaip savotišką vieningą operaciją, kurios vienintelis tikslas yra padėti visapusiškai diagnozuoti sistemą. Taip yra daugiausia dėl to, kaip istoriškai susiformavo idėjos apie paskirstytą sekimą. IN , padaryta atidarius Zipkin šaltinius, buvo paminėta, kad tai [Zipkin] daro Twitter greitesnį. Pirmieji komerciniai pasiūlymai sekimui taip pat buvo reklamuojami kaip .
Pastaba. vert.: Kad tolesnis tekstas būtų lengviau suprantamas, apibrėžkime du pagrindinius terminus pagal :
- trukmė — pagrindinis paskirstytojo sekimo elementas. Tai tam tikros darbo eigos (pavyzdžiui, duomenų bazės užklausos) aprašymas su pavadinimu, pradžios ir pabaigos laiku, žymomis, žurnalais ir kontekstu.
- Tarpai paprastai apima nuorodas į kitus intervalus, leidžiančius sujungti kelis intervalus Sekti — užklausos gyvavimo vizualizacija, kai ji juda paskirstytoje sistemoje.
Pėdsakai turi neįtikėtinai vertingų duomenų, kurie gali padėti atliekant tokias užduotis kaip gamybos bandymai, atkūrimo bandymai po nelaimės, klaidų injekcijos bandymai ir kt. Tiesą sakant, kai kurios įmonės jau naudoja sekimą panašiais tikslais. Pradėkime nuo gali būti naudojamas ir kitoms reikmėms, išskyrus tiesiog perkeliant tarpus į saugojimo sistemą:
- Pavyzdžiui, Uber sekti rezultatus, kad būtų galima atskirti bandomąjį srautą ir gamybos srautą.
- Facebook sekti duomenis kritinio kelio analizei ir eismo perjungimui atliekant reguliarius atkūrimo testus po nelaimių.
- Taip pat socialinis tinklas „Jupyter“ nešiojamieji kompiuteriai, leidžiantys kūrėjams vykdyti savavališkas sekimo rezultatų užklausas.
- Sekėjai (Lineage Driven Failure Injection) išdalino pėdsakus testavimui su klaidų įvedimu.
Nė viena iš aukščiau išvardytų parinkčių netaikoma šiam scenarijui derinimas, kurio metu inžinierius bando išspręsti problemą žiūrėdamas į pėdsaką.
Kai tai ateina dar pasiekia derinimo scenarijų, pagrindinė sąsaja išlieka diagrama traceview (nors kai kurie taip pat vadina "Ganto diagramos" arba "krioklio diagrama"). Pagal traceview я visi ilgiai ir pridedami metaduomenys, kurie kartu sudaro pėdsaką. Kiekviena atvirojo kodo sekimo sistema, taip pat kiekvienas komercinis sekimo sprendimas siūlo a traceview vartotojo sąsaja, skirta vizualizuoti, detalizuoti ir filtruoti pėdsakus.
Visų iki šiol matytų sekimo sistemų problema yra ta, kad rezultatas vizualizacija (traceview) beveik visiškai atspindi pėdsakų generavimo proceso ypatybes. Net kai siūlomos alternatyvios vizualizacijos: šilumos žemėlapiai, paslaugų topologijos, delsos histogramos, jos vis tiek galiausiai yra traceview.
Praeityje I atrodo, kad dauguma UI/UX sekimo „naujovių“ apsiriboja papildomų metaduomenų sekimo, investuojant į juos didelio kardinalumo informaciją (didelis kardinalumas) arba suteikiant galimybę įsigilinti į konkrečias sritis arba vykdyti užklausas tarpinis ir vidinis pėdsakas... Kur traceview išlieka pagrindine vizualizavimo priemone. Kol tokia padėtis tęsis, paskirstytasis sekimas (geriausiu atveju) užims 4 vietą kaip derinimo įrankis po metrikų, žurnalų ir krūvos pėdsakų, o blogiausiu atveju tai bus pinigų ir laiko švaistymas.
Problema su traceview
Tikslas traceview — pateikti išsamų vaizdą apie vienos užklausos judėjimą visuose paskirstytos sistemos komponentuose, su kuriais ji yra susijusi. Kai kurios pažangesnės sekimo sistemos leidžia įsigilinti į atskirus intervalus ir peržiūrėti suskirstymą laikui bėgant per vienas procesas (kai tarpatramiai turi funkcines ribas).
Pagrindinė mikropaslaugų architektūros prielaida yra idėja, kad organizacinė struktūra auga kartu su įmonės poreikiais. Mikropaslaugų šalininkai teigia, kad įvairių verslo užduočių paskirstymas į atskiras paslaugas leidžia mažoms, savarankiškoms kūrėjų komandoms kontroliuoti visą tokių paslaugų gyvavimo ciklą, suteikiant galimybę savarankiškai kurti, išbandyti ir diegti tas paslaugas. Tačiau šio paskirstymo trūkumas yra informacijos apie tai, kaip kiekviena paslauga sąveikauja su kitomis, praradimas. Tokiomis sąlygomis išplatintas sekimas yra nepakeičiamas įrankis derinimas sudėtinga paslaugų sąveika.
Jei tikrai , tada ne vienas žmogus nesugeba to išlaikyti savo galvoje pilnas paveikslėlį. Tiesą sakant, įrankio kūrimas remiantis prielaida, kad tai netgi įmanoma, yra kažkas panašaus į modelį (neveiksmingas ir neproduktyvus metodas). Idealiu atveju derinti reikalingas įrankis, kuris padeda susiaurinkite paieškos sritį, kad inžinieriai galėtų sutelkti dėmesį į aspektų poaibį (paslaugos / vartotojai / prieglobos ir kt.), susijusius su svarstomu problemos scenariju. Nustatydami gedimo priežastį, inžinieriai neprivalo suprasti, kas įvyko gedimo metu visas paslaugas vienu metu, nes toks reikalavimas prieštarautų pačiai mikropaslaugų architektūros idėjai.
Tačiau traceview yra būtent Tai. Taip, kai kurios sekimo sistemos siūlo suglaudintus pėdsakų rodinius, kai pėdsakų intervalų skaičius yra toks didelis, kad jų negalima parodyti vienoje vizualizacijoje. Tačiau dėl didelio informacijos kiekio, esančio net tokioje supaprastintoje vizualizacijoje, inžinieriai vis tiek priverstas „atsijoti“ jį, rankiniu būdu susiaurindami pasirinkimą iki paslaugų, kurios yra problemų šaltiniai, rinkinio. Deja, šioje srityje mašinos yra daug greitesnės už žmones, mažiau linkusios į klaidas, o jų rezultatai labiau pakartojami.
Kita priežastis, dėl kurios manau, kad traceview yra neteisinga, yra ta, kad ji nėra tinkama hipotezėmis pagrįstam derinimui. Iš esmės tai yra derinimas pasikartojantis procesas prasidedantis hipoteze, po kurio seka įvairių stebėjimų ir faktų, gautų iš sistemos pagal skirtingus vektorius, patikrinimas, išvados/apibendrinimai ir tolesnis hipotezės teisingumo vertinimas.
Galimybė greitai ir pigiai tikrinti hipotezes ir atitinkamai tobulinti mentalinį modelį kertinis akmuo derinimas Bet koks derinimo įrankis turėtų būti interaktyvus ir susiaurinti paieškos erdvę arba, klaidingo pranešimo atveju, leisti vartotojui grįžti atgal ir sutelkti dėmesį į kitą sistemos sritį. Tobulas įrankis tai padarys aktyviai, nedelsiant atkreipdamas vartotojo dėmesį į galimas problemines sritis.
Deja, traceview negali būti vadinamas įrankiu su interaktyvia sąsaja. Geriausia, ko galite tikėtis naudodami jį, tai surasti didesnį delsos šaltinį ir peržiūrėti visas galimas su juo susijusias žymas ir žurnalus. Tai nepadeda inžinieriui identifikuoti modelius eisme, pvz., delsos pasiskirstymo specifiką, arba aptikti koreliacijas tarp skirtingų matavimų. gali padėti išspręsti kai kurias iš šių problemų. tikrai, sėkminga analizė naudojant mašininį mokymąsi, siekiant nustatyti anomalius intervalus ir nustatyti žymų, kurios gali būti susijusios su anomaliu elgesiu, poaibį. Tačiau dar nemačiau įtikinamų mašininio mokymosi ar duomenų gavybos išvadų vizualizacijų, taikomų intervalams, kurie labai skiriasi nuo traceview arba DAG (nukreiptos aciklinės grafikos).
Tarpai yra per žemi
Pagrindinė „traceview“ problema yra ta apima yra per žemo lygio primityvūs delsos analizei ir pagrindinės priežasties analizei. Tai tarsi atskirų procesoriaus komandų analizavimas, siekiant išspręsti išimtį, žinant, kad yra daug aukštesnio lygio įrankių, pvz., „backtrace“, su kuriais dirbti daug patogiau.
Be to, pasiimu laisvę teigti: idealiu atveju mums to nereikia pilnas vaizdas įvyko per užklausos gyvavimo ciklą, kurį reprezentuoja šiuolaikiniai sekimo įrankiai. Vietoj to reikalinga tam tikra aukštesnio lygio abstrakcijos forma, kurioje būtų informacijos apie tai, ką Nepavyko (panašus į backtrace), kartu su tam tikru kontekstu. Užuot stebėjęs visą pėdsaką, man labiau patinka jį pamatyti часть, kur nutinka kažkas įdomaus ar neįprasto. Šiuo metu paieška atliekama rankiniu būdu: inžinierius gauna pėdsaką ir savarankiškai analizuoja intervalus, ieškodamas ko nors įdomaus. Žmonių požiūris į atskirus pėdsakus žiūri į intervalus, tikėdamasis aptikti įtartiną veiklą (ypač kai jie turi suprasti visus metaduomenis, užkoduotus skirtingose srityse, pvz., intervalo ID, RPC metodo pavadinimą, intervalo trukmę). 'a, žurnalai, žymos ir kt.).
Traceview alternatyvos
Stebėjimo rezultatai yra naudingiausi, kai juos galima vizualizuoti tokiu būdu, kuris suteikia nereikšmingą įžvalgą apie tai, kas vyksta tarpusavyje sujungtose sistemos dalyse. Kol tai neįvyks, derinimo procesas iš esmės išlieka inertiškas ir priklauso nuo vartotojo gebėjimo pastebėti teisingas sąsajas, patikrinti tinkamas sistemos dalis arba sudėti dėlionės dalis – priešingai įrankis, padeda vartotojui suformuluoti šias hipotezes.
Nesu vaizdų dizaineris ar UX specialistas, bet kitame skyriuje noriu pasidalinti keliomis idėjomis, kaip šios vizualizacijos galėtų atrodyti.
Susikoncentruokite į konkrečias paslaugas
Tuo metu, kai pramonė telkiasi aplink idėjas , atrodo pagrįsta, kad atskiros komandos turėtų teikti pirmenybę tam, kad jų paslaugos būtų suderintos su šiais tikslais. Tai seka orientuotas į paslaugą vizualizacija geriausiai tinka tokioms komandoms.
Pėdsakai, ypač be atrankos, yra informacijos apie kiekvieną paskirstytos sistemos komponentą lobis. Šią informaciją galima paduoti gudriam procesoriui, kuris aprūpins vartotojus orientuotas į paslaugą radinius galima nustatyti iš anksto – net prieš vartotojui pažiūrėjus pėdsakus:
- Delsos paskirstymo diagramos tik labai svarbioms užklausoms (išskirtiniai prašymai);
- Vėlavimo pasiskirstymo diagramos tais atvejais, kai paslaugos SLO tikslai nepasiekiami;
- „Dažniausios“, „įdomiausios“ ir „keistos“ žymos užklausose, kurios dažniausiai kartojasi;
- Latencijos suskirstymas tais atvejais, kai priklausomybes paslaugos nepasiekia savo SLO tikslų;
- Įvairių paskesnių paslaugų delsos suskirstymas.
Į kai kuriuos iš šių klausimų tiesiog neatsako integruota metrika, todėl naudotojai verčiami atidžiai išnagrinėti intervalus. Dėl to turime itin priešišką vartotojui mechanizmą.
Tai kelia klausimą: kaip su sudėtinga sąveika tarp įvairių paslaugų, kurias valdo skirtingos komandos? Ar ne taip traceview nelaikoma tinkamiausia priemone tokiai situacijai pabrėžti?
Mobiliųjų telefonų kūrėjai, paslaugų be pilietybės savininkai, valdomų būseną palaikančių paslaugų (pvz., duomenų bazių) savininkai ir platformų savininkai gali būti suinteresuoti dar kuo nors pristatymas paskirstyta sistema; traceview yra pernelyg bendras šių iš esmės skirtingų poreikių sprendimas. Net ir labai sudėtingoje mikropaslaugų architektūroje paslaugų savininkams nereikia gilių žinių apie daugiau nei dvi ar tris aukštesnės ir paskesnes paslaugas. Iš esmės daugeliu atvejų naudotojams tereikia atsakyti į klausimus, susijusius su ribotas paslaugų rinkinys.
Tai panašu į nedidelį paslaugų pogrupį žiūrėti per didinamąjį stiklą, kad būtų galima jį kruopščiai ištirti. Tai leis vartotojui užduoti aktualesnius klausimus apie sudėtingą šių paslaugų sąveiką ir tiesioginę jų priklausomybę. Tai panašu į „backtrace“ paslaugų pasaulyje, kur inžinierius žino kad neteisingai, taip pat turi tam tikrą supratimą apie tai, kas vyksta aplinkinėse tarnybose kodėl.
Mano reklamuojamas metodas yra visiškai priešingas „iš viršaus į apačią“, „traceview“ metodui, kai analizė pradedama nuo viso pėdsako, o po to palaipsniui pereinama prie atskirų intervalų. Priešingai, metodas „iš apačios į viršų“ pradedamas analizuojant nedidelę sritį, esančią netoli galimos incidento priežasties, o tada prireikus išplečiama paieškos erdvė (su galimybe įtraukti kitas komandas analizuoti platesnį paslaugų spektrą). Antrasis metodas labiau tinka norint greitai patikrinti pradines hipotezes. Kai bus gauti konkretūs rezultatai, bus galima pereiti prie tikslesnės ir išsamesnės analizės.
Topologijos kūrimas
Konkrečios paslaugos rodiniai gali būti nepaprastai naudingi, jei vartotojas žino kas paslauga arba paslaugų grupė yra atsakinga už delsos padidėjimą arba klaidų sukėlimą. Tačiau sudėtingoje sistemoje pažeidusios paslaugos nustatymas gali būti nereikšminga užduotis gedimo metu, ypač jei iš tarnybų nebuvo pranešta apie klaidų pranešimus.
Paslaugų topologijos kūrimas gali labai padėti išsiaiškinti, kuriai paslaugai būdingas klaidų dažnio padidėjimas arba delsos padidėjimas, dėl kurio paslauga pastebimai pablogėja. Kai aš kalbu apie topologijos kūrimą, aš neturiu omenyje paslaugų žemėlapis, kuriame rodomos visos sistemoje prieinamos ir dėl jos žinomos paslaugos . Šis vaizdas nėra geresnis nei traceview, pagrįstas nukreiptu acikliniu grafiku. Vietoj to norėčiau pamatyti dinamiškai generuojama paslaugų topologija, remiantis tam tikrais atributais, tokiais kaip klaidų dažnis, atsako laikas arba bet koks vartotojo nustatytas parametras, padedantis išsiaiškinti konkrečių įtartinų paslaugų situaciją.
Paimkime pavyzdį. Įsivaizduokime hipotetinę naujienų svetainę. Pagrindinio puslapio paslauga (Titulinis lapas) keičiasi duomenimis su Redis, su rekomendacijų paslauga, su reklamos paslauga ir vaizdo įrašų paslauga. Vaizdo įrašų paslauga paima vaizdo įrašus iš S3 ir metaduomenis iš DynamoDB. Rekomendacijų tarnyba gauna metaduomenis iš „DynamoDB“, įkelia duomenis iš „Redis“ ir „MySQL“ bei rašo pranešimus „Kafka“. Reklamos paslauga gauna duomenis iš MySQL ir rašo pranešimus Kafkai.
Žemiau pateikiamas šios topologijos schematiškas vaizdas (daugelis komercinių maršruto parinkimo programų sukuria topologiją). Tai gali būti naudinga, jei reikia suprasti paslaugų priklausomybes. Tačiau per derinimas, kai tam tikra paslauga (tarkim, vaizdo paslauga) pasižymi padidintu atsako laiku, tokia topologija nėra labai naudinga.
Hipotetinės naujienų svetainės paslaugų schema
Žemiau pateikta diagrama būtų tinkamesnė. Iškilo su paslauga susijusi problema (vaizdo įrašas) pavaizduotas pačiame centre. Vartotojas tai iškart pastebi. Iš šios vizualizacijos tampa aišku, kad vaizdo paslauga veikia nenormaliai dėl pailgėjusio S3 atsako laiko, o tai turi įtakos dalies pagrindinio puslapio įkėlimo greičiui.
Dinaminė topologija, rodanti tik „įdomias“ paslaugas
Dinamiškai generuojamos topologijos gali būti efektyvesnės nei statiniai paslaugų žemėlapiai, ypač elastingose, automatinio mastelio keitimo infrastruktūrose. Galimybė palyginti ir supriešinti paslaugų topologijas leidžia vartotojui užduoti aktualesnius klausimus. Tikėtina, kad tikslesni klausimai apie sistemą padės geriau suprasti, kaip sistema veikia.
Lyginamasis ekranas
Kita naudinga vizualizacija būtų lyginamasis ekranas. Šiuo metu pėdsakai nėra labai tinkami lyginimui šalia, todėl palyginimai dažniausiai yra apima. Ir pagrindinė šio straipsnio idėja yra būtent ta, kad intervalai yra per žemi, kad būtų galima išgauti vertingiausią informaciją iš pėdsakų rezultatų.
Dviejų pėdsakų palyginimas nereikalauja iš esmės naujų vizualizacijų. Tiesą sakant, pakanka kažko panašaus į histogramą, vaizduojančią tą pačią informaciją kaip ir traceview. Keista, bet net šis paprastas metodas gali duoti daug daugiau vaisių, nei tiesiog tiriant du pėdsakus atskirai. Galimybė būtų dar galingesnė vizualizuoti pėdsakų palyginimas Iš viso. Būtų labai naudinga pamatyti, kaip neseniai įdiegtas duomenų bazės konfigūracijos pakeitimas, leidžiantis įgalinti GC (šiukšlių surinkimą), paveikia tolesnių paslaugų reakcijos laiką kelių valandų mastu. Jei tai, ką čia aprašau, skamba kaip infrastruktūros pokyčių poveikio A/B analizė daugelyje paslaugų naudojant pėdsakų rezultatus, tada nesate per toli nuo tiesos.
išvada
Neabejoju paties sekimo naudingumu. Nuoširdžiai tikiu, kad nėra kito metodo, kaip rinkti tokius turtingus, priežastinius ir kontekstinius duomenis, kokie yra pėdsakuose. Tačiau taip pat manau, kad visi sekimo sprendimai šiuos duomenis naudoja itin neefektyviai. Kol sekimo įrankiai bus įstrigę traceview atvaizde, jų galimybės maksimaliai išnaudoti vertingą informaciją, kurią galima išgauti iš pėdsakuose esančių duomenų. Be to, kyla pavojus toliau kurti visiškai nedraugišką ir neintuityvią vaizdinę sąsają, kuri labai apribos vartotojo galimybes šalinti programos klaidas.
Sudėtingų sistemų derinimas, net naudojant naujausius įrankius, yra neįtikėtinai sunkus. Įrankiai turėtų padėti kūrėjui suformuluoti ir patikrinti hipotezę, aktyviai teikiant atitinkama informacija, nustatant iškrypimus ir atkreipiant dėmesį į vėlavimų pasiskirstymo ypatybes. Kad sekimas taptų kūrėjų pasirinkimo įrankiu šalinant gamybos gedimus arba sprendžiant problemas, apimančias kelias paslaugas, reikia originalių vartotojo sąsajų ir vizualizacijų, kurios labiau atitiktų tas paslaugas kuriančių ir valdančių kūrėjų mentalinį modelį.
Reikės didelių protinių pastangų sukurti sistemą, kuri atvaizduotų įvairius signalus, esančius sekimo rezultatuose, optimizuotu būdu, kad būtų lengviau analizuoti ir daryti išvadas. Turite pagalvoti, kaip derinimo metu abstrahuoti sistemos topologiją taip, kad vartotojas galėtų įveikti akląsias zonas, nežiūrint į atskirus pėdsakus ar tarpsnius.
Mums reikia gerų abstrakcijos ir sluoksniavimo galimybių (ypač vartotojo sąsajoje). Tokie, kurie puikiai tiktų hipotezėmis grindžiamam derinimo procesui, kuriame galite pakartotinai užduoti klausimus ir patikrinti hipotezes. Jie automatiškai neišspręs visų stebimumo problemų, tačiau padės vartotojams sustiprinti intuiciją ir suformuluoti protingesnius klausimus. Kviečiu labiau apgalvotą ir novatoriškesnį požiūrį į vizualizaciją. Čia yra reali perspektyva plėsti akiratį.
PS iš vertėjo
Taip pat skaitykite mūsų tinklaraštyje:
- «»;
- «»;
- «".
Šaltinis: www.habr.com