Bemærk. overs.: Forfatteren af dette materiale er Cindy Sridharan, en ingeniør hos imgix, som har specialiseret sig i API-udvikling og især mikroservicetestning. I dette materiale deler hun sin detaljerede vision om aktuelle problemer inden for distribueret sporing, hvor der efter hendes mening mangler virkelig effektive værktøjer til at løse presserende problemer.
[Illustration taget fra om distribueret sporing.]
Det antages, at vanskeligt at implementere, og afkastet af det . Der er mange grunde til, at sporing er problematisk, ofte med henvisning til det arbejde, der er involveret i at konfigurere hver systemkomponent til at sende de passende overskrifter med hver anmodning. Selvom dette problem eksisterer, er det på ingen måde uoverkommeligt. Det forklarer i øvrigt ikke, hvorfor udviklere ikke rigtig kan lide sporing (selv når det allerede fungerer).
Den største udfordring med distribueret sporing er ikke at indsamle data, standardisere formater til distribution og præsentation af resultater eller at bestemme hvornår, hvor og hvordan der skal prøves. Jeg prøver ikke at forestille mig trivielt disse "forståelighedsproblemer" er faktisk ret betydelige tekniske og (hvis vi virkelig betragter Open Source) ) politiske udfordringer, der skal overvindes, så disse problemer kan anses for løst.
Men forestiller vi os, at alle disse problemer er løst, er der stor sandsynlighed for, at intet ændrer sig væsentligt mht. slutbrugeroplevelse. Sporing er muligvis stadig ikke praktisk anvendelig i de mest almindelige fejlfindingsscenarier – selv efter at den er blevet implementeret.
Sådan et anderledes spor
Distribueret sporing omfatter flere forskellige komponenter:
- udstyre applikationer og middleware med kontrolværktøjer;
- distribueret kontekstoverførsel;
- indsamling af spor;
- spor opbevaring;
- deres udvinding og visualisering.
En masse snak om distribueret sporing har en tendens til at behandle det som en slags unær operation, hvis eneste formål er at hjælpe med at diagnosticere systemet fuldt ud. Dette skyldes i høj grad, hvordan ideer om distribueret sporing historisk er blevet dannet. I , lavet da Zipkin-kilderne blev åbnet, blev det nævnt, at det [Zipkin] gør Twitter hurtigere. De første kommercielle tilbud til sporing blev også promoveret som .
Bemærk. overs.: For at gøre yderligere tekst lettere at forstå, lad os definere to grundlæggende udtryk iflg :
- Span — det grundlæggende element i distribueret sporing. Det er en beskrivelse af en bestemt arbejdsgang (for eksempel en databaseforespørgsel) med navn, start- og sluttider, tags, logfiler og kontekst.
- Spænd indeholder typisk links til andre spænd, hvilket gør det muligt at kombinere flere spænd til Trace — visualisering af en anmodnings levetid, når den bevæger sig gennem et distribueret system.
Spor indeholder utroligt værdifulde data, der kan hjælpe med opgaver såsom produktionstest, disaster recovery test, fejlinjektionstest osv. Faktisk bruger nogle virksomheder allerede sporing til lignende formål. Lad os begynde med har andre anvendelser udover blot at transportere spænd til lagersystemet:
- For eksempel Uber sporingsresultater for at skelne mellem testtrafik og produktionstrafik.
- Facebook sporingsdata til kritisk stianalyse og til trafikskift under regelmæssige katastrofegendannelsestests.
- Også socialt netværk Jupyter-notebooks, der giver udviklere mulighed for at køre vilkårlige forespørgsler på sporingsresultater.
- Tilhængere (Lineage Driven Failure Injection) uddelte spor til test med fejlinjektion.
Ingen af de ovennævnte muligheder gælder udelukkende for scenariet fejlretning, hvor ingeniøren forsøger at løse problemet ved at se på sporet.
Når det kommer endnu når fejlfindingsscriptet, forbliver den primære grænseflade diagrammet sporvisning (selvom nogle også kalder det "Gantt kort" eller "vandfaldsdiagram"). Under sporvisning я alle de spænd og medfølgende metadata, der tilsammen udgør sporet. Ethvert open source-sporingssystem såvel som enhver kommerciel sporingsløsning tilbyder en sporvisning brugergrænseflade til visualisering, detaljering og filtrering af spor.
Problemet med alle de sporingssystemer, jeg hidtil har set, er, at resultatet visualisering (traceview) næsten fuldstændigt afspejler funktionerne i sporgenereringsprocessen. Selv når alternative visualiseringer foreslås: varmekort, servicetopologier, latenshistogrammer, kommer de stadig i sidste ende ned på sporvisning.
Tidligere jeg at de fleste "innovationer" i UI/UX-sporing ser ud til at være begrænset til yderligere metadata i spor, investere i dem information med høj kardinalitet (høj kardinalitet) eller giver mulighed for at gå ned i specifikke spænd eller køre forespørgsler inter- og intra-trace... Hvori sporvisning forbliver det primære visualiseringsværktøj. Så længe denne situation fortsætter, vil distribueret sporing (i bedste fald) indtage 4. pladsen som et fejlfindingsværktøj, efter metrik, logs og stakspor, og i værste fald vil det vise sig at være spild af penge og tid.
Problem med traceview
skæbne sporvisning — give et fuldstændigt billede af bevægelsen af en enkelt anmodning på tværs af alle komponenter i det distribuerede system, som den er relateret til. Nogle mere avancerede sporingssystemer giver dig mulighed for at bore ned i individuelle spænd og se en opdeling over tid inden én proces (når spænd har funktionelle grænser).
Den grundlæggende forudsætning for mikroservicearkitektur er ideen om, at organisationsstrukturen vokser med virksomhedens behov. Tilhængere af mikrotjenester hævder, at distribution af forskellige forretningsopgaver i individuelle tjenester giver små, selvstændige udviklingsteams mulighed for at kontrollere hele livscyklussen af sådanne tjenester, hvilket giver dem mulighed for selvstændigt at bygge, teste og implementere disse tjenester. Ulempen ved denne distribution er imidlertid tabet af information om, hvordan hver tjeneste interagerer med andre. Under sådanne forhold hævder distribueret sporing at være et uundværligt værktøj til fejlretning komplekse interaktioner mellem tjenester.
Hvis du virkelig , så er ikke en eneste person i stand til at holde det i hovedet fuld billede. Faktisk er udvikling af et værktøj baseret på antagelsen om, at det overhovedet er muligt, noget af et anti-mønster (en ineffektiv og uproduktiv tilgang). Ideelt set kræver fejlfinding et værktøj, der hjælper indsnævre dit søgeområde, så ingeniører kan fokusere på en delmængde af dimensioner (tjenester/brugere/værter osv.), der er relevante for det problemscenarie, der overvejes. Når man skal bestemme årsagen til en fejl, er ingeniører ikke forpligtet til at forstå, hvad der skete under alle tjenester på én gang, da et sådant krav ville modsige selve ideen om mikroservicearkitektur.
Traceview er dog nemlig Det her. Ja, nogle sporingssystemer tilbyder komprimerede sporingsvisninger, når antallet af spænd i sporet er så stort, at de ikke kan vises i én visualisering. Men på grund af den store mængde information, der er indeholdt selv i en sådan strippet visualisering, er ingeniører stadig tvunget "siv" det, og indsnævrer manuelt udvalget til et sæt tjenester, der er kilder til problemer. Desværre er maskiner på dette felt meget hurtigere end mennesker, mindre tilbøjelige til fejl, og deres resultater er mere gentagelige.
En anden grund til, at jeg mener, at traceview er forkert, er, at det ikke er godt til hypotesedrevet fejlfinding. I sin kerne er debugging iterativ en proces, der starter med en hypotese, efterfulgt af verifikation af forskellige observationer og fakta opnået fra systemet langs forskellige vektorer, konklusioner/generaliseringer og yderligere vurdering af sandheden af hypotesen.
Opportunity hurtigt og billigt teste hypoteser og forbedre den mentale model i overensstemmelse hermed hjørnesten fejlretning Ethvert fejlfindingsværktøj bør være interaktive og indsnævre søgeområdet eller, i tilfælde af en falsk kundeemne, tillade brugeren at gå tilbage og fokusere på et andet område af systemet. Det perfekte værktøj vil gøre dette proaktivt, der straks henleder brugerens opmærksomhed på potentielle problemområder.
Ak, sporvisning kan ikke kaldes et værktøj med en interaktiv grænseflade. Det bedste du kan håbe på, når du bruger det, er at finde en kilde til øget latenstid og se på alle de mulige tags og logfiler, der er forbundet med det. Dette hjælper ikke ingeniøren med at identificere mønstre i trafikken, såsom detaljerne i forsinkelsesfordelingen, eller detekter korrelationer mellem forskellige målinger. kan hjælpe med at omgå nogle af disse problemer. Virkelig, vellykket analyse ved hjælp af maskinlæring til at identificere unormale spænd og identificere en undergruppe af tags, der kan være forbundet med unormal adfærd. Jeg har dog endnu ikke set overbevisende visualiseringer af maskinlæring eller data mining-resultater anvendt på spænd, der er væsentligt forskellige fra en traceview eller en DAG (rettet acyklisk graf).
Spændvidden er for lav
Det grundlæggende problem med traceview er det spænder over er for lavt niveau primitiver til både latensanalyse og årsagsanalyse. Det er som at parse individuelle processorkommandoer for at forsøge at løse en undtagelse, vel vidende at der er meget højere niveauværktøjer som backtrace, der er meget mere praktiske at arbejde med.
Desuden vil jeg tage mig den frihed at påstå følgende: Ideelt set har vi ikke brug for det det fulde billede opstod i løbet af anmodningens livscyklus, som er repræsenteret af moderne sporingsværktøjer. I stedet kræves der en form for abstraktion på højere niveau, der indeholder information om hvad gik galt (ligner backtrace), sammen med en vis kontekst. I stedet for at se hele sporet, foretrækker jeg at se det часть, hvor der sker noget interessant eller usædvanligt. I øjeblikket udføres søgningen manuelt: Ingeniøren modtager sporet og analyserer uafhængigt spændene i jagten på noget interessant. Tilgangen med folk, der stirrer på spænd i individuelle spor i håb om at opdage mistænkelig aktivitet, skalerer slet ikke (især når de skal give mening i alle de metadata, der er kodet i forskellige spænd, såsom spænd-id, RPC-metodenavn, spændvidde 'a, logfiler, tags osv.).
Alternativer til traceview
Sporingsresultater er mest nyttige, når de kan visualiseres på en måde, der giver ikke-triviel indsigt i, hvad der sker i indbyrdes forbundne dele af systemet. Indtil dette sker, forbliver fejlretningsprocessen stort set inert og afhænger af brugerens evne til at lægge mærke til de rigtige sammenhænge, tjekke de rigtige dele af systemet eller sætte brikkerne i puslespillet sammen – i modsætning til værktøj, der hjælper brugeren med at formulere disse hypoteser.
Jeg er ikke visuel designer eller UX-specialist, men i næste afsnit vil jeg dele et par ideer til, hvordan disse visualiseringer kan se ud.
Fokus på specifikke tjenester
På et tidspunkt, hvor branchen konsoliderer sig omkring ideer , forekommer det rimeligt, at individuelle teams skal prioritere at sikre, at deres tjenester er tilpasset disse mål. Den følger det serviceorienteret visualisering er bedst egnet til sådanne teams.
Spor, især uden prøveudtagning, er en skattekiste af information om hver komponent i et distribueret system. Denne information kan føres til en snedig processor, der vil forsyne brugerne serviceorienteret fund. De kan identificeres på forhånd - selv før brugeren ser på sporene:
- Latency distributionsdiagrammer kun for meget fremtrædende anmodninger (outlier anmodninger);
- Diagrammer over forsinkelsesfordeling for tilfælde, hvor service SLO-mål ikke nås;
- De mest "almindelige", "interessante" og "mærkelige" tags i forespørgsler, der oftest gentages;
- Latency opdeling for tilfælde hvor зависимости tjenester opnår ikke deres SLO-mål;
- Latency-opdeling for forskellige downstream-tjenester.
Nogle af disse spørgsmål besvares simpelthen ikke af indbyggede metrics, hvilket tvinger brugerne til at undersøge spændvidden. Som et resultat har vi en ekstremt brugerfjendtlig mekanisme.
Dette rejser spørgsmålet: hvad med komplekse interaktioner mellem forskellige tjenester styret af forskellige teams? Er det ikke sporvisning ikke anses for at være det mest passende værktøj til at fremhæve en sådan situation?
Mobiludviklere, ejere af statsløse tjenester, ejere af administrerede stateful-tjenester (som databaser) og platformsejere kan være interesserede i noget andet præsentation distribueret system; sporvisning er en for generisk løsning til disse fundamentalt forskellige behov. Selv i en meget kompleks mikroservicearkitektur behøver tjenesteejere ikke dyb viden om mere end to eller tre upstream- og downstream-tjenester. Grundlæggende behøver brugerne i de fleste scenarier kun at besvare spørgsmål vedr begrænset sæt af tjenester.
Det er som at se på en lille undergruppe af tjenester gennem et forstørrelsesglas for at undersøge det nærmere. Dette vil give brugeren mulighed for at stille mere presserende spørgsmål vedrørende den komplekse interaktion mellem disse tjenester og deres umiddelbare afhængigheder. Dette svarer til backtrace i serviceverdenen, hvor ingeniøren ved at forkert, og har også en vis forståelse for, hvad der sker i de omkringliggende tjenester at forstå hvorfor.
Den tilgang, jeg promoverer, er det stik modsatte af den top-down, traceview-baserede tilgang, hvor analysen starter med hele sporet og derefter gradvist arbejder ned til individuelle spænd. I modsætning hertil begynder en bottom-up-tilgang med at analysere et lille område tæt på den potentielle årsag til hændelsen og derefter udvide søgeområdet efter behov (med potentialet til at inddrage andre teams til at analysere en bredere vifte af tjenester). Den anden tilgang er bedre egnet til hurtigt at teste indledende hypoteser. Når der er opnået konkrete resultater, vil det være muligt at gå videre til en mere målrettet og detaljeret analyse.
Opbygning af en topologi
Tjenestespecifikke visninger kan være utrolig nyttige, hvis brugeren ved det hvilken en tjeneste eller gruppe af tjenester er ansvarlig for at øge ventetiden eller forårsage fejl. I et komplekst system kan det dog være en ikke-triviel opgave at identificere den fornærmende tjeneste under en fejl, især hvis der ikke blev rapporteret fejlmeddelelser fra tjenesterne.
Opbygning af en tjenestetopologi kan være en stor hjælp til at finde ud af, hvilken tjeneste, der oplever en stigning i fejlfrekvenser eller en stigning i latens, der får tjenesten til at blive mærkbart forringet. Når jeg taler om at bygge en topologi, mener jeg det ikke tjenester kort, der viser alle tjenester, der er tilgængelige i systemet og kendt for sine . Denne visning er ikke bedre end traceview baseret på en rettet acyklisk graf. I stedet vil jeg gerne se dynamisk genereret servicetopologi, baseret på visse attributter såsom fejlrate, responstid eller enhver brugerdefineret parameter, der hjælper med at afklare situationen med specifikke mistænkelige tjenester.
Lad os tage et eksempel. Lad os forestille os et hypotetisk nyhedssite. Hjemmesidetjeneste (Forside) udveksler data med Redis, med en anbefalingstjeneste, med en reklametjeneste og en videotjeneste. Videotjenesten tager videoer fra S3 og metadata fra DynamoDB. Anbefalingstjenesten modtager metadata fra DynamoDB, indlæser data fra Redis og MySQL og skriver beskeder til Kafka. Annoncetjenesten modtager data fra MySQL og skriver beskeder til Kafka.
Nedenfor er en skematisk repræsentation af denne topologi (mange kommercielle routing-programmer bygger topologien). Det kan være nyttigt, hvis du har brug for at forstå serviceafhængigheder. Dog under fejlretning, når en bestemt tjeneste (f.eks. en videotjeneste) udviser øget responstid, er en sådan topologi ikke særlig nyttig.
Servicediagram af et hypotetisk nyhedssite
Diagrammet nedenfor ville være bedre egnet. Der er et problem med tjenesten (Video) afbildet lige i midten. Brugeren bemærker det med det samme. Fra denne visualisering bliver det klart, at videotjenesten fungerer unormalt på grund af en stigning i S3-svartid, hvilket påvirker indlæsningshastigheden på en del af hovedsiden.
Dynamisk topologi, der kun viser "interessante" tjenester
Dynamisk genererede topologier kan være mere effektive end statiske servicekort, især i elastiske infrastrukturer med automatisk skalering. Evnen til at sammenligne og kontrastere servicetopologier giver brugeren mulighed for at stille mere relevante spørgsmål. Mere præcise spørgsmål om systemet vil med større sandsynlighed føre til en bedre forståelse af, hvordan systemet fungerer.
Sammenlignende display
En anden nyttig visualisering ville være en sammenlignende visning. I øjeblikket er spor ikke særlig velegnede til side-by-side sammenligninger, så sammenligninger er normalt spænder over. Og hovedideen i denne artikel er netop, at spændvidden er for lav til at udtrække den mest værdifulde information fra sporingsresultaterne.
At sammenligne to spor kræver ikke grundlæggende nye visualiseringer. Faktisk er noget som et histogram, der repræsenterer den samme information som en sporingsvisning, tilstrækkeligt. Overraskende nok kan selv denne simple metode bringe meget mere frugt end blot at studere to spor hver for sig. Endnu mere kraftfuld ville være muligheden visualisere sammenligning af spor I alt. Det ville være yderst nyttigt at se, hvordan en nyligt implementeret databasekonfigurationsændring for at aktivere GC (garbage collection) påvirker responstiden for en downstream-tjeneste i en skala på flere timer. Hvis det, jeg beskriver her, lyder som en A/B-analyse af virkningen af infrastrukturændringer i mange tjenester ved at bruge sporresultaterne, så er du ikke for langt fra sandheden.
Konklusion
Jeg stiller ikke spørgsmålstegn ved nytten af selve sporingen. Jeg mener oprigtigt, at der ikke er nogen anden metode til at indsamle data så rig, kausal og kontekstuel som den, der er indeholdt i et spor. Jeg mener dog også, at alle sporingsløsninger bruger disse data ekstremt ineffektivt. Så længe sporingsværktøjer forbliver fast på traceview-repræsentationen, vil de være begrænset i deres evne til at få mest muligt ud af den værdifulde information, der kan udvindes fra dataene i sporene. Derudover er der risiko for at videreudvikle en fuldstændig uvenlig og uintuitiv visuel grænseflade, der vil begrænse brugerens mulighed for at fejlfinde fejl i applikationen kraftigt.
Fejlretning af komplekse systemer, selv med de nyeste værktøjer, er utroligt vanskeligt. Værktøjer skal hjælpe udvikleren med at formulere og teste en hypotese, yder aktivt relevante oplysninger, identifikation af afvigende værdier og notering af træk ved fordelingen af forsinkelser. For at sporing skal blive det foretrukne værktøj for udviklere, når de skal fejlfinde produktionsfejl eller løse problemer, der spænder over flere tjenester, er der brug for originale brugergrænseflader og visualiseringer, som er mere i overensstemmelse med den mentale model hos udviklerne, der skaber og driver disse tjenester.
Det vil kræve en betydelig mental indsats at designe et system, der vil repræsentere de forskellige signaler, der er tilgængelige i sporingsresultaterne på en måde, der er optimeret til let analyse og slutning. Du skal tænke over, hvordan du abstraherer systemtopologien under fejlfinding på en måde, der hjælper brugeren med at overvinde blinde vinkler uden at se på individuelle spor eller spænd.
Vi har brug for gode abstraktions- og lagdelingsevner (især i brugergrænsefladen). Dem, der ville passe godt ind i en hypotese-drevet debugging-proces, hvor du iterativt kan stille spørgsmål og teste hypoteser. De vil ikke automatisk løse alle observerbarhedsproblemer, men de vil hjælpe brugerne med at skærpe deres intuition og formulere smartere spørgsmål. Jeg efterlyser en mere gennemtænkt og innovativ tilgang til visualisering. Her er der en reel udsigt til at udvide horisonten.
PS fra oversætteren
Læs også på vores blog:
- «";
- «";
- «'.
Kilde: www.habr.com