Poznámka. přel.: Autorkou tohoto materiálu je Cindy Sridharan, inženýrka z imgix, která se specializuje na vývoj API a zejména na testování mikroslužeb. V tomto materiálu sdílí svou podrobnou vizi aktuálních problémů v oblasti distribuovaného sledování, kde podle ní chybí skutečně efektivní nástroje pro řešení naléhavých problémů.
[Ilustrace převzata z o distribuovaném sledování.]
Předpokládá se, že obtížné realizovat a návratnost . Existuje mnoho důvodů, proč je trasování problematické, přičemž se často uvádí pracnost spojená s konfigurací každé systémové komponenty pro přenos příslušných hlaviček s každým požadavkem. I když tento problém existuje, není v žádném případě nepřekonatelný. Mimochodem, nevysvětluje to, proč vývojáři ve skutečnosti nemají rádi sledování (i když už funguje).
Hlavním problémem distribuovaného sledování není sběr dat, standardizace formátů pro distribuci a prezentaci výsledků nebo určování, kdy, kde a jak vzorkovat. Nesnažím se si to představovat triviální tyto „problémy se srozumitelností“ jsou ve skutečnosti poměrně značné technické a (pokud uvažujeme skutečně Open Source) ) politické výzvy, které je třeba překonat, aby mohly být tyto problémy považovány za vyřešené.
Pokud si však představíme, že všechny tyto problémy jsou vyřešeny, je velká pravděpodobnost, že se na tom nic výrazněji nezmění zkušenost koncového uživatele. Trasování stále nemusí mít praktické využití v nejběžnějších scénářích ladění – dokonce i po jeho nasazení.
Taková jiná stopa
Distribuované trasování zahrnuje několik různých komponent:
- vybavení aplikací a middlewaru ovládacími nástroji;
- distribuovaný přenos kontextu;
- sběr stop;
- ukládání stop;
- jejich extrakce a vizualizace.
Mnoho řečí o distribuovaném sledování má tendenci k tomu přistupovat jako k jakési unární operaci, jejímž jediným účelem je pomoci plně diagnostikovat systém. To je z velké části způsobeno tím, jak se historicky formovaly myšlenky o distribuovaném sledování. V , vyrobený při otevření Zipkinových zdrojů, bylo zmíněno, že to [Zipkin] dělá Twitter rychlejší. Byly také propagovány první komerční nabídky pro sledování .
Poznámka. přel.: Pro snazší pochopení dalšího textu si definujme dva základní pojmy podle :
- Rozsah — základní prvek distribuovaného sledování. Jde o popis určitého pracovního postupu (například databázového dotazu) s názvem, počátečním a koncovým časem, značkami, logy a kontextem.
- Rozpětí obvykle obsahuje odkazy na další rozpětí, což umožňuje kombinovat více rozpětí Sledovat — vizualizace životnosti požadavku, když se pohybuje distribuovaným systémem.
Trasování obsahuje neuvěřitelně cenná data, která mohou pomoci s úkoly, jako je testování výroby, testování obnovy po havárii, testování vkládání chyb atd. Ve skutečnosti některé společnosti již využívají sledování pro podobné účely. Začněme s má další využití kromě jednoduchého transportu rozpětí do skladovacího systému:
- Například Uber výsledky sledování k rozlišení mezi testovacím a produkčním provozem.
- facebook trasovací data pro analýzu kritických cest a pro přepínání provozu během pravidelných testů obnovy po havárii.
- Také sociální síť Notebooky Jupyter, které umožňují vývojářům spouštět libovolné dotazy na výsledky trasování.
- Přívrženci (Lineage Driven Failure Injection) distribuované stopy pro testování s injekcí chyb.
Žádná z výše uvedených možností se na scénář zcela nevztahuje ladění, během níž se inženýr snaží vyřešit problém pohledem na stopu.
Kdy to přijde zatím dosáhne ladícího skriptu, primárním rozhraním zůstává diagram traceview (i když to někteří také nazývají "Ganttův diagram" nebo "vodopádový diagram"). Pod traceview я všechna rozpětí a doprovodná metadata, která dohromady tvoří trasování. Každý open source systém sledování, stejně jako každé komerční řešení sledování, nabízí a traceview uživatelské rozhraní pro vizualizaci, detailování a filtrování tras.
Problém se všemi sledovacími systémy, které jsem zatím viděl, je ten, že výsledný vizualizace (traceview) téměř úplně odráží vlastnosti procesu generování stop. I když jsou navrženy alternativní vizualizace: heatmapy, topologie služeb, histogramy latence, stejně nakonec traceview.
V minulosti I že většina "inovací" v UI/UX sledování se zdá být omezena na další metadata ve sledování a investování do nich informací s vysokou mohutností (vysoká kardinalita) nebo poskytnutí možnosti procházet do konkrétních rozsahů nebo spouštět dotazy inter- a intra-trace... Čím traceview zůstává primárním vizualizačním nástrojem. Dokud bude tento stav pokračovat, bude distribuované trasování (v nejlepším případě) zaujímat 4. místo jako ladicí nástroj, po metrikách, protokolech a trasování zásobníku, a v nejhorším případě se ukáže jako plýtvání penězi a časem.
Problém s traceview
Účel traceview — poskytnout úplný obraz o pohybu jednoho požadavku napříč všemi komponentami distribuovaného systému, ke kterému se vztahuje. Některé pokročilejší systémy trasování umožňují procházet jednotlivými rozpětími a prohlížet si rozpis v průběhu času uvnitř jeden proces (když mají rozpětí funkční hranice).
Základním předpokladem architektury mikroslužeb je myšlenka, že organizační struktura roste s potřebami společnosti. Zastánci mikroslužeb tvrdí, že distribuce různých obchodních úkolů do jednotlivých služeb umožňuje malým, autonomním vývojovým týmům řídit celý životní cyklus takových služeb, což jim dává možnost tyto služby samostatně budovat, testovat a nasazovat. Nevýhodou této distribuce je však ztráta informací o tom, jak jednotlivé služby interagují s ostatními. V takových podmínkách se distribuované sledování prohlašuje za nepostradatelný nástroj ladění komplexní interakce mezi službami.
Pokud opravdu , pak to ani jeden člověk není schopen udržet v hlavě plné obrázek. Vyvinout nástroj založený na předpokladu, že je to vůbec možné, je ve skutečnosti něco jako anti-vzorec (neefektivní a neproduktivní přístup). V ideálním případě ladění vyžaduje nástroj, který pomáhá zúžit oblast hledání, takže se inženýři mohou zaměřit na podmnožinu dimenzí (služby/uživatelé/hostitelé atd.) relevantních pro zvažovaný problémový scénář. Při určování příčiny poruchy se od inženýrů nevyžaduje, aby rozuměli tomu, co se během ní stalo všechny služby najednou, protože takový požadavek by byl v rozporu se samotnou myšlenkou architektury mikroslužeb.
Nicméně, traceview je a to Tento. Ano, některé trasovací systémy nabízejí komprimované trasovací pohledy, když je počet rozpětí ve trasování tak velký, že je nelze zobrazit v jedné vizualizaci. Vzhledem k velkému množství informací obsažených i v takto okleštěné vizualizaci však inženýři stále nucen „prosít“, ručně zúžit výběr na sadu služeb, které jsou zdrojem problémů. Bohužel v tomto oboru jsou stroje mnohem rychlejší než lidé, méně náchylné k chybám a jejich výsledky jsou více opakovatelné.
Dalším důvodem, proč si myslím, že traceview je nesprávný, je ten, že není vhodný pro ladění založené na hypotézách. Ve svém jádru je ladění iterativní proces začínající hypotézou, po kterém následuje ověření různých pozorování a faktů získaných ze systému podél různých vektorů, závěry/zobecnění a další posouzení pravdivosti hypotézy.
Příležitost rychle a levně testování hypotéz a odpovídající zlepšení mentálního modelu základní kámen ladění Jakýkoli nástroj pro ladění by měl být interaktivní a zúžit prostor pro vyhledávání nebo v případě falešného vedení umožnit uživateli vrátit se a zaměřit se na jinou oblast systému. Perfektní nástroj to udělá proaktivně, okamžitě upozorní uživatele na potenciální problémové oblasti.
Běda, traceview nelze nazvat nástrojem s interaktivním rozhraním. Nejlepší, v co můžete při jeho používání doufat, je najít nějaký zdroj zvýšené latence a podívat se na všechny možné značky a protokoly s tím spojené. To nepomůže inženýrovi identifikovat vzory v provozu, jako jsou specifika distribuce zpoždění nebo detekovat korelace mezi různými měřeními. může pomoci obejít některé z těchto problémů. Opravdu, úspěšná analýza pomocí strojového učení k identifikaci anomálních rozsahů a identifikaci podmnožiny značek, které mohou být spojeny s anomálním chováním. Ještě jsem však neviděl přesvědčivé vizualizace zjištění strojového učení nebo dolování dat aplikovaných na rozpětí, která se výrazně liší od traceview nebo DAG (directed acyclic graph).
Rozpětí jsou příliš nízká
Základní problém traceview je ten rozpětí jsou příliš nízkoúrovňová primitiva pro analýzu latence i analýzu hlavní příčiny. Je to jako analyzovat jednotlivé příkazy procesoru, abyste se pokusili vyřešit výjimku, s vědomím, že existují nástroje na mnohem vyšší úrovni, jako je backtrace, se kterými je mnohem pohodlnější pracovat.
Navíc si dovolím tvrdit následující: v ideálním případě nepotřebujeme úplný obrázek došlo během životního cyklu požadavku, který představují moderní nástroje pro sledování. Místo toho je vyžadována nějaká forma abstrakce vyšší úrovně, která obsahuje informace o čem dopadlo špatně (podobně jako backtrace), spolu s určitým kontextem. Místo abych sledoval celou stopu, raději ji vidím часть, kde se děje něco zajímavého nebo neobvyklého. V současné době se vyhledávání provádí ručně: inženýr obdrží stopu a nezávisle analyzuje rozpětí při hledání něčeho zajímavého. Přístup lidí zírajících na rozpětí v jednotlivých stopách v naději, že odhalí podezřelou aktivitu, se vůbec neškáluje (zvláště když musí rozumět všem metadatům zakódovaným v různých rozpětích, jako je ID rozpětí, název metody RPC, trvání rozpětí 'a, protokoly, štítky atd.).
Alternativy k traceview
Výsledky trasování jsou nejužitečnější, když je lze vizualizovat způsobem, který poskytuje netriviální pohled na to, co se děje v propojených částech systému. Dokud se tak nestane, proces ladění z velké části zůstává inertní a závisí na schopnosti uživatele všimnout si správných korelací, zkontrolovat správné části systému nebo poskládat kousky skládačky dohromady – na rozdíl od nástroj, což uživateli pomáhá formulovat tyto hypotézy.
Nejsem vizuální designér ani UX specialista, ale v další sekci se chci podělit o pár nápadů, jak by tyto vizualizace mohly vypadat.
Zaměřte se na konkrétní služby
V době, kdy se průmysl kolem nápadů konsoliduje Zdá se rozumné, že jednotlivé týmy by měly upřednostňovat zajištění souladu jejich služeb s těmito cíli. Z toho vyplývá, že orientované na služby Pro takové týmy se nejlépe hodí vizualizace.
Stopy, zejména bez vzorkování, jsou pokladnicí informací o každé složce distribuovaného systému. Tyto informace mohou být předány mazanému procesoru, který bude zásobovat uživatele orientované na služby nálezy. Lze je identifikovat předem – ještě předtím, než se uživatel podívá na stopy:
- Diagramy rozložení latence pouze pro vysoce prominentní požadavky (vzdálené požadavky);
- Diagramy rozložení zpoždění pro případy, kdy není dosaženo cílů SLO služby;
- Nejčastěji „obecné“, „zajímavé“ a „divné“ značky v dotazech se opakují;
- Rozdělení latence pro případy, kdy závislostí služby nedosahují svých cílů SLO;
- Rozdělení latence pro různé navazující služby.
Na některé z těchto otázek jednoduše neodpovídají vestavěné metriky, což nutí uživatele zkoumat rozpětí. Výsledkem je, že máme extrémně uživatelsky nepřátelský mechanismus.
To vyvolává otázku: co složité interakce mezi různými službami řízenými různými týmy? Není to tak? traceview nepovažuje se za nejvhodnější nástroj ke zdůraznění takové situace?
Mobilní vývojáře, vlastníky bezstavových služeb, vlastníky spravovaných stavových služeb (jako jsou databáze) a vlastníky platforem může zajímat něco jiného prezentace distribuovaný systém; traceview je příliš obecné řešení pro tyto zásadně odlišné potřeby. I ve velmi složité architektuře mikroslužeb nepotřebují vlastníci služeb hluboké znalosti o více než dvou nebo třech upstream a downstream službách. V podstatě ve většině scénářů uživatelé potřebují pouze odpovídat na otázky týkající se omezený soubor služeb.
Je to jako dívat se na malou podmnožinu služeb přes lupu, abyste si ji mohli prohlédnout. To uživateli umožní klást naléhavější otázky týkající se komplexních interakcí mezi těmito službami a jejich bezprostředními závislostmi. Je to podobné jako backtrace ve světě služeb, kde inženýr ví že špatně a také má určité porozumění tomu, co se děje v okolních službách, aby pochopil proč.
Přístup, který propaguji, je přesným opakem přístupu shora dolů, založeného na traceview, kde analýza začíná celým trasováním a postupně se propracovává až k jednotlivým rozpětím. Naproti tomu přístup zdola nahoru začíná analýzou malé oblasti v blízkosti potenciální příčiny incidentu a poté podle potřeby rozšiřuje vyhledávací prostor (s potenciálem přivést další týmy k analýze širšího spektra služeb). Druhý přístup je vhodnější pro rychlé testování počátečních hypotéz. Jakmile budou získány konkrétní výsledky, bude možné přejít k cílenější a podrobnější analýze.
Budování topologie
Pohledy specifické pro službu mohou být neuvěřitelně užitečné, pokud to uživatel ví co služba nebo skupina služeb je zodpovědná za zvýšení latence nebo za způsobení chyb. Ve složitém systému však může být identifikace závadné služby netriviálním úkolem během selhání, zejména pokud ze služeb nebyly hlášeny žádné chybové zprávy.
Sestavení topologie služby může být velkou pomocí při zjišťování, která služba zažívá prudký nárůst chybovosti nebo zvýšení latence, které způsobuje znatelné zhoršení služby. Když mluvím o budování topologie, nemám na mysli mapa služeb, zobrazující všechny služby dostupné v systému a známé tím . Tento pohled není o nic lepší než traceview na základě orientovaného acyklického grafu. Místo toho bych chtěl vidět dynamicky generovaná topologie služeb, na základě určitých atributů, jako je chybovost, doba odezvy nebo jakýkoli uživatelsky definovaný parametr, který pomáhá objasnit situaci s konkrétními podezřelými službami.
Vezměme si příklad. Představme si hypotetický zpravodajský web. Služba domovské stránky (přední strana) vyměňuje data s Redis, s doporučovací službou, s reklamní službou a video službou. Video služba přebírá videa z S3 a metadata z DynamoDB. Služba doporučení přijímá metadata z DynamoDB, načítá data z Redis a MySQL a zapisuje zprávy do Kafky. Reklamní služba přijímá data z MySQL a píše zprávy Kafkovi.
Níže je schematické znázornění této topologie (topologii vytváří mnoho komerčních směrovacích programů). Může být užitečné, pokud potřebujete porozumět závislostem služeb. Nicméně během ladění, když určitá služba (řekněme video služba) vykazuje zvýšenou dobu odezvy, není taková topologie příliš užitečná.
Servisní diagram hypotetického zpravodajského webu
Níže uvedený diagram by byl vhodnější. Vyskytl se problém se službou (video) vyobrazeno přímo uprostřed. Uživatel si toho okamžitě všimne. Z této vizualizace je zřejmé, že video služba funguje abnormálně kvůli prodloužení doby odezvy S3, což ovlivňuje rychlost načítání části hlavní stránky.
Dynamická topologie zobrazující pouze „zajímavé“ služby
Dynamicky generované topologie mohou být efektivnější než statické mapy služeb, zejména v elastických infrastrukturách s automatickým škálováním. Schopnost porovnávat a porovnávat topologie služeb umožňuje uživateli klást relevantnější otázky. Přesnější otázky o systému pravděpodobně povedou k lepšímu pochopení toho, jak systém funguje.
Srovnávací zobrazení
Další užitečnou vizualizací by bylo srovnávací zobrazení. V současné době nejsou stopy příliš vhodné pro porovnávání vedle sebe, takže srovnání obvykle ano rozpětí. A hlavní myšlenkou tohoto článku je právě to, že rozsahy jsou příliš nízké na to, aby z výsledků trasování extrahovaly ty nejcennější informace.
Porovnání dvou tras nevyžaduje zásadně nové vizualizace. Ve skutečnosti stačí něco jako histogram představující stejné informace jako traceview. Kupodivu i tato jednoduchá metoda může přinést mnohem více ovoce než pouhé studium dvou stop odděleně. Ještě silnější by byla možnost vizualizovat srovnání stop Dohromady. Bylo by nesmírně užitečné vidět, jak nedávno nasazená změna konfigurace databáze umožňující GC (sběr odpadu) ovlivňuje dobu odezvy navazující služby v rozsahu několika hodin. Pokud to, co zde popisuji, zní jako A/B analýza dopadu změn infrastruktury v mnoha službách pomocí výsledků trasování pak nejste příliš daleko od pravdy.
Závěr
Nezpochybňuji užitečnost samotného sledování. Upřímně věřím, že neexistuje žádná jiná metoda pro sběr dat tak bohatých, kauzálních a kontextových, jako jsou ty obsažené ve stopě. Jsem však také přesvědčen, že všechna řešení pro sledování využívají tato data extrémně neefektivně. Dokud nástroje pro sledování zůstanou přilepené na reprezentaci traceview, budou omezeny ve své schopnosti maximálně využít cenné informace, které lze extrahovat z dat obsažených ve trasování. Navíc hrozí další vývoj zcela nepřívětivého a neintuitivního vizuálního rozhraní, které výrazně omezí možnosti uživatele odstraňovat chyby v aplikaci.
Ladění složitých systémů, a to i pomocí nejnovějších nástrojů, je neuvěřitelně obtížné. Nástroje by měly vývojářům pomoci formulovat a testovat hypotézu, aktivně poskytovat relevantní informace, identifikace odlehlých hodnot a zaznamenání rysů v rozložení zpoždění. Aby se trasování stalo nástrojem volby pro vývojáře při řešení problémů s produkčními poruchami nebo řešení problémů, které zahrnují více služeb, jsou zapotřebí originální uživatelská rozhraní a vizualizace, které jsou více konzistentní s mentálním modelem vývojářů, kteří tyto služby vytvářejí a provozují.
Navrhnout systém, který bude reprezentovat různé signály dostupné ve výsledcích trasování způsobem, který je optimalizován pro snadnou analýzu a odvození, bude vyžadovat značné duševní úsilí. Musíte přemýšlet o tom, jak abstrahovat topologii systému během ladění způsobem, který uživateli pomůže překonat slepá místa, aniž by se díval na jednotlivé stopy nebo rozpětí.
Potřebujeme dobré možnosti abstrakce a vrstvení (zejména v uživatelském rozhraní). Takové, které by se dobře hodily do procesu ladění založeného na hypotézách, kde můžete opakovaně klást otázky a testovat hypotézy. Nevyřeší automaticky všechny problémy s pozorovatelností, ale pomohou uživatelům zbystřit intuici a formulovat chytřejší otázky. Vyzývám k promyšlenějšímu a inovativnějšímu přístupu k vizualizaci. Je zde reálná vyhlídka na rozšíření obzorů.
PS od překladatele
Přečtěte si také na našem blogu:
- «";
- «";
- «".
Zdroj: www.habr.com