Notera. transl.: Författaren till det här materialet är Cindy Sridharan, ingenjör på imgix som är specialiserad på API-utveckling och i synnerhet testning av mikrotjänster. I detta material delar hon med sig av sin detaljerade syn på aktuella problem inom området distribuerad spårning, där det enligt hennes uppfattning saknas verkligt effektiva verktyg för att lösa akuta problem.
[Illustration hämtad från om distribuerad spårning.]
Det förmodas att svåra att genomföra, och avkastningen på det . Det finns många anledningar till varför spårning är problematiskt, ofta med hänvisning till det arbete som är involverat i att konfigurera varje systemkomponent för att överföra lämpliga rubriker med varje begäran. Även om detta problem finns, är det inte på något sätt oöverstigligt. Förresten, det förklarar inte varför utvecklare inte riktigt gillar spårning (även när det redan fungerar).
Den största utmaningen med distribuerad spårning är inte att samla in data, standardisera format för att distribuera och presentera resultat, eller att bestämma när, var och hur man ska prova. Jag försöker inte föreställa mig trivial dessa "begriplighetsproblem" är i själva verket ganska betydande tekniska och (om vi överväger verkligen öppen källkod) ) politiska utmaningar som måste övervinnas för att dessa problem ska anses lösa.
Men om vi tänker oss att alla dessa problem är lösta är det stor sannolikhet att ingenting kommer att förändras nämnvärt m.t.t. slutanvändarens upplevelse. Spårning kanske fortfarande inte är praktiskt användbar i de vanligaste felsökningsscenarierna – även efter att den har distribuerats.
Så annorlunda spår
Distribuerad spårning inkluderar flera olika komponenter:
- utrusta applikationer och mellanprogram med kontrollverktyg;
- distribuerad kontextöverföring;
- insamling av spår;
- spårlagring;
- deras utvinning och visualisering.
Mycket prat om distribuerad spårning tenderar att behandla det som en sorts unär operation vars enda syfte är att hjälpa till att helt diagnostisera systemet. Detta beror till stor del på hur idéer om distribuerad spårning har formats historiskt. I , som gjordes när Zipkin-källorna öppnades, nämndes det att det [Zipkin] gör Twitter snabbare. De första kommersiella erbjudandena för spårning marknadsfördes också som .
Notera. transl.: För att göra ytterligare text lättare att förstå, låt oss definiera två grundläggande termer enligt :
- Spänna — Grundelementet i distribuerad spårning. Det är en beskrivning av ett visst arbetsflöde (till exempel en databasfråga) med namn, start- och sluttider, taggar, loggar och sammanhang.
- Spännen innehåller vanligtvis länkar till andra spann, vilket gör att flera spann kan kombineras till Trace — visualisering av livslängden för en förfrågan när den rör sig genom ett distribuerat system.
Spår innehåller otroligt värdefull data som kan hjälpa till med uppgifter som produktionstestning, katastrofåterställningstestning, felinjektionstestning, etc. Faktum är att vissa företag redan använder spårning för liknande ändamål. Låt oss börja med har andra användningsområden förutom att bara flytta spann till lagringssystemet:
- Till exempel Uber spårningsresultat för att skilja mellan testtrafik och produktionstrafik.
- Facebook spåra data för kritisk väganalys och för trafikväxling under regelbundna katastrofåterställningstester.
- Även socialt nätverk Jupyter-anteckningsböcker som låter utvecklare köra godtyckliga frågor på spårningsresultat.
- Anhängare (Lineage Driven Failure Injection) distribuerade spår för testning med felinjektion.
Inget av alternativen ovan gäller helt och hållet för scenariot felsökning, under vilken ingenjören försöker lösa problemet genom att titta på spåret.
När det kommer än når felsökningsskriptet, förblir det primära gränssnittet diagrammet spårvy (även om vissa också kallar det "Gantt-diagram" eller "vattenfallsdiagram"). Under spårvy я alla spann och tillhörande metadata som tillsammans utgör spåret. Varje spårningssystem med öppen källkod, såväl som alla kommersiella spårningslösningar, erbjuder en spårvy användargränssnitt för att visualisera, detaljera och filtrera spår.
Problemet med alla spårningssystem jag har sett hittills är att resultatet visualisering (traceview) nästan helt återspeglar funktionerna i spårgenereringsprocessen. Även när alternativa visualiseringar föreslås: värmekartor, tjänstetopologier, latenshistogram, kommer de ändå i slutändan till spårvy.
Förr i tiden som de flesta "innovationer" inom UI/UX-spårning verkar vara begränsade till ytterligare metadata i spåret, investerar i dem information med hög kardinalitet (hög kardinalitet) eller ger möjlighet att gå ner i specifika intervall eller köra frågor inter- och intra-spårning... Vart i spårvy förblir det primära visualiseringsverktyget. Så länge det här läget fortsätter kommer distribuerad spårning (i bästa fall) att ta 4:e plats som ett felsökningsverktyg, efter mätvärden, loggar och stackspår, och i värsta fall kommer det att visa sig vara slöseri med pengar och tid.
Problem med traceview
öde spårvy — ge en fullständig bild av förflyttningen av en enda begäran över alla komponenter i det distribuerade systemet som den är relaterad till. Vissa mer avancerade spårningssystem låter dig borra ner i individuella spann och se en uppdelning över tid inom en process (när spann har funktionella gränser).
Grundpremissen för mikrotjänsters arkitektur är idén att organisationsstrukturen växer med företagets behov. Förespråkare för mikrotjänster hävdar att distribution av olika affärsuppgifter till individuella tjänster tillåter små, autonoma utvecklingsteam att kontrollera hela livscykeln för sådana tjänster, vilket ger dem möjlighet att självständigt bygga, testa och distribuera dessa tjänster. Nackdelen med denna distribution är dock förlusten av information om hur varje tjänst interagerar med andra. Under sådana förhållanden hävdar distribuerad spårning att vara ett oumbärligt verktyg för felsökning komplexa interaktioner mellan tjänster.
Om du verkligen , då kan inte en enda person hålla det i huvudet komplett bild. Att utveckla ett verktyg baserat på antagandet att det ens är möjligt är faktiskt något av ett antimönster (ett ineffektivt och improduktivt tillvägagångssätt). Helst kräver felsökning ett verktyg som hjälper begränsa ditt sökområde, så att ingenjörer kan fokusera på en delmängd av dimensioner (tjänster/användare/värdar, etc.) som är relevanta för det problemscenario som övervägs. När man ska fastställa orsaken till ett fel behöver ingenjörer förstå vad som hände under alla tjänster på en gång, eftersom ett sådant krav skulle motsäga själva idén med mikrotjänstarkitektur.
Det är dock traceview nämligen Detta. Ja, vissa spårningssystem erbjuder komprimerade spårvyer när antalet spann i spåret är så stort att de inte kan visas i en visualisering. Men på grund av den stora mängden information som finns även i en sådan avskalad visualisering, är ingenjörer fortfarande tvingade "sålla" det, manuellt begränsa urvalet till en uppsättning tjänster som är källor till problem. Tyvärr är maskiner inom detta område mycket snabbare än människor, mindre benägna att göra fel, och deras resultat är mer repeterbara.
En annan anledning till att jag tycker att traceview är fel är att det inte är bra för hypotesdriven felsökning. I kärnan är felsökning iterativ en process som börjar med en hypotes, följt av verifiering av olika observationer och fakta erhållna från systemet längs olika vektorer, slutsatser/generaliseringar och ytterligare bedömning av hypotesens sanning.
Möjlighet snabbt och billigt testa hypoteser och förbättra den mentala modellen i enlighet därmed hörnsten felsökning Alla felsökningsverktyg bör vara interaktiv och begränsa sökutrymmet eller, i fallet med en falsk ledning, låt användaren gå tillbaka och fokusera på ett annat område av systemet. Det perfekta verktyget kommer att göra detta proaktivt, omedelbart uppmärksamma användaren på potentiella problemområden.
Ack, spårvy kan inte kallas ett verktyg med ett interaktivt gränssnitt. Det bästa du kan hoppas på när du använder det är att hitta någon källa till ökad latens och titta på alla möjliga taggar och loggar som är associerade med den. Detta hjälper inte ingenjören att identifiera mönster i trafiken, såsom detaljerna i fördröjningsfördelningen, eller upptäcka korrelationer mellan olika mätningar. kan hjälpa till att komma runt några av dessa problem. Verkligen, framgångsrik analys med hjälp av maskininlärning för att identifiera avvikande spann och identifiera en undergrupp av taggar som kan vara associerade med avvikande beteende. Men jag har ännu inte sett övertygande visualiseringar av maskininlärning eller datautvinningsresultat tillämpade på spann som skiljer sig väsentligt från en traceview eller en DAG (riktad acyklisk graf).
Spännvidden är för låg
Det grundläggande problemet med traceview är det spänner över är för låga primitiva för både latensanalys och rotorsaksanalys. Det är som att analysera individuella processorkommandon för att försöka lösa ett undantag, med vetskapen om att det finns verktyg på mycket högre nivå som backtrace som är mycket bekvämare att arbeta med.
Dessutom tar jag mig friheten att hävda följande: I idealfallet behöver vi inte hela bilden inträffade under begärans livscykel, som representeras av moderna spårningsverktyg. Istället krävs någon form av abstraktion på högre nivå som innehåller information om vad gick fel (liknar backtrace), tillsammans med något sammanhang. Istället för att titta på hela spåret föredrar jag att se det часть, där något intressant eller ovanligt händer. För närvarande utförs sökningen manuellt: ingenjören tar emot spåret och analyserar självständigt spann i jakt på något intressant. Tillvägagångssättet med människor som stirrar på spann i individuella spår i hopp om att upptäcka misstänkt aktivitet skalas inte alls (särskilt när de måste förstå all metadata som kodats i olika spann, som span-ID, RPC-metodnamn, spanvaraktighet 'a, loggar, taggar, etc.).
Alternativ till traceview
Spårningsresultat är mest användbara när de kan visualiseras på ett sätt som ger icke-trivial insikt i vad som händer i sammankopplade delar av systemet. Tills detta händer återstår i stort sett felsökningsprocessen inert och beror på användarens förmåga att lägga märke till rätt korrelationer, kontrollera rätt delar av systemet eller lägga pusselbitarna - till skillnad från verktyg, som hjälper användaren att formulera dessa hypoteser.
Jag är ingen visuell designer eller UX-specialist, men i nästa avsnitt vill jag dela med mig av några idéer om hur dessa visualiseringar kan se ut.
Fokusera på specifika tjänster
I en tid då branschen konsolideras kring idéer , verkar det rimligt att enskilda team bör prioritera att säkerställa att deras tjänster är anpassade till dessa mål. Det följer att serviceinriktad visualisering är bäst lämpad för sådana team.
Spår, särskilt utan provtagning, är en skattkammare av information om varje komponent i ett distribuerat system. Denna information kan matas till en listig processor som kommer att förse användare serviceinriktad De kan identifieras i förväg - även innan användaren tittar på spåren:
- Diagram för latensdistribution endast för mycket framträdande förfrågningar (avvikande begäranden);
- Diagram över fördröjningsfördelning för fall då service SLO-mål inte uppnås;
- De mest "vanliga", "intressanta" och "konstiga" taggarna i frågor som oftast upprepas;
- Latensuppdelning för fall där beroende på tjänster uppnår inte sina SLO-mål;
- Latensuppdelning för olika nedströmstjänster.
Vissa av dessa frågor besvaras helt enkelt inte av inbyggda mätvärden, vilket tvingar användare att granska spann. Som ett resultat har vi en extremt användarfientlig mekanism.
Detta väcker frågan: hur är det med komplexa interaktioner mellan olika tjänster som kontrolleras av olika team? Är det inte det spårvy anses inte vara det lämpligaste verktyget för att belysa en sådan situation?
Mobilutvecklare, ägare av statslösa tjänster, ägare av hanterade statliga tjänster (som databaser) och plattformsägare kan vara intresserade av något annat presentation distribuerat system; spårvy är en alltför generisk lösning för dessa fundamentalt olika behov. Även i en mycket komplex mikrotjänstarkitektur behöver tjänsteägare inte djup kunskap om mer än två eller tre uppströms- och nedströmstjänster. I huvudsak behöver användare i de flesta scenarier bara svara på frågor om begränsad uppsättning tjänster.
Det är som att titta på en liten delmängd av tjänster genom ett förstoringsglas för att granska det. Detta kommer att tillåta användaren att ställa mer pressande frågor angående de komplexa interaktionerna mellan dessa tjänster och deras omedelbara beroenden. Detta liknar backtrace i tjänstevärlden, där ingenjören vet att fel, och har också en viss förståelse för vad som händer i omgivande tjänster att förstå Varför.
Tillvägagångssättet jag förespråkar är raka motsatsen till det uppifrån och ner, traceview-baserade tillvägagångssättet, där analysen börjar med hela spåret och sedan gradvis arbetar ner till individuella spann. Däremot börjar en nedifrån-och-upp-metod med att analysera ett litet område nära den potentiella orsaken till incidenten, och sedan utökar sökutrymmet efter behov (med potential att ta in andra team för att analysera ett bredare utbud av tjänster). Den andra metoden är bättre lämpad för att snabbt testa initiala hypoteser. När konkreta resultat erhållits kommer det att vara möjligt att gå vidare till en mer fokuserad och detaljerad analys.
Att bygga en topologi
Tjänstespecifika vyer kan vara otroligt användbara om användaren vet vilken en tjänst eller grupp av tjänster är ansvarig för att öka latensen eller orsaka fel. Men i ett komplext system kan identifiering av den felande tjänsten vara en icke-trivial uppgift under ett fel, särskilt om inga felmeddelanden rapporterades från tjänsterna.
Att bygga en tjänsttopologi kan vara till stor hjälp för att ta reda på vilken tjänst som upplever en topp i felfrekvensen eller en ökning av latens som gör att tjänsten märkbart försämras. När jag pratar om att bygga en topologi menar jag inte tjänster karta, som visar alla tjänster som är tillgängliga i systemet och kända för sina . Denna vy är inte bättre än traceview baserat på en riktad acyklisk graf. Istället skulle jag vilja se dynamiskt genererad tjänststopologi, baserat på vissa attribut som felfrekvens, svarstid eller någon användardefinierad parameter som hjälper till att klargöra situationen med specifika misstänkta tjänster.
Låt oss ta ett exempel. Låt oss föreställa oss en hypotetisk nyhetssajt. Hemsidatjänst (framsida) utbyter data med Redis, med en rekommendationstjänst, med en annonstjänst och en videotjänst. Videotjänsten tar videor från S3 och metadata från DynamoDB. Rekommendationstjänsten tar emot metadata från DynamoDB, laddar data från Redis och MySQL och skriver meddelanden till Kafka. Annonstjänsten tar emot data från MySQL och skriver meddelanden till Kafka.
Nedan finns en schematisk representation av denna topologi (många kommersiella routingprogram bygger topologin). Det kan vara användbart om du behöver förstå tjänsteberoenden. Dock under felsökning, när en viss tjänst (säg en videotjänst) uppvisar ökad svarstid, är en sådan topologi inte särskilt användbar.
Servicediagram av en hypotetisk nyhetssajt
Diagrammet nedan skulle passa bättre. Det finns ett problem med tjänsten (video) avbildad mitt i mitten. Användaren märker det omedelbart. Från denna visualisering blir det tydligt att videotjänsten fungerar onormalt på grund av en ökning av S3-svarstiden, vilket påverkar laddningshastigheten för en del av huvudsidan.
Dynamisk topologi som endast visar "intressanta" tjänster
Dynamiskt genererade topologier kan vara effektivare än statiska servicekartor, särskilt i elastiska, automatiskt skalande infrastrukturer. Möjligheten att jämföra och kontrastera tjänstetopologier gör att användaren kan ställa mer relevanta frågor. Mer exakta frågor om systemet leder mer sannolikt till en bättre förståelse för hur systemet fungerar.
Jämförande display
En annan användbar visualisering skulle vara en jämförande display. För närvarande är spår inte särskilt lämpliga för jämförelser sida vid sida, så jämförelser är vanligtvis spänner över. Och huvudtanken med den här artikeln är just att spann är för låga för att extrahera den mest värdefulla informationen från spårningsresultaten.
Att jämföra två spår kräver inte i grunden nya visualiseringar. Faktum är att något som ett histogram som representerar samma information som en traceview är tillräckligt. Överraskande nog kan även denna enkla metod ge mycket mer frukt än att bara studera två spår separat. Ännu kraftfullare skulle möjligheten vara visualisera jämförelse av spår Totalt. Det skulle vara extremt användbart att se hur en nyligen distribuerad databaskonfigurationsändring för att aktivera GC (skräphämtning) påverkar svarstiden för en nedströmstjänst i en skala av flera timmar. Om det jag beskriver här låter som en A/B-analys av effekterna av infrastrukturförändringar i många tjänster genom att använda spårningsresultaten är du inte alltför långt ifrån sanningen.
Slutsats
Jag ifrågasätter inte användbarheten av själva spårningen. Jag tror uppriktigt att det inte finns någon annan metod för att samla in data så rik, kausal och kontextuell som den som finns i ett spår. Men jag tror också att alla spårningslösningar använder denna data extremt ineffektivt. Så länge spårningsverktyg förblir fast på traceview-representationen, kommer de att vara begränsade i sin förmåga att få ut det mesta av den värdefulla information som kan extraheras från data som finns i spåren. Dessutom finns det en risk att vidareutveckla ett helt ovänligt och ointuitivt visuellt gränssnitt som kraftigt kommer att begränsa användarens möjlighet att felsöka fel i applikationen.
Att felsöka komplexa system, även med de senaste verktygen, är otroligt svårt. Verktyg ska hjälpa utvecklaren att formulera och testa en hypotes, aktivt tillhandahåller relevant information, identifiera extremvärden och notera funktioner i fördelningen av förseningar. För att spårning ska bli det bästa verktyget för utvecklare när man felsöker produktionsfel eller löser problem som sträcker sig över flera tjänster, behövs ursprungliga användargränssnitt och visualiseringar som är mer förenliga med den mentala modellen hos utvecklarna som skapar och driver dessa tjänster.
Det kommer att kräva betydande mental ansträngning att designa ett system som kommer att representera de olika signalerna som finns tillgängliga i spårningsresultaten på ett sätt som är optimerat för enkel analys och slutledning. Du måste tänka på hur man abstraherar systemtopologin under felsökning på ett sätt som hjälper användaren att övervinna blinda fläckar utan att titta på individuella spår eller spann.
Vi behöver bra abstraktions- och lagerkapacitet (särskilt i användargränssnittet). Sådana som skulle passa väl in i en hypotesdriven felsökningsprocess där du iterativt kan ställa frågor och testa hypoteser. De kommer inte automatiskt att lösa alla observerbarhetsproblem, men de kommer att hjälpa användare att vässa sin intuition och formulera smartare frågor. Jag efterlyser ett mer genomtänkt och innovativt förhållningssätt till visualisering. Här finns en verklig möjlighet att vidga vyerna.
PS från översättaren
Läs även på vår blogg:
- «";
- «";
- «".
Källa: will.com