Märge. tõlge: Selle materjali autor on Cindy Sridharan, imgixi insener, kes on spetsialiseerunud API arendamisele ja eelkõige mikroteenuste testimisele. Selles materjalis jagab ta oma üksikasjalikku nägemust praegustest probleemidest hajutatud jälgimise valdkonnas, kus tema arvates napib tõeliselt tõhusaid tööriistu pakiliste probleemide lahendamiseks.
[Illustratsioon võetud hajutatud jälgimise kohta.]
Usutakse, et raske rakendada ja selle tasuvus . Põhjuseid, miks jälgimine on problemaatiline, on palju, viidates sageli tööjõule, mis on seotud iga süsteemikomponendi konfigureerimisega, et edastada iga päringuga sobivad päised. Kuigi see probleem on olemas, pole see mingil juhul ületamatu. Muide, see ei selgita, miks arendajatele jälitamine tegelikult ei meeldi (isegi kui see juba töötab).
Jaotatud jälgimise peamine väljakutse ei ole andmete kogumine, tulemuste levitamise ja esitamise vormingute standardimine ega proovide võtmise aja, koha ja viisi määramine. Ma ei püüa ette kujutada triviaalne need "arusaadavuse probleemid" on tegelikult üsna olulised tehnilised ja (kui me mõtleme tõeliselt avatud lähtekoodiga) ) poliitilised väljakutsed, mis tuleb ületada, et need probleemid loetaks lahendatuks.
Kui aga kujutame ette, et kõik need probleemid on lahendatud, siis on suur tõenäosus, et miski oluliselt ei muutu. lõppkasutaja kogemus. Jälgimine ei pruugi siiski olla kõige tavalisemate silumisstsenaariumide puhul praktiline – isegi pärast selle juurutamist.
Selline teistsugune jälg
Jaotatud jälgimine sisaldab mitut erinevat komponenti:
- rakenduste ja vahevara varustamine juhtimisvahenditega;
- hajutatud konteksti ülekanne;
- jälgede kogumine;
- jälgede säilitamine;
- nende ekstraheerimine ja visualiseerimine.
Palju räägitakse hajutatud jälgimisest, käsitletakse seda kui ühtset toimingut, mille ainus eesmärk on aidata süsteemi täielikult diagnoosida. See on suuresti tingitud sellest, kuidas ideed hajutatud jälgimise kohta on ajalooliselt kujunenud. IN , mis tehti Zipkini allikate avamisel, mainiti, et see [Zipkin] muudab Twitteri kiiremaks. Samuti reklaamiti esimesi kommertspakkumisi jälgimiseks .
Märge. tõlge: Täiendava teksti arusaadavamaks muutmiseks defineerime vastavalt kaks põhimõistet :
- sille — hajutatud jälgimise põhielement. See on teatud töövoo kirjeldus (näiteks andmebaasi päring) koos nime, algus- ja lõpuaegade, siltide, logide ja kontekstiga.
- Tavaliselt sisaldavad vahemikud linke teistele vahemikele, võimaldades kombineerida mitut ulatust Jälg — päringu eluea visualiseerimine, kui see liigub hajussüsteemis.
Jäljed sisaldavad uskumatult väärtuslikke andmeid, mis võivad aidata selliste ülesannete täitmisel nagu tootmise testimine, avariitaaste testimine, vigade sisestamise testimine jne. Tegelikult kasutavad mõned ettevõtted juba sarnastel eesmärkidel jälgimist. Alustame sellest sellel on muud kasutusalad peale vahede lihtsalt salvestussüsteemi teisaldamise:
- Näiteks Uber tulemuste jälgimine, et eristada testliiklust tootmisliiklusest.
- Facebook jälgige andmeid kriitilise tee analüüsiks ja liikluse ümberlülitamiseks tavaliste avariitaastetestide ajal.
- Samuti sotsiaalvõrgustik Jupyteri sülearvutid, mis võimaldavad arendajatel käivitada suvalisi päringuid jälgimistulemuste kohta.
- Jälgijad (Lineage Driven Failure Injection) jaotatud jäljed testimiseks veasüstiga.
Ükski ülaltoodud võimalustest ei kehti selle stsenaariumi puhul täielikult silumine, mille käigus insener püüab jälge vaadates probleemi lahendada.
Kui see tuleb veel jõuab silumisskriptini, jääb esmaseks liideseks diagramm traceview (kuigi mõned nimetavad seda ka "Gantti diagramm" või "juga diagramm"). Under traceview я kõik ulatused ja kaasnevad metaandmed, mis koos moodustavad jälje. Iga avatud lähtekoodiga jälgimissüsteem, nagu ka iga kaubanduslik jälgimislahendus, pakub a traceview kasutajaliides jälgede visualiseerimiseks, täpsustamiseks ja filtreerimiseks.
Kõigi seni nähtud jälgimissüsteemide probleem on see, et tulemus visualiseerimine (jäljevaade) peegeldab peaaegu täielikult jälgede genereerimise protsessi iseärasusi. Isegi kui pakutakse välja alternatiivsed visualiseeringud: soojuskaardid, teenuse topoloogiad, latentsushistogrammid, taanduvad need lõpuks ikkagi traceview.
Minevikus I millega enamik UI/UX jälgimise "uuendusi" näib piirduvat täiendavad metaandmed, investeerides neisse suure kardinaalsusega teavet (kõrge kardinaalsus) või pakkudes võimalust süveneda konkreetsetesse ulatustesse või käitada päringuid inter- ja intra-trace... Kusjuures traceview jääb peamiseks visualiseerimisvahendiks. Niikaua kui selline olukord jätkub, võtab hajutatud jälgimine (parimal juhul) silumisvahendina mõõdikute, logide ja virnajälgede järel 4. koha ning halvimal juhul osutub see raha ja aja raiskamiseks.
Probleem traceview'ga
Eesmärk traceview — anda täielik ülevaade ühe päringu liikumisest hajussüsteemi kõigis komponentides, millega see on seotud. Mõned täiustatud jälgimissüsteemid võimaldavad teil süveneda üksikutesse ulatustesse ja vaadata jaotust aja jooksul jooksul üks protsess (kui ulatustel on funktsionaalsed piirid).
Mikroteenuste arhitektuuri põhieelduseks on idee, et organisatsiooni struktuur kasvab koos ettevõtte vajadustega. Mikroteenuste pooldajad väidavad, et erinevate äriülesannete jaotamine üksikuteks teenusteks võimaldab väikestel autonoomsetel arendusmeeskondadel kontrollida selliste teenuste kogu elutsüklit, andes neile võimaluse neid teenuseid iseseisvalt luua, testida ja juurutada. Selle jaotuse puuduseks on aga teabe kadumine selle kohta, kuidas iga teenus teistega suhtleb. Sellistes tingimustes väidab hajutatud jälgimine olevat asendamatu tööriist silumine teenustevahelised keerulised vastasmõjud.
Kui sa tõesti , siis ei suuda ükski inimene seda oma peas hoida täielik pilt. Tegelikult on tööriista väljatöötamine eeldusel, et see on isegi võimalik, antimustrilaadne (ebaefektiivne ja ebaproduktiivne lähenemine). Ideaalis vajab silumine tööriista, mis aitab kitsendage oma otsinguala, et insenerid saaksid keskenduda vaadeldava probleemistsenaariumiga seotud mõõtmete alamhulgale (teenused/kasutajad/hostid jne). Rikke põhjuse kindlakstegemisel ei pea insenerid aru saama, mis rikke ajal juhtus kõik teenused korraga, kuna selline nõue oleks vastuolus mikroteenuste arhitektuuri ideega.
Traceview on aga nimelt See. Jah, mõned jälgimissüsteemid pakuvad tihendatud jälgimisvaateid, kui jälgede pikkuste arv on nii suur, et neid ei saa ühes visualiseeringus kuvada. Kuid isegi sellises nihutatud visualiseeringus sisalduva suure teabehulga tõttu on insenerid endiselt sunnitud "sõela" seda, kitsendades valikut käsitsi probleemide allikaks olevate teenuste komplekti. Kahjuks on selles valdkonnas masinad palju kiiremad kui inimesed, vähem altid vigadele ja nende tulemused on paremini korratavad.
Teine põhjus, miks ma arvan, et traceview on vale, on see, et see pole hüpoteesil põhineva silumise jaoks hea. Selle tuumaks on silumine iteratiivne hüpoteesist algav protsess, millele järgneb süsteemist saadud erinevate tähelepanekute ja faktide kontrollimine mööda erinevaid vektoreid, järeldused/üldistused ja edasine hüpoteesi tõesuse hindamine.
Võimalus kiire ja odav hüpoteeside kontrollimine ja vastavalt sellele vaimse mudeli täiustamine on nurgakivi silumine Iga silumistööriist peaks olema interaktiivne ja kitsendada otsinguruumi või valevihje korral lubada kasutajal tagasi minna ja keskenduda süsteemi teisele piirkonnale. Ideaalne tööriist teeb seda ennetavalt, juhtides koheselt kasutaja tähelepanu võimalikele probleemsetele kohtadele.
paraku traceview ei saa nimetada interaktiivse liidesega tööriistaks. Parim, mida saate selle kasutamisel loota, on leida mõni suurenenud latentsusaja allikas ja vaadata kõiki sellega seotud võimalikke silte ja logisid. See ei aita inseneril tuvastada mustrid liikluses, näiteks viivituse jaotuse spetsiifikat, või tuvastada korrelatsioone erinevate mõõtmiste vahel. võib aidata mõnest neist probleemidest mööda saada. Tõesti, edukas analüüs masinõppe abil, et tuvastada anomaalsed vahemikud ja tuvastada märgendite alamhulk, mida võib seostada anomaalse käitumisega. Siiski pole ma veel näinud veenvaid visualiseerimisi masinõppe või andmekaeve leidude kohta, mis on rakendatud vahemikele, mis erinevad oluliselt jälgimisvaatest või DAG-st (suunatud atsükliline graafik).
Sirged on liiga madalad
Traceview põhiprobleem on see ulatub on liiga madala taseme primitiivid nii latentsusanalüüsi kui ka algpõhjuste analüüsi jaoks. See on nagu üksikute protsessori käskude sõelumine, et proovida erandit lahendada, teades, et on palju kõrgema taseme tööriistu, nagu backtrace, millega on palju mugavam töötada.
Lisaks võtan endale vabaduse väita järgmist: ideaaljuhul me ei vaja täispilt toimus päringu elutsükli jooksul, mida esindavad kaasaegsed jälgimistööriistad. Selle asemel on vaja mingit kõrgema taseme abstraktsiooni, mis sisaldab teavet selle kohta, mida läks valesti (sarnaselt tagajäljega) koos mõne kontekstiga. Selle asemel, et kogu jälge vaadata, eelistan seda näha часть, kus juhtub midagi huvitavat või ebatavalist. Praegu toimub otsing käsitsi: insener saab jälje ja analüüsib iseseisvalt ulatusi, otsides midagi huvitavat. Inimesed, kes vaatavad üksikute jälgede kaupa vahemikke, lootes tuvastada kahtlast tegevust, ei mastaapse üldse (eriti kui nad peavad mõistma kõiki erinevatesse ulatustesse kodeeritud metaandmeid, nagu vahemiku ID, RPC meetodi nimi, ulatuse kestus 'a, logid, sildid jne).
Traceview alternatiivid
Jälgimistulemused on kõige kasulikumad, kui neid saab visualiseerida viisil, mis annab mittetriviaalse ülevaate süsteemi omavahel ühendatud osades toimuvast. Kuni see ei juhtu, jääb silumisprotsess suures osas alles inertne ja see sõltub kasutaja võimest märgata õigeid seoseid, kontrollida süsteemi õigeid osi või pusletükke kokku panna – erinevalt tööriist, mis aitab kasutajal neid hüpoteese sõnastada.
Ma ei ole visuaalne kujundaja ega kasutajakogemuse spetsialist, kuid järgmises osas tahan jagada mõningaid ideid selle kohta, millised need visualiseeringud võiksid välja näha.
Keskenduge konkreetsetele teenustele
Ajal, mil tööstus koondub ideede ümber , tundub mõistlik, et üksikud meeskonnad peaksid esmajärjekorras tagama, et nende teenused on nende eesmärkidega kooskõlas. Sellest järeldub teenindusele orienteeritud visualiseerimine sobib sellistele meeskondadele kõige paremini.
Jäljed, eriti ilma proovivõtuta, on hajutatud süsteemi iga komponendi kohta teabe aare. Seda teavet saab anda kavalale protsessorile, mis varustab kasutajaid teenindusele orienteeritud leiud. Neid saab eelnevalt tuvastada – isegi enne, kui kasutaja jälgi vaatab:
- Latentsusaja jaotusskeemid ainult väga silmapaistvate päringute jaoks (kõrvalealised taotlused);
- Viivituse jaotuse diagrammid juhtudel, kui teenuse SLO eesmärke ei saavutata;
- Kõige “levinud”, “huvitavamad” ja “veidramad” sildid päringutes, mis kõige sagedamini korratakse;
- Latentsuse jaotus juhtudel, kui sõltuvused teenused ei saavuta oma SLO eesmärke;
- Latentsuse jaotus erinevatele allavooluteenustele.
Sisseehitatud mõõdikud lihtsalt ei vasta mõnele neist küsimustest, mis sunnib kasutajaid vahemikke kontrollima. Selle tulemusena on meil äärmiselt kasutajavaenulik mehhanism.
See tõstatab küsimuse: kuidas on lood keerukate interaktsioonidega erinevate meeskondade juhitavate erinevate teenuste vahel? Eks ole traceview ei peeta kõige sobivamaks vahendiks sellise olukorra esiletõstmiseks?
Mobiiliarendajad, kodakondsuseta teenuste omanikud, hallatavate olekupõhiste teenuste (nt andmebaasid) omanikud ja platvormide omanikud võivad olla huvitatud millestki muust esitlus hajutatud süsteem; traceview on nende põhimõtteliselt erinevate vajaduste jaoks liiga üldine lahendus. Isegi väga keerulise mikroteenuste arhitektuuri puhul ei vaja teenuseomanikud sügavaid teadmisi rohkem kui kahe või kolme üles- ja allavoolu teenuse kohta. Põhimõtteliselt peavad kasutajad enamiku stsenaariumide korral vastama ainult seotud küsimustele piiratud teenuste komplekt.
See on nagu väikese teenuste alamhulga vaatamine läbi suurendusklaasi, et seda kontrollida. See võimaldab kasutajal esitada pakilisemaid küsimusi nende teenuste keeruka koostoime ja nende vahetute sõltuvuste kohta. See sarnaneb tagasijälitusega teenusemaailmas, kus insener teab et vale, ja mõistab ka ümbritsevates teenustes toimuvat miks.
Minu propageeritav lähenemine on täpselt vastupidine ülalt-alla, jälgimisvaatel põhinevale lähenemisviisile, kus analüüs algab kogu jäljest ja jõuab seejärel järk-järgult üksikute ulatusteni. Seevastu alt-üles lähenemine algab väikese ala analüüsimisega, mis on intsidendi võimaliku põhjuse lähedal, ja seejärel laiendab otsinguruumi vastavalt vajadusele (võimalusega kaasata teisi meeskondi, et analüüsida laiemat valikut teenuseid). Teine lähenemisviis sobib paremini esialgsete hüpoteeside kiireks kontrollimiseks. Kui konkreetsed tulemused on saavutatud, on võimalik liikuda edasi keskendunud ja üksikasjalikuma analüüsi juurde.
Topoloogia loomine
Teenusepõhised vaated võivad olla väga kasulikud, kui kasutaja teab mis teenus või teenuste rühm vastutab latentsuse suurendamise või vigade tekitamise eest. Keerulises süsteemis võib aga rikkuva teenuse tuvastamine tõrke ajal olla mittetriviaalne ülesanne, eriti kui teenustest ei teatatud veateateid.
Teenuse topoloogia loomine võib olla suureks abiks selle väljaselgitamisel, millises teenuses esineb veamäära tõusu või latentsusaja suurenemist, mis põhjustab teenuse märgatava halvenemise. Kui ma räägin topoloogia loomisest, ei pea ma silmas teenuste kaart, kus kuvatakse kõik süsteemis saadaolevad ja selle poolest tuntud teenused . See vaade pole parem kui traceview, mis põhineb suunatud atsüklilisel graafikul. Selle asemel tahaksin näha dünaamiliselt genereeritud teenuse topoloogia, mis põhineb teatud atribuutidel, nagu veamäär, reageerimisaeg või mis tahes kasutaja määratud parameeter, mis aitab konkreetsete kahtlaste teenuste puhul olukorda selgitada.
Võtame näite. Kujutagem ette hüpoteetilist uudiste saiti. Kodulehe teenus (Esilehekülg) vahetab andmeid Redisega, soovitusteenusega, reklaamiteenusega ja videoteenusega. Videoteenus võtab videod S3-st ja metaandmed DynamoDB-st. Soovitusteenus saab metaandmeid DynamoDB-st, laadib andmeid Redisest ja MySQL-ist ning kirjutab sõnumeid Kafkale. Reklaamiteenus saab MySQL-ist andmeid ja kirjutab sõnumeid Kafkale.
Allpool on selle topoloogia skemaatiline esitus (paljud kaubanduslikud marsruutimisprogrammid loovad topoloogia). See võib olla kasulik, kui peate mõistma teenuse sõltuvusi. Siiski ajal silumine, kui teatud teenusel (näiteks videoteenusel) on pikem reageerimisaeg, pole selline topoloogia eriti kasulik.
Hüpoteetilise uudistesaidi teenindusskeem
Allolev diagramm sobiks paremini. Teenusega on probleem (video) kujutatud otse keskel. Kasutaja märkab seda kohe. Sellest visualiseerimisest selgub, et videoteenus töötab S3 reageerimisaja pikenemise tõttu ebanormaalselt, mis mõjutab põhilehe osa laadimiskiirust.
Dünaamiline topoloogia, mis kuvab ainult "huvitavaid" teenuseid
Dünaamiliselt genereeritud topoloogiad võivad olla tõhusamad kui staatilised teeninduskaardid, eriti elastsetes, automaatselt skaleeruvates infrastruktuurides. Võimalus võrrelda ja vastandada teenuse topoloogiaid võimaldab kasutajal esitada asjakohasemaid küsimusi. Täpsemad küsimused süsteemi kohta aitavad tõenäolisemalt paremini mõista, kuidas süsteem toimib.
Võrdlev kuva
Teine kasulik visualiseerimine oleks võrdlev ekraan. Praegu ei ole jäljed kõrvuti võrdlemiseks eriti sobivad, seega on võrdlused tavaliselt sobivad ulatub. Ja selle artikli põhiidee on just see, et ulatused on liiga madalad, et jäljetulemustest kõige väärtuslikumat teavet eraldada.
Kahe jälje võrdlemine ei nõua põhimõtteliselt uusi visualiseerimisi. Tegelikult piisab sellisest nagu histogramm, mis esindab sama teavet kui jäljevaade. Üllataval kombel võib isegi see lihtne meetod tuua palju rohkem vilja kui lihtsalt kahe jälje eraldi uurimine. Võimalus oleks veelgi võimsam visualiseerida jälgede võrdlus Kokku. Oleks äärmiselt kasulik näha, kuidas hiljuti juurutatud andmebaasi konfiguratsiooni muudatus GC (prügikogumise) lubamiseks mõjutab allavooluteenuse reageerimisaega mitme tunni ulatuses. Kui see, mida ma siin kirjeldan, kõlab nagu A/B analüüs infrastruktuuri muudatuste mõju kohta paljudes teenustes kasutades jälgi tulemusi, siis pole te tõest liiga kaugel.
Järeldus
Ma ei sea kahtluse alla jälgimise enda kasulikkust. Usun siiralt, et pole ühtegi teist meetodit nii rikkalike, põhjuslike ja kontekstuaalsete andmete kogumiseks kui need, mis sisalduvad jäljes. Samas usun ka, et kõik jälgimislahendused kasutavad neid andmeid äärmiselt ebaefektiivselt. Niikaua kui jälgimistööriistad jäävad traceview esitusse kinni, on nende võime kasutada maksimaalselt ära väärtuslikku teavet, mida jälgedes sisalduvatest andmetest saab eraldada. Lisaks on oht arendada edasi täiesti ebasõbralikku ja ebaintuitiivset visuaalset liidest, mis piirab oluliselt kasutaja võimalusi rakenduses esinevate vigade otsimisel.
Keeruliste süsteemide silumine, isegi uusimate tööriistadega, on uskumatult keeruline. Tööriistad peaksid aitama arendajal hüpoteesi sõnastada ja testida, aktiivselt pakkuma asjakohast teavet, tuvastades kõrvalekaldeid ja märkides ära viivituste jaotumise tunnused. Selleks, et jälgimisest saaks arendajate jaoks valitud tööriist tootmistõrgete tõrkeotsingul või mitut teenust hõlmavate probleemide lahendamisel, on vaja originaalseid kasutajaliideseid ja visualiseerimisi, mis on paremini kooskõlas neid teenuseid loovate ja opereerivate arendajate vaimse mudeliga.
See nõuab märkimisväärseid vaimseid jõupingutusi, et kujundada süsteem, mis esindaks erinevaid jälgimistulemustes saadaolevaid signaale viisil, mis on analüüsi ja järelduste hõlbustamiseks optimeeritud. Peate mõtlema, kuidas süsteemi topoloogiat silumise ajal abstraktselt võtta viisil, mis aitaks kasutajal ületada pimedad nurgad ilma üksikuid jälgi või vahemikke vaatamata.
Vajame häid abstraktsiooni- ja kihistamisvõimalusi (eriti kasutajaliideses). Sellised, mis sobiksid hästi hüpoteesil põhinevasse silumisprotsessi, kus saate iteratiivselt küsimusi esitada ja hüpoteese testida. Need ei lahenda automaatselt kõiki jälgitavusega seotud probleeme, kuid aitavad kasutajatel oma intuitsiooni teravdada ja targemaid küsimusi sõnastada. Kutsun üles läbimõeldumat ja uuenduslikumat lähenemist visualiseerimisele. Siin on tõeline väljavaade silmaringi laiendada.
PS tõlkijalt
Loe ka meie blogist:
- «";
- «";
- «'.
Allikas: www.habr.com