Poznámka. preklad.: Autorkou tohto materiálu je Cindy Sridharan, inžinierka z imgix, ktorá sa špecializuje na vývoj API a najmä testovanie mikroslužieb. V tomto materiáli zdieľa svoju podrobnú víziu aktuálnych problémov v oblasti distribuovaného sledovania, kde podľa jej názoru chýbajú skutočne efektívne nástroje na riešenie naliehavých problémov.
[Ilustrácia prevzatá z o distribuovanom sledovaní.]
Predpokladá sa, že ťažko realizovateľné a návratnosť . Existuje mnoho dôvodov, prečo je sledovanie problematické, pričom sa často uvádza pracnosť pri konfigurácii každého komponentu systému na prenos príslušných hlavičiek s každou požiadavkou. Aj keď tento problém existuje, v žiadnom prípade nie je neriešiteľný. Mimochodom, nevysvetľuje, prečo vývojári nemajú radi sledovanie (aj keď už funguje).
Hlavnou výzvou pri distribuovanom sledovaní nie je zhromažďovanie údajov, štandardizácia formátov na distribúciu a prezentáciu výsledkov alebo určenie, kedy, kde a ako vzorkovať. neskúšam si to predstavovať triviálne tieto „problémy so zrozumiteľnosťou“ sú v skutočnosti dosť významné technické a (ak uvažujeme skutočne s otvoreným zdrojom) ) politické výzvy, ktoré je potrebné prekonať, aby sa tieto problémy mohli považovať za vyriešené.
Ak si však predstavíme, že všetky tieto problémy sú vyriešené, je veľká pravdepodobnosť, že sa z hľadiska výraznejšieho nič nezmení skúsenosti koncového používateľa. Sledovanie stále nemusí byť praktické v najbežnejších scenároch ladenia – dokonca aj po jeho nasadení.
Taká iná stopa
Distribuované sledovanie zahŕňa niekoľko rôznych komponentov:
- vybavenie aplikácií a middlewaru riadiacimi nástrojmi;
- distribuovaný kontextový prenos;
- zber stôp;
- skladovanie stôp;
- ich extrakcia a vizualizácia.
Veľa sa hovorí o distribuovanom sledovaní má tendenciu považovať ho za druh unárnej operácie, ktorej jediným účelom je pomôcť úplne diagnostikovať systém. Je to do značnej miery spôsobené tým, ako sa historicky formovali myšlienky o distribuovanom sledovaní. IN , vyrobený pri otvorení Zipkinových prameňov, bolo spomenuté, že to [Zipkin] robí Twitter rýchlejším. Boli propagované aj prvé komerčné ponuky na sledovanie .
Poznámka. preklad.: Aby bol ďalší text zrozumiteľnejší, definujme dva základné pojmy podľa :
- Rozsah — základný prvok distribuovaného sledovania. Je to popis určitého pracovného postupu (napríklad databázový dotaz) s názvom, časom začiatku a konca, značkami, protokolmi a kontextom.
- Rozpätia zvyčajne obsahujú odkazy na iné rozpätia, ktoré umožňujú kombinovať viaceré rozpätia stopa — vizualizácia životnosti požiadavky pri jej pohybe cez distribuovaný systém.
Stopy obsahujú neuveriteľne cenné údaje, ktoré môžu pomôcť pri úlohách, ako je testovanie výroby, testovanie obnovy po havárii, testovanie vstrekovania chýb atď. V skutočnosti niektoré spoločnosti už využívajú sledovanie na podobné účely. Začnime s má iné využitie okrem jednoduchého presunu rozpätí do úložného systému:
- Napríklad Uber výsledky sledovania na rozlíšenie medzi testovacou a produkčnou prevádzkou.
- facebook údaje sledovania pre analýzu kritických ciest a pre prepínanie prevádzky počas pravidelných testov obnovy po havárii.
- Aj sociálna sieť Notebooky Jupyter, ktoré umožňujú vývojárom spúšťať ľubovoľné dotazy na výsledky sledovania.
- Nasledovníci (Lineage Driven Failure Injection) distribuované stopy na testovanie s vložením chýb.
Žiadna z vyššie uvedených možností sa úplne nevzťahuje na scenár ladenie, počas ktorej sa inžinier snaží vyriešiť problém pohľadom na stopu.
Keď to príde napriek tomu dosiahne ladiaci skript, primárnym rozhraním zostáva diagram traceview (aj keď niektorí to tiež nazývajú "Ganttov diagram" alebo "vodopádová schéma"). Pod traceview я všetky rozsahy a sprievodné metadáta, ktoré spolu tvoria stopu. Každý systém sledovania s otvoreným zdrojom, ako aj každé komerčné riešenie sledovania ponúka a traceview užívateľské rozhranie na vizualizáciu, detailovanie a filtrovanie stôp.
Problém so všetkými systémami sledovania, ktoré som doteraz videl, je ten, že výsledný vizualizácia (traceview) takmer úplne odráža vlastnosti procesu generovania stopy. Aj keď sú navrhnuté alternatívne vizualizácie: teplotné mapy, topológie služieb, histogramy latencie, stále sa nakoniec traceview.
V minulosti I Zdá sa, že väčšina „inovácií“ sledovania UI/UX je obmedzená na ďalšie metadáta v stope, investovanie do nich informácií s vysokou mohutnosťou (vysoká kardinalita) alebo poskytovanie možnosti hĺbkovej analýzy do konkrétnych rozsahov alebo spúšťania dotazov inter- a intra-trace... Čím traceview zostáva primárnym nástrojom vizualizácie. Pokiaľ bude tento stav pokračovať, distribuované sledovanie bude (v najlepšom prípade) zaujímať 4. miesto ako nástroj na ladenie, po metrikách, protokoloch a stopách zásobníka, a v najhoršom prípade sa ukáže ako strata peňazí a času.
Problém s traceview
osud traceview — poskytnúť úplný obraz o pohybe jednej požiadavky naprieč všetkými komponentmi distribuovaného systému, s ktorým súvisí. Niektoré pokročilejšie systémy sledovania vám umožňujú hĺbkovú analýzu jednotlivých rozsahov a zobrazenie rozpisu v priebehu času vnútri jeden proces (keď majú rozpätia funkčné hranice).
Základným predpokladom architektúry mikroslužieb je myšlienka, že organizačná štruktúra rastie s potrebami spoločnosti. Zástancovia mikroslužieb tvrdia, že distribúcia rôznych obchodných úloh do jednotlivých služieb umožňuje malým autonómnym vývojovým tímom kontrolovať celý životný cyklus takýchto služieb, čo im dáva možnosť tieto služby nezávisle zostavovať, testovať a nasadzovať. Nevýhodou tejto distribúcie je však strata informácií o tom, ako jednotlivé služby interagujú s ostatnými. V takýchto podmienkach sa distribuované sledovanie považuje za nevyhnutný nástroj ladenie komplexné interakcie medzi službami.
Ak naozaj , potom to ani jeden človek nedokáže udržať v hlave kompletný obrázok. V skutočnosti je vývoj nástroja na základe predpokladu, že je to vôbec možné, niečo ako anti-vzorec (neefektívny a neproduktívny prístup). V ideálnom prípade ladenie vyžaduje nástroj, ktorý pomáha zúžiť oblasť vyhľadávania, aby sa inžinieri mohli zamerať na podmnožinu dimenzií (služby/používatelia/hostiteľ atď.), ktoré sú relevantné pre uvažovaný problémový scenár. Pri určovaní príčiny poruchy sa od inžinierov nevyžaduje, aby rozumeli tomu, čo sa stalo počas poruchy všetky služby naraz, pretože takáto požiadavka by bola v rozpore so samotnou myšlienkou architektúry mikroslužieb.
Traceview však áno a to Toto. Áno, niektoré systémy sledovania ponúkajú komprimované zobrazenia sledovania, keď je počet rozsahov v sledovaní taký veľký, že ich nemožno zobraziť v jednej vizualizácii. Avšak kvôli veľkému množstvu informácií obsiahnutých aj v takejto oklieštenej vizualizácii inžinieri stále vynútený „preosiať“, manuálne zúžiť výber na súbor služieb, ktoré sú zdrojom problémov. Bohužiaľ, v tejto oblasti sú stroje oveľa rýchlejšie ako ľudia, menej náchylné na chyby a ich výsledky sú opakovateľnejšie.
Ďalší dôvod, prečo si myslím, že traceview je nesprávny, je ten, že nie je vhodný na ladenie založené na hypotézach. Jadrom je ladenie iteratívny proces začínajúci hypotézou, po ktorom nasleduje overenie rôznych pozorovaní a faktov získaných zo systému pozdĺž rôznych vektorov, závery/zovšeobecnenia a ďalšie posúdenie pravdivosti hypotézy.
Príležitosť rýchlo a lacno testovanie hypotéz a zodpovedajúce zlepšovanie mentálneho modelu základným kameňom ladenie Akýkoľvek nástroj na ladenie by mal byť interaktívne a zúžiť priestor vyhľadávania alebo v prípade falošného potenciálu umožniť používateľovi vrátiť sa späť a zamerať sa na inú oblasť systému. Perfektný nástroj to urobí proaktívne, okamžite upozorní používateľa na potenciálne problémové oblasti.
žiaľ, traceview nemožno nazvať nástrojom s interaktívnym rozhraním. Najlepšie, v čo môžete pri jeho používaní dúfať, je nájsť nejaký zdroj zvýšenej latencie a pozrieť sa na všetky možné značky a protokoly, ktoré sú s tým spojené. To nepomôže inžinierovi identifikovať vzory v prevádzke, ako sú špecifiká distribúcie oneskorenia, alebo zistiť korelácie medzi rôznymi meraniami. môže pomôcť vyriešiť niektoré z týchto problémov. naozaj, úspešnú analýzu pomocou strojového učenia na identifikáciu anomálnych rozsahov a identifikáciu podmnožiny značiek, ktoré môžu byť spojené s anomálnym správaním. Ešte som však nevidel presvedčivé vizualizácie zistení strojového učenia alebo dolovania údajov aplikovaných na rozpätia, ktoré sa výrazne líšia od traceview alebo DAG (riadený acyklický graf).
Rozpätia sú príliš nízke
Základným problémom traceview je to rozpätia sú primitívy príliš nízkej úrovne pre analýzu latencie aj analýzu základnej príčiny. Je to ako analyzovať jednotlivé príkazy procesora, aby ste sa pokúsili vyriešiť výnimku, s vedomím, že existujú nástroje na oveľa vyššej úrovni, ako napríklad backtrace, s ktorými je oveľa pohodlnejšie pracovať.
Navyše si dovolím tvrdiť nasledovné: v ideálnom prípade nepotrebujeme úplný obrázok došlo počas životného cyklu požiadavky, ktorý predstavujú moderné nástroje sledovania. Namiesto toho sa vyžaduje určitá forma abstrakcie vyššej úrovne, ktorá obsahuje informácie o čom sa pokazilo (podobne ako backtrace), spolu s určitým kontextom. Namiesto sledovania celej stopy ju radšej vidím часть, kde sa deje niečo zaujímavé alebo nezvyčajné. V súčasnosti sa vyhľadávanie vykonáva manuálne: inžinier dostane stopu a nezávisle analyzuje rozpätia pri hľadaní niečoho zaujímavého. Prístup ľudí, ktorí hľadia na rozpätia jednotlivých stôp v nádeji, že zistia podozrivú aktivitu, sa vôbec neškáluje (najmä keď musia pochopiť všetky metadáta zakódované v rôznych rozpätiach, ako je ID rozpätia, názov metódy RPC, trvanie rozpätia). „a, denníky, štítky atď.).
Alternatívy k traceview
Výsledky sledovania sú najužitočnejšie, keď sa dajú vizualizovať spôsobom, ktorý poskytuje netriviálny pohľad na to, čo sa deje v prepojených častiach systému. Kým sa tak nestane, proces ladenia z veľkej časti zostáva inertný a závisí od schopnosti používateľa všimnúť si správne korelácie, skontrolovať správne časti systému alebo poskladať kúsky skladačky – na rozdiel od náradie, ktoré pomáhajú používateľovi formulovať tieto hypotézy.
Nie som vizuálny dizajnér ani UX špecialista, ale v ďalšej časti sa chcem podeliť o pár nápadov, ako by tieto vizualizácie mohli vyzerať.
Zamerajte sa na konkrétne služby
V čase, keď sa priemysel konsoliduje okolo nápadov Zdá sa rozumné, že jednotlivé tímy by mali uprednostniť zabezpečenie súladu ich služieb s týmito cieľmi. Z toho vyplýva orientované na služby Pre takéto tímy je najvhodnejšia vizualizácia.
Stopy, najmä bez vzorkovania, sú pokladnicou informácií o každom komponente distribuovaného systému. Tieto informácie môžu byť odovzdané prefíkanému procesoru, ktorý bude zásobovať používateľov orientované na služby Dajú sa identifikovať vopred – ešte predtým, ako sa používateľ pozrie na stopy:
- Diagramy distribúcie latencie len pre veľmi významné požiadavky (extrémne požiadavky);
- Diagramy distribúcie oneskorenia pre prípady, keď sa nedosiahnu ciele služby SLO;
- Najčastejšie „bežné“, „zaujímavé“ a „čudné“ značky v dopytoch sa opakujú;
- Rozdelenie latencie pre prípady, keď v závislosti na služby nedosahujú svoje ciele SLO;
- Rozdelenie latencie pre rôzne nadväzujúce služby.
Na niektoré z týchto otázok jednoducho neodpovedajú vstavané metriky, čo núti používateľov kontrolovať rozpätia. V dôsledku toho máme mechanizmus extrémne nepriateľský voči používateľom.
To vyvoláva otázku: čo so zložitými interakciami medzi rôznymi službami riadenými rôznymi tímami? Nie? traceview nepovažuje za najvhodnejší nástroj na zvýraznenie takejto situácie?
Mobilných vývojárov, vlastníkov bezstavových služieb, vlastníkov spravovaných stavových služieb (ako sú databázy) a vlastníkov platforiem môže zaujímať niečo iné prezentácia distribuovaný systém; traceview je príliš všeobecné riešenie pre tieto zásadne odlišné potreby. Dokonca aj vo veľmi komplexnej architektúre mikroslužieb nepotrebujú vlastníci služieb hlboké znalosti o viac ako dvoch alebo troch upstream a downstream službách. V podstate vo väčšine scenárov musia používatelia odpovedať iba na otázky týkajúce sa obmedzený súbor služieb.
Je to ako pozerať sa na malú podskupinu služieb cez lupu, aby ste si ju dôkladne prezreli. To umožní používateľovi klásť naliehavejšie otázky týkajúce sa komplexných interakcií medzi týmito službami a ich bezprostrednými závislosťami. Je to podobné ako spätné sledovanie vo svete služieb, kde to inžinier vie že nesprávne a tiež má určité porozumenie tomu, čo sa deje v okolitých službách prečo.
Prístup, ktorý presadzujem, je presným opakom prístupu zhora nadol, založeného na traceview, kde analýza začína celým priebehom a potom postupne prechádza k jednotlivým rozsahom. Na rozdiel od toho, prístup zdola nahor začína analýzou malej oblasti blízko potenciálnej príčiny incidentu a potom podľa potreby rozširuje priestor vyhľadávania (s potenciálom priviesť ďalšie tímy na analýzu širšieho spektra služieb). Druhý prístup je vhodnejší na rýchle testovanie počiatočných hypotéz. Po získaní konkrétnych výsledkov bude možné prejsť k cielenejšej a podrobnejšej analýze.
Budovanie topológie
Pohľady špecifické pre službu môžu byť neuveriteľne užitočné, ak to používateľ vie ktorý služba alebo skupina služieb je zodpovedná za zvýšenie latencie alebo za spôsobenie chýb. V zložitom systéme však môže byť identifikácia problematickej služby počas zlyhania netriviálnou úlohou, najmä ak služby nehlásili žiadne chybové hlásenia.
Vybudovanie topológie služby môže byť veľkou pomocou pri zisťovaní, ktorá služba zaznamenáva prudký nárast chybovosti alebo zvýšenie latencie, ktoré spôsobuje výrazné zhoršenie služby. Keď hovorím o budovaní topológie, nemám na mysli mapa služieb, zobrazujúci všetky služby dostupné v systéme a známe tým . Tento pohľad nie je o nič lepší ako traceview na základe orientovaného acyklického grafu. Namiesto toho by som chcel vidieť dynamicky generovaná topológia služieb, na základe určitých atribútov, ako je chybovosť, čas odozvy alebo akýkoľvek užívateľom definovaný parameter, ktorý pomáha objasniť situáciu s konkrétnymi podozrivými službami.
Vezmime si príklad. Predstavme si hypotetický spravodajský web. Služba domovskej stránky (predná strana) vymieňa si údaje s Redis, s odporúčacou službou, s reklamnou službou a video službou. Video služba preberá videá z S3 a metadáta z DynamoDB. Služba odporúčaní prijíma metadáta z DynamoDB, načítava údaje z Redis a MySQL a zapisuje správy do Kafka. Reklamná služba prijíma dáta z MySQL a píše správy Kafkovi.
Nižšie je schematické znázornenie tejto topológie (topológiu vytvára veľa komerčných smerovacích programov). Môže to byť užitočné, ak potrebujete pochopiť závislosti služieb. Avšak počas ladenie, keď určitá služba (povedzme video služba) vykazuje zvýšený čas odozvy, takáto topológia nie je veľmi užitočná.
Servisný diagram hypotetického spravodajského webu
Nižšie uvedený diagram by bol vhodnejší. Vyskytol sa problém so službou (Video) zobrazené priamo v strede. Používateľ si to okamžite všimne. Z tejto vizualizácie je zrejmé, že video služba funguje abnormálne v dôsledku predĺženia času odozvy S3, čo ovplyvňuje rýchlosť načítania časti hlavnej stránky.
Dynamická topológia zobrazujúca len „zaujímavé“ služby
Dynamicky generované topológie môžu byť efektívnejšie ako statické mapy služieb, najmä v elastických infraštruktúrach s automatickým škálovaním. Schopnosť porovnávať a porovnávať topológie služieb umožňuje užívateľovi klásť relevantnejšie otázky. Presnejšie otázky o systéme s väčšou pravdepodobnosťou povedú k lepšiemu pochopeniu toho, ako systém funguje.
Porovnávacie zobrazenie
Ďalšou užitočnou vizualizáciou by bolo porovnávacie zobrazenie. V súčasnosti nie sú stopy veľmi vhodné na porovnávanie vedľa seba, takže porovnávania zvyčajne sú rozpätia. A hlavnou myšlienkou tohto článku je presne to, že rozpätia sú príliš nízke na to, aby z výsledkov sledovania získali najcennejšie informácie.
Porovnanie dvoch stôp si nevyžaduje zásadne nové vizualizácie. V skutočnosti postačuje niečo ako histogram predstavujúci rovnakú informáciu ako traceview. Prekvapivo, aj táto jednoduchá metóda môže priniesť oveľa viac ovocia, ako jednoduché štúdium dvoch stôp oddelene. Ešte silnejšia by bola možnosť vizualizovať porovnanie stôp Spolu. Bolo by mimoriadne užitočné vidieť, ako nedávno nasadená zmena konfigurácie databázy s cieľom umožniť GC (zber odpadu) ovplyvňuje čas odozvy nadväzujúcej služby v rozsahu niekoľkých hodín. Ak to, čo tu popisujem, znie ako A/B analýza vplyvu zmien infraštruktúry v mnohých službách pomocou výsledkov sledovania potom nie ste príliš ďaleko od pravdy.
Záver
Nespochybňujem užitočnosť samotného sledovania. Úprimne verím, že neexistuje žiadna iná metóda na zhromažďovanie údajov tak bohatých, kauzálnych a kontextových ako tie, ktoré sú obsiahnuté v stope. Som však tiež presvedčený, že všetky riešenia sledovania využívajú tieto údaje mimoriadne neefektívne. Pokiaľ nástroje sledovania zostanú uviaznuté na reprezentácii sledovania, budú obmedzené vo svojej schopnosti čo najlepšie využiť cenné informácie, ktoré možno extrahovať z údajov obsiahnutých v stopách. Okrem toho existuje riziko ďalšieho vývoja úplne neprívetivého a neintuitívneho vizuálneho rozhrania, ktoré výrazne obmedzí možnosti používateľa odstraňovať chyby v aplikácii.
Ladenie zložitých systémov, dokonca aj pomocou najnovších nástrojov, je neskutočne ťažké. Nástroje by mali pomôcť vývojárovi formulovať a testovať hypotézu, aktívne poskytovať relevantné informácie, identifikovanie odľahlých hodnôt a zaznamenanie prvkov v distribúcii oneskorení. Aby sa sledovanie stalo nástrojom voľby vývojárov pri odstraňovaní zlyhaní výroby alebo riešení problémov, ktoré zahŕňajú viacero služieb, sú potrebné originálne používateľské rozhrania a vizualizácie, ktoré sú viac v súlade s mentálnym modelom vývojárov, ktorí tieto služby vytvárajú a prevádzkujú.
Bude si vyžadovať značné duševné úsilie navrhnúť systém, ktorý bude reprezentovať rôzne signály dostupné vo výsledkoch sledovania spôsobom, ktorý je optimalizovaný pre jednoduchú analýzu a odvodenie. Musíte premýšľať o tom, ako abstrahovať topológiu systému počas ladenia spôsobom, ktorý pomôže používateľovi prekonať slepé miesta bez toho, aby sa pozrel na jednotlivé stopy alebo rozpätia.
Potrebujeme dobré možnosti abstrakcie a vrstvenia (najmä v používateľskom rozhraní). Také, ktoré by sa hodili do procesu ladenia založeného na hypotézach, kde môžete opakovane klásť otázky a testovať hypotézy. Nevyriešia automaticky všetky problémy s pozorovateľnosťou, ale pomôžu používateľom zdokonaliť svoju intuíciu a formulovať inteligentnejšie otázky. Vyzývam na premyslenejší a inovatívnejší prístup k vizualizácii. Je tu reálna perspektíva rozšíriť obzory.
PS od prekladateľa
Prečítajte si aj na našom blogu:
- «»;
- «»;
- «".
Zdroj: hab.com