Opomba. prevod: Avtorica tega gradiva je Cindy Sridharan, inženirka pri imgixu, ki je specializirana za razvoj API-jev in še posebej za testiranje mikrostoritev. V tem gradivu deli svojo podrobno vizijo trenutnih problemov na področju porazdeljenega sledenja, kjer po njenem mnenju primanjkuje resnično učinkovitih orodij za reševanje perečih problemov.
[Ilustracija povzeta po o porazdeljenem sledenju.]
Menijo, da je težko izvedljivo in donos . Obstaja veliko razlogov, zakaj je sledenje problematično, pogosto navajajo delo, vključeno v konfiguracijo vsake sistemske komponente za prenos ustreznih glav z vsako zahtevo. Čeprav ta težava obstaja, nikakor ni nerešljiva. Mimogrede, to ne pojasni, zakaj razvijalci ne marajo sledenja (tudi ko že deluje).
Glavni izziv pri porazdeljenem sledenju ni zbiranje podatkov, standardizacija formatov za distribucijo in predstavitev rezultatov ali določanje, kdaj, kje in kako vzorčiti. Ne poskušam si predstavljati trivialno te "težave z razumljivostjo" so v resnici precejšnje tehnične in (če razmišljamo o resnično odprtokodni) ) politične izzive, ki jih je treba premagati, da se ti problemi štejejo za rešene.
Če pa si predstavljamo, da so vsi ti problemi rešeni, obstaja velika verjetnost, da se glede izkušnjo končnega uporabnika. Sledenje morda še vedno ni praktično uporabno v najpogostejših scenarijih odpravljanja napak – tudi potem, ko je že uvedeno.
Tako drugačna sled
Porazdeljeno sledenje vključuje več različnih komponent:
- opremljanje aplikacij in vmesne programske opreme z nadzornimi orodji;
- prenos porazdeljenega konteksta;
- zbiranje sledi;
- shranjevanje sledi;
- njihovo ekstrakcijo in vizualizacijo.
Veliko govora o porazdeljenem sledenju se nagiba k temu, da ga obravnavajo kot nekakšno enolično operacijo, katere edini namen je pomagati pri popolni diagnostiki sistema. To je v veliki meri posledica tega, kako so se zgodovinsko oblikovale ideje o porazdeljenem sledenju. IN , narejeno ob odprtju virov Zipkin, je bilo omenjeno, da to [Zipkin] naredi Twitter hitrejši. Prve komercialne ponudbe za sledenje so bile promovirane tudi kot .
Opomba. prevod: Za lažje razumevanje nadaljnjega besedila opredelimo dva osnovna pojma glede na :
- Razpon — osnovni element porazdeljenega sledenja. Je opis določenega poteka dela (na primer poizvedbe po zbirki podatkov) z imenom, začetnim in končnim časom, oznakami, dnevniki in kontekstom.
- Razponi običajno vsebujejo povezave do drugih razponov, kar omogoča združevanje več razponov Trace — vizualizacija življenjske dobe zahteve med premikanjem po porazdeljenem sistemu.
Sledi vsebujejo neverjetno dragocene podatke, ki lahko pomagajo pri nalogah, kot so testiranje proizvodnje, testiranje obnovitve po katastrofi, testiranje vbrizgavanja napak itd. Pravzaprav nekatera podjetja že uporabljajo sledenje za podobne namene. Začnimo z ima še druge namene poleg preprostega premikanja razponov v sistem za shranjevanje:
- Na primer Uber rezultate sledenja za razlikovanje med testnim in proizvodnim prometom.
- Facebook podatki o sledenju za analizo kritične poti in za preklapljanje prometa med rednimi preskusi obnovitve po katastrofi.
- Tudi socialno omrežje Prenosni računalniki Jupyter, ki razvijalcem omogočajo izvajanje poljubnih poizvedb o rezultatih sledenja.
- Sledilci (Lineage Driven Failure Injection) porazdeljene sledi za testiranje z vbrizgavanjem napak.
Nobena od zgoraj navedenih možnosti v celoti ne velja za scenarij odpravljanje napak, med katerim inženir poskuša rešiti problem s pogledom na sled.
Ko pride še doseže skript za odpravljanje napak, primarni vmesnik ostane diagram traceview (čeprav ga nekateri imenujejo tudi "Gantogram" ali "diagram slapa"). Spodaj traceview я vse razpone in spremljajoče metapodatke, ki skupaj sestavljajo sled. Vsak odprtokodni sistem sledenja, pa tudi vsaka komercialna rešitev sledenja, ponuja a traceview uporabniški vmesnik za vizualizacijo, detajliranje in filtriranje sledi.
Težava z vsemi sistemi sledenja, ki sem jih videl do sedaj, je, da rezultat vizualizacija (traceview) skoraj v celoti odraža značilnosti procesa generiranja sledi. Tudi ko so predlagane alternativne vizualizacije: toplotni zemljevidi, topologije storitev, histogrami zakasnitev, se na koncu še vedno zmanjšajo na traceview.
V preteklosti sem na katere se zdi, da je večina "inovacij" pri sledenju uporabniškega vmesnika/uporabne izkušnje omejena dodatne metapodatke v sledenju in vanje vloži informacije z visoko kardinalnostjo (visoka kardinalnost) ali zagotavljanje zmožnosti vrtanja v določene razpone ali izvajanja poizvedb inter- in intra-sled... Kamor traceview ostaja glavno vizualizacijsko orodje. Dokler se bo takšno stanje nadaljevalo, bo porazdeljeno sledenje (v najboljšem primeru) zasedlo 4. mesto kot orodje za odpravljanje napak, za metrikami, dnevniki in sledenjem skladov, v najslabšem primeru pa se bo izkazalo za potrato denarja in časa.
Težava s traceviewom
Namen traceview — zagotoviti popolno sliko gibanja ene same zahteve po vseh komponentah porazdeljenega sistema, s katerim je povezana. Nekateri naprednejši sistemi sledenja vam omogočajo, da se poglobite v posamezne razpone in si ogledate razčlenitev skozi čas znotraj en proces (ko imajo razponi funkcionalne meje).
Osnovno izhodišče arhitekture mikrostoritev je ideja, da organizacijska struktura raste s potrebami podjetja. Zagovorniki mikrostoritev trdijo, da porazdelitev različnih poslovnih nalog v posamezne storitve omogoča majhnim, avtonomnim razvojnim skupinam, da nadzorujejo celoten življenjski cikel takih storitev, kar jim daje možnost neodvisne gradnje, testiranja in uvajanja teh storitev. Vendar pa je pomanjkljivost te distribucije izguba informacij o tem, kako posamezna storitev sodeluje z drugimi. V takšnih razmerah se porazdeljeno sledenje trdi, da je nepogrešljivo orodje za odpravljanje napak kompleksne interakcije med storitvami.
Če res , potem tega noben človek ne more obdržati v glavi popolna slika. Pravzaprav je razvoj orodja, ki temelji na predpostavki, da je to sploh mogoče, nekakšen anti-vzorec (neučinkovit in neproduktiven pristop). V idealnem primeru je za odpravljanje napak potrebno orodje, ki pomaga zožite območje iskanja, tako da se inženirji lahko osredotočijo na podmnožico dimenzij (storitve/uporabniki/gostitelji itd.), ki so pomembne za obravnavani problemski scenarij. Pri ugotavljanju vzroka okvare inženirjem ni treba razumeti, kaj se je zgodilo med vse storitve naenkrat, saj bi bila takšna zahteva v nasprotju s samo idejo arhitekture mikrostoritev.
Vendar traceview je in sicer to. Da, nekateri sistemi sledenja ponujajo stisnjene poglede sledenja, ko je število razponov v sledenju tako veliko, da jih ni mogoče prikazati v eni vizualizaciji. Vendar pa inženirji zaradi velike količine informacij, ki jih vsebuje tudi tako okrnjena vizualizacija, še vedno prisilno »presejati« in ročno zožiti izbor na niz storitev, ki so viri težav. Žal so na tem področju stroji veliko hitrejši od ljudi, manj nagnjeni k napakam, njihovi rezultati pa so bolj ponovljivi.
Drugi razlog, zakaj menim, da je traceview napačen, je, ker ni dober za odpravljanje napak na podlagi hipotez. V svojem bistvu je odpravljanje napak iterativno proces, ki se začne s hipotezo, sledi preverjanje različnih opažanj in dejstev, pridobljenih iz sistema po različnih vektorjih, zaključki/generalizacije in nadaljnja ocena resničnosti hipoteze.
Priložnost hitro in poceni testiranje hipotez in ustrezno izboljšanje mentalnega modela temeljni kamen odpravljanje napak Vsako orodje za odpravljanje napak mora biti interaktivni in zožiti iskalni prostor ali, v primeru lažnega namiga, omogočiti uporabniku, da se vrne nazaj in se osredotoči na drugo področje sistema. Popolno orodje bo to naredilo proaktivno, ki takoj pritegne pozornost uporabnika na morebitna problematična področja.
žal traceview ni mogoče imenovati orodje z interaktivnim vmesnikom. Najboljše, na kar lahko upate, ko ga uporabljate, je, da poiščete vir povečane zakasnitve in si ogledate vse možne oznake in dnevnike, povezane z njim. To inženirju ne pomaga prepoznati vzorci v prometu, kot so posebnosti porazdelitve zamud, ali zaznati korelacije med različnimi meritvami. lahko pomaga obiti nekatere od teh težav. res, uspešna analiza z uporabo strojnega učenja za identifikacijo nenormalnih razponov in identifikacijo podmnožice oznak, ki so lahko povezane z nepravilnim vedenjem. Vendar pa še nisem videl prepričljivih vizualizacij strojnega učenja ali ugotovitev podatkovnega rudarjenja, uporabljenih za razpone, ki se bistveno razlikujejo od traceviewa ali DAG (usmerjenega acikličnega grafa).
Razponi so prenizki
Temeljna težava traceviewa je ta razponi so primitivi prenizke ravni tako za analizo zakasnitve kot za analizo temeljnega vzroka. To je kot razčlenjevanje ukazov posameznega procesorja, da bi poskušali razrešiti izjemo, saj veste, da obstajajo orodja na višji ravni, kot je povratna sled, s katerimi je veliko bolj priročno delati.
Poleg tega si bom dovolil zatrditi naslednje: v idealnem primeru ne potrebujemo polna slika prišlo med življenjskim ciklom zahteve, ki ga predstavljajo sodobna orodja za sledenje. Namesto tega je potrebna neka oblika abstrakcije na višji ravni, ki vsebuje informacije o tem, kaj je šlo narobe (podobno povratnemu sledenju), skupaj z nekaj konteksta. Namesto da bi gledal celotno sled, jo raje vidim часть, kjer se dogaja kaj zanimivega ali nenavadnega. Trenutno iskanje poteka ročno: inženir prejme sled in samostojno analizira razpone v iskanju nečesa zanimivega. Pristop ljudi, ki strmijo v razpone v posameznih sledovih v upanju, da bodo odkrili sumljivo dejavnost, sploh ni skaliran (zlasti ko morajo razumeti vse metapodatke, kodirane v različnih razponih, kot so ID razpona, ime metode RPC, trajanje razpona 'a, dnevniki, oznake itd.).
Alternative za traceview
Rezultati sledenja so najbolj uporabni, če jih je mogoče vizualizirati na način, ki zagotavlja netrivialen vpogled v dogajanje v medsebojno povezanih delih sistema. Dokler se to ne zgodi, se postopek odpravljanja napak večinoma nadaljuje inerten in je odvisen od uporabnikove sposobnosti, da opazi prave korelacije, preveri prave dele sistema ali sestavi koščke sestavljanke – v nasprotju z orodje, ki uporabniku pomaga oblikovati te hipoteze.
Nisem vizualni oblikovalec ali strokovnjak za UX, vendar želim v naslednjem razdelku deliti nekaj zamisli o tem, kako bi te vizualizacije lahko izgledale.
Osredotočite se na posebne storitve
V času, ko se industrija konsolidira okoli idej , se zdi razumno, da bi morale posamezne ekipe dati prednost zagotavljanju, da so njihove storitve usklajene s temi cilji. Sledi, da storitveno usmerjeni vizualizacija je najbolj primerna za takšne ekipe.
Sledi, zlasti brez vzorčenja, so zakladnica informacij o vsaki komponenti porazdeljenega sistema. Te informacije se lahko vnesejo v zvit procesor, ki bo oskrboval uporabnike storitveno usmerjeni Prepoznati jih je mogoče vnaprej – še preden uporabnik pogleda sledi:
- Diagrami porazdelitve zakasnitev samo za zelo izrazite zahteve (izjemne zahteve);
- Diagrami porazdelitve zakasnitve za primere, ko servisni SLO cilji niso doseženi;
- Najbolj »pogoste«, »zanimive« in »čudne« oznake v poizvedbah, ki najpogosteje se ponavljajo;
- Razčlenitev latence za primere, ko odvisnost storitve ne dosegajo svojih SLO ciljev;
- Razčlenitev zakasnitve za različne storitve na nižji stopnji.
Na nekatera od teh vprašanj preprosto ne odgovorijo vgrajene metrike, zaradi česar so uporabniki prisiljeni natančno preučiti razpone. Posledično imamo do uporabnika izjemno sovražen mehanizem.
To postavlja vprašanje: kaj pa zapletene interakcije med različnimi storitvami, ki jih nadzorujejo različne ekipe? Ali ne? traceview ne velja za najprimernejše orodje za poudarjanje takšne situacije?
Mobilne razvijalce, lastnike storitev brez stanja, lastnike upravljanih storitev s stanjem (kot so baze podatkov) in lastnike platform bo morda zanimalo nekaj drugega predstavitev porazdeljeni sistem; traceview je preveč splošna rešitev za te bistveno različne potrebe. Celo v zelo zapleteni arhitekturi mikrostoritev lastniki storitev ne potrebujejo poglobljenega znanja o več kot dveh ali treh storitvah navzgor in navzdol. V bistvu morajo uporabniki v večini primerov odgovoriti le na vprašanja o omejen nabor storitev.
To je tako, kot če bi majhno podmnožico storitev gledali skozi povečevalno steklo, da bi jo natančno pregledali. To bo uporabniku omogočilo zastavljanje bolj perečih vprašanj v zvezi s kompleksnimi interakcijami med temi storitvami in njihovimi neposrednimi odvisnostmi. To je podobno povratnemu sledenju v svetu storitev, kjer inženir ve da narobe, in ima tudi nekaj razumevanja, kaj se dogaja v okoliških storitvah za razumevanje zakaj.
Pristop, ki ga spodbujam, je pravo nasprotje pristopa od zgoraj navzdol, ki temelji na traceviewu, kjer se analiza začne s celotno sledjo in se nato postopoma spusti do posameznih razponov. V nasprotju s tem se pristop od spodaj navzgor začne z analizo majhnega območja blizu možnega vzroka incidenta in nato po potrebi razširi prostor iskanja (z možnostjo vključitve drugih skupin za analizo širšega nabora storitev). Drugi pristop je bolj primeren za hitro testiranje začetnih hipotez. Ko bodo pridobljeni konkretni rezultati, bo mogoče preiti na bolj ciljno in podrobno analizo.
Gradnja topologije
Pogledi, specifični za storitev, so lahko izjemno uporabni, če uporabnik ve kaj storitev ali skupina storitev je odgovorna za povečanje zakasnitve ali povzročanje napak. Vendar pa je v zapletenem sistemu prepoznavanje kršitvene storitve med napako lahko nepomembna naloga, zlasti če storitve niso sporočile sporočil o napakah.
Izgradnja topologije storitve je lahko v veliko pomoč pri ugotavljanju, pri kateri storitvi se pojavlja skokovito povečanje stopnje napak ali povečanje zakasnitve, zaradi česar se storitev opazno poslabša. Ko govorim o gradnji topologije, ne mislim zemljevid storitev, ki prikazuje vse storitve, ki so na voljo v sistemu in so znane po svojih . Ta pogled ni nič boljši od traceviewa, ki temelji na usmerjenem acikličnem grafu. Namesto tega bi rad videl dinamično generirana storitvena topologija, ki temelji na določenih atributih, kot so stopnja napak, odzivni čas ali kateri koli uporabniško določen parameter, ki pomaga razjasniti situacijo s posebnimi sumljivimi storitvami.
Vzemimo primer. Predstavljajmo si hipotetično spletno stran z novicami. Storitev domače strani (prednja stran) izmenjuje podatke z Redisom, s storitvijo priporočil, z oglaševalsko storitvijo in video storitvijo. Video storitev zajema videoposnetke iz S3 in metapodatke iz DynamoDB. Priporočilna storitev prejema metapodatke iz DynamoDB, nalaga podatke iz Redisa in MySQL ter piše sporočila Kafki. Oglaševalska storitev prejema podatke iz MySQL in piše sporočila Kafki.
Spodaj je shematski prikaz te topologije (številni komercialni programi za usmerjanje gradijo topologijo). Lahko je koristno, če morate razumeti odvisnosti storitev. Vendar pa med odpravljanje napak, ko ima določena storitev (recimo video storitev) povečan odzivni čas, taka topologija ni zelo uporabna.
Diagram storitev hipotetičnega mesta z novicami
Spodnji diagram bi bil bolj primeren. Prišlo je do težave s storitvijo (videoposnetek) upodobljen čisto v sredini. Uporabnik to takoj opazi. Iz te vizualizacije postane jasno, da video storitev ne deluje normalno zaradi podaljšanja odzivnega časa S3, kar vpliva na hitrost nalaganja dela glavne strani.
Dinamična topologija, ki prikazuje samo »zanimive« storitve
Dinamično ustvarjene topologije so lahko učinkovitejše od statičnih zemljevidov storitev, zlasti v elastičnih infrastrukturah s samodejnim skaliranjem. Zmožnost primerjave in primerjave topologij storitev omogoča uporabniku, da postavlja bolj pomembna vprašanja. Natančnejša vprašanja o sistemu bodo bolj verjetno vodila k boljšemu razumevanju delovanja sistema.
Primerjalni prikaz
Druga koristna vizualizacija bi bil primerjalni prikaz. Sledi trenutno niso zelo primerne za vzporedne primerjave, zato so primerjave običajno razponi. In glavna ideja tega članka je prav ta, da so razponi prenizki, da bi iz rezultatov sledenja izluščili najdragocenejše informacije.
Primerjava dveh sledi ne zahteva bistveno novih vizualizacij. Pravzaprav zadostuje nekaj podobnega histogramu, ki predstavlja iste informacije kot ogled sledi. Presenetljivo je, da lahko celo ta preprosta metoda prinese veliko več sadov kot preprosto preučevanje dveh sledi ločeno. Še močnejša bi bila možnost vizualizirati primerjava sledi Skupaj. Izjemno koristno bi bilo videti, kako nedavno uvedena sprememba konfiguracije baze podatkov za omogočanje GC (zbiranje smeti) vpliva na odzivni čas nižje storitve v obsegu nekaj ur. Če to, kar tukaj opisujem, zveni kot A/B analiza vpliva infrastrukturnih sprememb v številnih storitvah z uporabo rezultatov sledenja, potem niste preveč daleč od resnice.
Zaključek
Ne dvomim o uporabnosti samega sledenja. Iskreno verjamem, da ni druge metode za zbiranje podatkov, ki je tako bogata, vzročna in kontekstualna, kot je tista, ki jo vsebuje sled. Vendar pa tudi menim, da vse rešitve sledenja uporabljajo te podatke izjemno neučinkovito. Dokler bodo orodja za sledenje obtičala na predstavitvi pogleda sledenja, bodo omejena v svoji zmožnosti, da kar najbolje izkoristijo dragocene informacije, ki jih je mogoče izluščiti iz podatkov, ki jih vsebujejo sledi. Poleg tega obstaja nevarnost nadaljnjega razvoja popolnoma neprijaznega in neintuitivnega vizualnega vmesnika, ki bo močno omejil uporabnikovo sposobnost odpravljanja napak v aplikaciji.
Odpravljanje napak v kompleksnih sistemih, tudi z najnovejšimi orodji, je neverjetno težko. Orodja morajo razvijalcu pomagati oblikovati in preizkusiti hipotezo, aktivno zagotavljanje ustrezne informacije, prepoznavanje izstopajočih vrednosti in opazovanje značilnosti v porazdelitvi zamud. Da bi sledenje postalo izbrano orodje za razvijalce pri odpravljanju napak v proizvodnji ali reševanju težav, ki zajemajo več storitev, so potrebni izvirni uporabniški vmesniki in vizualizacije, ki so bolj skladni z miselnim modelom razvijalcev, ki ustvarjajo in upravljajo te storitve.
Za načrtovanje sistema, ki bo predstavljal različne signale, ki so na voljo v rezultatih sledenja, na način, ki je optimiziran za lažjo analizo in sklepanje, bo potreben velik mentalni napor. Razmisliti morate o tem, kako abstrahirati sistemsko topologijo med odpravljanjem napak na način, ki uporabniku pomaga premagati slepe pege, ne da bi gledal posamezne sledi ali razpone.
Potrebujemo dobre zmožnosti abstrakcije in plastenja (zlasti v uporabniškem vmesniku). Takšni, ki bi se dobro ujemali s postopkom odpravljanja napak, ki temelji na hipotezah, kjer lahko iterativno postavljate vprašanja in preizkušate hipoteze. Ne bodo samodejno rešili vseh težav z opazljivostjo, bodo pa uporabnikom pomagali izostriti njihovo intuicijo in oblikovati pametnejša vprašanja. Pozivam k bolj premišljenemu in inovativnemu pristopu k vizualizaciji. Tu obstaja resnična možnost za širjenje obzorij.
PS od prevajalca
Preberite tudi na našem blogu:
- «»;
- «»;
- «".
Vir: www.habr.com