Athugið. þýð.: Höfundur þessa efnis er Cindy Sridharan, verkfræðingur hjá imgix sem sérhæfir sig í þróun API og sérstaklega örþjónustuprófunum. Í þessu efni deilir hún ítarlegri sýn sinni á núverandi vandamál á sviði dreifðra rekja, þar sem að hennar mati skortir raunverulega áhrifarík tæki til að leysa brýn vandamál.
[Myndskreyting tekin úr um dreifða rakningu.]
Það er talið að erfitt í framkvæmd, og arðsemi af því . Það eru margar ástæður fyrir því að rekja er vandamál, oft vitnað í vinnuna sem fylgir því að stilla hvern kerfishluta til að senda viðeigandi hausa með hverri beiðni. Þó að þetta vandamál sé til staðar er það alls ekki óyfirstíganlegt. Við the vegur, það útskýrir ekki hvers vegna verktaki líkar ekki í raun að rekja (jafnvel þegar það virkar nú þegar).
Helsta áskorunin við dreifða rakningu er ekki að safna gögnum, staðla snið til að dreifa og kynna niðurstöður eða ákvarða hvenær, hvar og hvernig á að taka sýni. Ég er ekki að reyna að ímynda mér léttvægur þessi „skilningsvandamál“ eru í raun töluverð tæknileg og (ef við erum að íhuga raunverulegan opinn uppspretta) ) pólitískar áskoranir sem þarf að sigrast á svo þessi vandamál geti talist leyst.
Hins vegar, ef við ímyndum okkur að öll þessi vandamál séu leyst, eru miklar líkur á að ekkert breytist verulega m.t.t. upplifun endanotenda. Rekja gæti samt ekki verið hagnýtt í algengustu villuleitaratburðarásinni - jafnvel eftir að það hefur verið notað.
Svona öðruvísi ummerki
Dreifð rakning inniheldur nokkra ólíka hluti:
- útbúa forrit og millibúnað með stjórntækjum;
- dreifður samhengisflutningur;
- söfnun ummerkja;
- ummerki geymsla;
- útdráttur þeirra og sjónmyndun.
Mikið talað um dreifða rakningu hefur tilhneigingu til að meðhöndla það sem eins konar einhæfa aðgerð sem hefur það eina markmið að hjálpa til við að greina kerfið að fullu. Þetta er að miklu leyti vegna þess hvernig hugmyndir um dreifða rekja hafa myndast sögulega. IN , sem gerð var þegar Zipkin heimildirnar voru opnaðar, var minnst á það það [Zipkin] gerir Twitter hraðari. Fyrstu viðskiptatilboðin til að rekja voru einnig kynnt sem .
Athugið. þýð.: Til að gera frekari texta auðveldari að skilja, skulum við skilgreina tvö grunnhugtök skv :
- Span — grunnþáttur dreifðrar rakningar. Það er lýsing á ákveðnu verkflæði (til dæmis gagnagrunnsfyrirspurn) með nafni, upphafs- og lokatíma, merkjum, annálum og samhengi.
- Spönn innihalda venjulega tengla á önnur span, sem gerir kleift að sameina mörg span í Rekja — sjónræning á líftíma beiðni þar sem hún fer í gegnum dreift kerfi.
Ummerki innihalda ótrúlega verðmæt gögn sem geta hjálpað til við verkefni eins og framleiðsluprófun, hörmungaprófun, villuinnspýtingarprófun o.s.frv. Reyndar nota sum fyrirtæki nú þegar rakningu í svipuðum tilgangi. Við skulum byrja með hefur aðra notkun fyrir utan einfaldlega að færa span í geymslukerfið:
- Til dæmis Uber að rekja niðurstöður til að greina á milli prófunarumferðar og framleiðsluumferðar.
- Facebook rekja gögn fyrir greiningu á mikilvægum slóðum og til að skipta um umferð meðan á reglulegum hamfarabataprófum stendur.
- Einnig félagslegt net Jupyter fartölvur sem gera forriturum kleift að keyra handahófskenndar fyrirspurnir um rakningarniðurstöður.
- Fylgjendur (Lineage Driven Failure Injection) dreift ummerkjum til prófunar með villuinnspýtingu.
Enginn af valkostunum sem taldir eru upp hér að ofan eiga algjörlega við um atburðarásina kemba, þar sem verkfræðingurinn reynir að leysa vandamálið með því að skoða ummerkin.
Þegar það kemur strax nær kembiforritinu, er aðalviðmótið áfram skýringarmyndin traceview (þó sumir kalla það líka "Gantt myndrit" eða "fossamynd"). Undir traceview я öll spann og meðfylgjandi lýsigögn sem saman mynda ummerki. Sérhver opinn uppspretta rakningarkerfi, sem og sérhver viðskiptalausn, býður upp á a traceview notendaviðmót til að sjá, útskýra og sía ummerki.
Vandamálið með öll rekjakerfi sem ég hef séð hingað til er að afleiðingin sjónræn (traceview) endurspeglar nánast algjörlega eiginleika snefilmyndunarferlisins. Jafnvel þegar verið er að leggja til aðrar sjónmyndir: hitakort, þjónustustórfræði, leyndarstuðlamyndir, koma þær samt að lokum niður á traceview.
Áður fyrr var ég sem flestar "nýjungar" í UI/UX rekningum virðast takmarkast við viðbótar lýsigögn í rekstri, fjárfest í þeim upplýsingum með mikilli kardinalitet (mikil kardinalitet) eða veita möguleika á að kafa niður í tilteknar svið eða keyra fyrirspurnir milli- og innanspors... Hvar í traceview er áfram aðal sjónræn tól. Svo lengi sem þetta ástand heldur áfram mun dreifð rakning (í besta falli) taka 4. sætið sem villuleitartæki, á eftir mælingum, logs og staflasporum, og í versta falli reynist það sóun á peningum og tíma.
Vandamál með traceview
Tilgangur traceview — veita heildarmynd af hreyfingu einnar beiðni yfir alla íhluti dreifða kerfisins sem hún tengist. Sum fullkomnari rekjakerfi gera þér kleift að bora niður í einstök svið og skoða sundurliðun með tímanum innan eitt ferli (þegar span hafa virknimörk).
Grunnforsenda örþjónustuarkitektúrs er sú hugmynd að skipulagið vaxi með þörfum fyrirtækisins. Talsmenn örþjónustu halda því fram að dreifing ýmissa viðskiptaverkefna í einstakar þjónustur geri litlum, sjálfstæðum þróunarteymi kleift að stjórna öllu líftíma slíkrar þjónustu, sem gefur þeim möguleika á að byggja upp, prófa og dreifa þessari þjónustu sjálfstætt. Ókosturinn við þessa dreifingu er hins vegar tap á upplýsingum um hvernig hver þjónusta hefur samskipti við aðra. Við slíkar aðstæður segist dreifð rakning vera ómissandi tæki fyrir kemba flókið samspil þjónustu.
Ef þú virkilega , þá er ekki einn einasti maður fær um að halda því í hausnum heill mynd. Reyndar, að þróa tól sem byggir á þeirri forsendu að það sé jafnvel mögulegt er eitthvað af andmynstri (áhrifalaus og óframkvæmanleg nálgun). Helst þarf kembiforrit tól sem hjálpar þrengja leitarsvæðið þitt, þannig að verkfræðingar geti einbeitt sér að undirmengi af víddum (þjónustu/notendum/hýsingum o.s.frv.) sem eiga við um vandamálið sem verið er að skoða. Þegar ákvarðað er orsök bilunar þurfa verkfræðingar ekki að skilja hvað gerðist á meðan alla þjónustu í einu, þar sem slík krafa myndi stangast á við hugmyndina um örþjónustuarkitektúr.
Hins vegar er traceview nefnilega Þetta. Já, sum rakningarkerfi bjóða upp á þjappað rekjaskoðanir þegar fjöldi spanna í rakningunni er svo mikill að ekki er hægt að birta þau í einni sjónmynd. Hins vegar, vegna mikils magns upplýsinga sem er að finna jafnvel í slíkri niðurrifnu sjónmynd, eru verkfræðingar enn neydd „sigtaðu“ það, þrengdu valið handvirkt í hóp þjónustu sem eru uppspretta vandamála. Því miður, á þessu sviði, eru vélar miklu hraðari en menn, minna viðkvæmir fyrir villum og niðurstöður þeirra eru endurteknar.
Önnur ástæða fyrir því að ég tel að traceview sé rangt er vegna þess að það er ekki gott fyrir tilgátu-drifin kembiforrit. Í kjarna þess er villuleit endurtekið ferli sem byrjar á tilgátu, fylgt eftir með sannprófun á ýmsum athugunum og staðreyndum sem fengnar eru úr kerfinu eftir mismunandi vektorum, ályktunum/alhæfingum og frekara mati á sannleika tilgátunnar.
Tækifæri hratt og ódýrt að prófa tilgátur og bæta andlega líkanið í samræmi við það hornsteinn villuleit Hvaða kembiforrit ætti að vera gagnvirkt og þrengja leitarrýmið eða, ef um ranga leið er að ræða, leyfa notandanum að fara til baka og einbeita sér að öðru svæði kerfisins. Hið fullkomna tól mun gera þetta fyrirbyggjandi, vekur strax athygli notandans á hugsanlegum vandamálasvæðum.
Því miður, traceview ekki hægt að kalla tól með gagnvirku viðmóti. Það besta sem þú getur vonast eftir þegar þú notar það er að finna einhverja uppsprettu aukinnar leynd og skoða öll möguleg merki og logs sem tengjast því. Þetta hjálpar verkfræðingnum ekki að bera kennsl á mynstur í umferðinni, eins og sérkenni seinkunardreifingar, eða greina fylgni milli mismunandi mælinga. gæti hjálpað til við að komast yfir sum þessara vandamála. Í alvöru, árangursrík greining með því að nota vélanám til að bera kennsl á afbrigðileg svið og bera kennsl á undirmengi merkja sem gætu tengst afbrigðilegri hegðun. Hins vegar hef ég enn ekki séð sannfærandi sjónmyndir af vélanámi eða gagnavinnsluniðurstöðum beitt á span sem eru verulega frábrugðin traceview eða DAG (stýrt ósýklískt graf).
Spönn eru of lág
Grundvallarvandamálið við traceview er það spannar eru of lág-stig frumstæður fyrir bæði leynd greiningu og rót orsök greiningu. Það er eins og að flokka einstakar örgjörvaskipanir til að reyna að leysa undantekningu, vitandi að það eru til miklu hærra stigi verkfæri eins og bakslag sem er miklu þægilegra að vinna með.
Þar að auki mun ég leyfa mér að fullyrða eftirfarandi: helst þurfum við ekki heildarmynd átti sér stað á lífsferli beiðninnar, sem er táknað með nútíma rekjatækjum. Þess í stað er krafist einhvers konar útdráttar á hærra stigi sem inniheldur upplýsingar um hvað fór úrskeiðis (svipað og backtrace), ásamt einhverju samhengi. Í stað þess að horfa á allt ummerki, kýs ég að sjá það часть, þar sem eitthvað áhugavert eða óvenjulegt gerist. Eins og er er leitin framkvæmd handvirkt: verkfræðingurinn fær ummerkin og greinir sjálfstætt spannirnar í leit að einhverju áhugaverðu. Nálgun fólks að glápa á span í einstökum sporum í von um að greina grunsamlega virkni mælist alls ekki (sérstaklega þegar það þarf að gera sér grein fyrir öllum lýsigögnum sem eru kóðuð á mismunandi sviðum, eins og span ID, RPC aðferð heiti, span lengd. 'a, logs, merki o.s.frv.).
Valkostir við traceview
Niðurstöður rakningar eru gagnlegastar þegar hægt er að sjá þær fyrir sér á þann hátt sem veitir ekki léttvæga innsýn í hvað er að gerast í samtengdum hlutum kerfisins. Þar til þetta gerist er kembiforritið að mestu eftir óvirkur og fer eftir hæfni notandans til að taka eftir réttum fylgni, athuga rétta hluta kerfisins eða setja púslstykkin saman - öfugt við tæki, sem hjálpar notandanum að móta þessar tilgátur.
Ég er ekki sjónhönnuður eða UX sérfræðingur, en í næsta kafla vil ég deila nokkrum hugmyndum um hvernig þessar sjónmyndir gætu litið út.
Leggðu áherslu á sérstaka þjónustu
Á þeim tíma þegar iðnaðurinn er að sameinast í kringum hugmyndir , það virðist sanngjarnt að einstök teymi setji í forgang að tryggja að þjónusta þeirra sé í samræmi við þessi markmið. Af því leiðir þjónustumiðuð sjónræning hentar best fyrir slík teymi.
Ummerki, sérstaklega án sýnatöku, eru fjársjóður upplýsinga um hvern hluta dreifðs kerfis. Þessar upplýsingar er hægt að gefa til slægs örgjörva sem mun útvega notendum þjónustumiðuð Niðurstöður. Hægt er að bera kennsl á þær fyrirfram - jafnvel áður en notandinn skoðar ummerkin:
- Töf dreifingarmyndir aðeins fyrir mjög áberandi beiðnir (óviðkomandi beiðnir);
- Skýringarmyndir um tafadreifingu fyrir tilvik þar sem markmiðum SLO þjónustu er ekki náð;
- „Algengustu“, „áhugaverðustu“ og „furðulegu“ merkin í fyrirspurnum sem oftast eru endurteknar;
- Töf sundurliðun fyrir tilvik þar sem ósjálfstæði þjónusta nær ekki SLO markmiðum sínum;
- Sundurliðun á biðtíma fyrir ýmsa niðurstreymisþjónustu.
Sumum þessara spurninga er einfaldlega ekki svarað með innbyggðum mælingum, sem neyðir notendur til að rýna í svið. Fyrir vikið höfum við mjög notendafjandsamlegt kerfi.
Þetta vekur upp spurninguna: hvað með flókin samskipti milli fjölbreyttrar þjónustu sem stjórnað er af mismunandi teymum? Er það ekki traceview er ekki talið heppilegasta tækið til að varpa ljósi á slíkar aðstæður?
Farsímaframleiðendur, eigendur ríkisfangslausrar þjónustu, eigendur stjórnaðrar ríkisþjónustu (eins og gagnagrunna) og eigendur palla gætu haft áhuga á einhverju öðru kynning dreift kerfi; traceview er of almenn lausn fyrir þessar í grundvallaratriðum ólíku þarfir. Jafnvel í mjög flóknum örþjónustuarkitektúr þurfa þjónustueigendur ekki djúpa þekkingu á fleiri en tveimur eða þremur uppstreymis- og niðurstreymisþjónustum. Í meginatriðum, í flestum tilfellum, þurfa notendur aðeins að svara spurningum um takmarkað úrval af þjónustu.
Þetta er eins og að horfa á lítið hlutmengi þjónustu í gegnum stækkunargler til að skoða hana. Þetta gerir notandanum kleift að spyrja áleitnari spurninga varðandi flókin samskipti þessara þjónustu og strax ósjálfstæði þeirra. Þetta er svipað og backtrace í þjónustuheiminum, þar sem verkfræðingurinn veit að rangt, og hefur líka einhvern skilning á því sem er að gerast í nærliggjandi þjónustu til að skilja hvers vegna.
Nálgunin sem ég er að kynna er akkúrat andstæða við topp-niður, traceview-miðaða nálgun, þar sem greiningin byrjar á öllu rekstrinum og vinnur síðan smám saman niður á einstaka span. Aftur á móti byrjar botn-upp nálgun á því að greina lítið svæði nálægt hugsanlegri orsök atviksins og stækkar síðan leitarrýmið eftir þörfum (með möguleika á að fá önnur teymi til að greina fjölbreyttari þjónustu). Önnur aðferðin hentar betur til að prófa fyrstu tilgátur fljótt. Þegar áþreifanlegar niðurstöður liggja fyrir verður hægt að fara yfir í markvissari og ítarlegri greiningu.
Að byggja upp staðfræði
Þjónustusértækar skoðanir geta verið ótrúlega gagnlegar ef notandinn veit hvað þjónusta eða hópur þjónustu ber ábyrgð á því að auka leynd eða valda villum. Hins vegar, í flóknu kerfi, getur verið að bera kennsl á brotaþjónustuna ekki léttvægt verkefni meðan á bilun stendur, sérstaklega ef engin villuboð voru tilkynnt frá þjónustunni.
Að byggja upp svæðisfræði þjónustu getur verið mikil hjálp við að finna út hvaða þjónusta er að upplifa aukningu í villutíðni eða aukningu á leynd sem veldur því að þjónustan rýrnar verulega. Þegar ég tala um að byggja upp staðfræði þá meina ég ekki þjónustukort, sem sýnir allar þjónustur sem til eru í kerfinu og þekktar fyrir hana . Þetta útsýni er ekkert betra en traceview byggt á stýrðu ósýklísku línuriti. Í staðinn myndi ég vilja sjá öflugt framleidd þjónustusvæðifræði, byggt á ákveðnum eiginleikum eins og villuhlutfalli, viðbragðstíma eða hvaða notendaskilgreindri færibreytu sem hjálpar til við að skýra ástandið með tilteknum grunsamlegum þjónustum.
Tökum dæmi. Ímyndum okkur ímyndaða fréttasíðu. Heimasíðaþjónusta (Forsíða) skiptist á gögnum við Redis, með meðmælaþjónustu, við auglýsingaþjónustu og myndbandsþjónustu. Myndbandsþjónustan tekur myndbönd frá S3 og lýsigögn frá DynamoDB. Meðmælaþjónustan tekur við lýsigögnum frá DynamoDB, hleður gögnum frá Redis og MySQL og skrifar skilaboð til Kafka. Auglýsingaþjónustan tekur við gögnum frá MySQL og skrifar skilaboð til Kafka.
Hér að neðan er skýringarmynd af þessari staðfræði (mörg viðskiptaleiðarforrit byggja upp staðfræðina). Það getur verið gagnlegt ef þú þarft að skilja þjónustufíkn. Hins vegar á meðan kemba, þegar ákveðin þjónusta (t.d. myndbandsþjónusta) sýnir aukinn viðbragðstíma er slík staðfræði ekki mjög gagnleg.
Þjónustumynd af ímyndaðri fréttasíðu
Myndin hér að neðan myndi henta betur. Það er vandamál með þjónustuna (myndband) sýnd beint í miðjunni. Notandinn tekur strax eftir því. Af þessari sjónmynd verður ljóst að myndbandsþjónustan starfar óeðlilega vegna aukins S3 viðbragðstíma, sem hefur áhrif á hleðsluhraða hluta aðalsíðunnar.
Kvik svæðisfræði sem sýnir aðeins „áhugaverða“ þjónustu
Kvikmynduð staðfræði getur verið skilvirkari en kyrrstæð þjónustukort, sérstaklega í teygjanlegum innviðum með sjálfvirkri stærðarstærð. Hæfni til að bera saman og andstæða þjónustustórfræði gerir notandanum kleift að spyrja meira viðeigandi spurninga. Nákvæmari spurningar um kerfið eru líklegri til að leiða til betri skilnings á því hvernig kerfið virkar.
Samanburðarskjár
Önnur gagnleg sjónmynd væri samanburðarskjár. Eins og er eru ummerki ekki mjög hentug fyrir hlið við hlið samanburð, svo samanburður er venjulega spannar. Og meginhugmynd þessarar greinar er einmitt sú að spannirnar eru of lágar til að draga verðmætustu upplýsingarnar úr rakningarniðurstöðum.
Að bera saman tvö ummerki krefst ekki í grundvallaratriðum nýjar sjónmyndir. Reyndar nægir eitthvað eins og súlurit sem táknar sömu upplýsingar og rekjaskoðun. Furðu, jafnvel þessi einfalda aðferð getur skilað miklu meiri ávöxtum en einfaldlega að rannsaka tvö ummerki sitt í hvoru lagi. Enn öflugri væri möguleikinn sjá fyrir sér samanburður á ummerkjum Samtals. Það væri afar gagnlegt að sjá hvernig nýlega sett gagnagrunnsstillingarbreyting til að virkja GC (sorpasöfnun) hefur áhrif á viðbragðstíma niðurstreymisþjónustu á nokkrum klukkustundum. Ef það sem ég er að lýsa hér hljómar eins og A/B greining á áhrifum innviðabreytinga í mörgum þjónustum með því að nota rakaniðurstöðurnar, þá ertu ekki of langt frá sannleikanum.
Ályktun
Ég efast ekki um gagnsemi rakningarinnar sjálfrar. Ég trúi því í einlægni að það sé engin önnur aðferð til að safna gögnum eins rík, orsakasamhengi og samhengisbundin og sú sem er að finna í snefil. Hins vegar tel ég líka að allar rakningarlausnir noti þessi gögn á afar óhagkvæman hátt. Svo lengi sem rakningartól eru föst á traceview framsetningunni, munu þau hafa takmarkaða möguleika á að nýta sem mest verðmætar upplýsingar sem hægt er að vinna úr gögnunum sem eru í rekjunum. Auk þess er hætta á að þróa frekar óvingjarnlegt og óviðjafnanlegt sjónviðmót sem mun takmarka verulega möguleika notandans til að leysa villur í forritinu.
Það er ótrúlega erfitt að kemba flókin kerfi, jafnvel með nýjustu verkfærunum. Verkfæri ættu að hjálpa verktaki að móta og prófa tilgátu, að veita virkan viðeigandi upplýsingar, auðkenningu frávika og athugaðu eiginleika í dreifingu tafa. Til þess að rakning verði valkostur fyrir þróunaraðila þegar bilanaleitir í framleiðslu eða leysa vandamál sem spanna margar þjónustur, þarf frumleg notendaviðmót og sjónrænar myndir sem eru í meira samræmi við hugarfar þróunaraðila sem búa til og reka þessa þjónustu.
Það mun taka verulega andlega áreynslu til að hanna kerfi sem mun tákna hin ýmsu merki sem eru tiltæk í rakningarniðurstöðum á þann hátt sem er bjartsýni til að auðvelda greiningu og ályktanir. Þú þarft að hugsa um hvernig á að draga úr kerfissvæðifræði við kembiforrit á þann hátt sem hjálpar notandanum að sigrast á blindum blettum án þess að horfa á einstök ummerki eða span.
Við þurfum góða abstrakt- og lagfæringu (sérstaklega í HÍ). Þeir sem myndu passa vel inn í tilgátu-drifið kembiforrit þar sem þú getur ítrekað spurt spurninga og prófað tilgátur. Þeir munu ekki sjálfkrafa leysa öll vandamál sem hægt er að fylgjast með, en þeir munu hjálpa notendum að skerpa á innsæi sínu og setja fram snjallari spurningar. Ég kalla eftir ígrundaðri og nýstárlegri nálgun við sjónræna mynd. Hér eru raunverulegar líkur á að víkka sjóndeildarhringinn.
PS frá þýðanda
Lestu líka á blogginu okkar:
- «»;
- «»;
- «'.
Heimild: www.habr.com