Merk. overs.: Forfatteren av dette materialet er Cindy Sridharan, en ingeniør hos imgix som spesialiserer seg på API-utvikling og spesielt mikrotjenestetesting. I dette materialet deler hun sin detaljerte visjon om aktuelle problemer innen distribuert sporing, hvor det etter hennes mening mangler virkelig effektive verktøy for å løse presserende problemer.
[Illustrasjon hentet fra om distribuert sporing.]
Det antas at vanskelig å gjennomføre, og avkastningen på det . Det er mange grunner til at sporing er problematisk, ofte med henvisning til arbeidskraften som er involvert i å konfigurere hver systemkomponent til å overføre de riktige overskriftene med hver forespørsel. Selv om dette problemet eksisterer, er det på ingen måte uoverkommelig. Forresten, det forklarer ikke hvorfor utviklere ikke liker sporing (selv når det allerede fungerer).
Hovedutfordringen med distribuert sporing er ikke å samle inn data, standardisere formater for distribusjon og presentasjon av resultater, eller å bestemme når, hvor og hvordan man skal prøve. Jeg prøver ikke å forestille meg triviell disse "forståelighetsproblemene" er faktisk ganske betydelige tekniske og (hvis vi vurderer virkelig åpen kildekode) ) politiske utfordringer som må overvinnes for at disse problemene skal anses løst.
Men hvis vi ser for oss at alle disse problemene er løst, er det stor sannsynlighet for at ingenting vil endre seg vesentlig mht. sluttbrukeropplevelse. Sporing er kanskje fortsatt ikke praktisk nyttig i de vanligste feilsøkingsscenariene – selv etter at den har blitt distribuert.
Et så annerledes spor
Distribuert sporing inkluderer flere forskjellige komponenter:
- utstyre applikasjoner og mellomvare med kontrollverktøy;
- distribuert kontekstoverføring;
- samling av spor;
- spor lagring;
- deres utvinning og visualisering.
Mye snakk om distribuert sporing har en tendens til å behandle det som en slags unær operasjon hvis eneste formål er å hjelpe til med å diagnostisere systemet fullt ut. Dette skyldes i stor grad hvordan ideer om distribuert sporing har blitt dannet historisk. I , laget da Zipkin-kildene ble åpnet, ble det nevnt at det [Zipkin] gjør Twitter raskere. De første kommersielle tilbudene for sporing ble også promotert som .
Merk. overs.: For å gjøre ytterligere tekst lettere å forstå, la oss definere to grunnleggende termer iht :
- Span — det grunnleggende elementet i distribuert sporing. Det er en beskrivelse av en bestemt arbeidsflyt (for eksempel en databasespørring) med navn, start- og sluttider, tagger, logger og kontekst.
- Spenn inneholder vanligvis lenker til andre span, slik at flere span kan kombineres til Trace — visualisering av levetiden til en forespørsel når den beveger seg gjennom et distribuert system.
Spor inneholder utrolig verdifulle data som kan hjelpe med oppgaver som produksjonstesting, katastrofegjenopprettingstesting, feilinjeksjonstesting, etc. Faktisk bruker noen selskaper allerede sporing til lignende formål. La oss begynne med har andre bruksområder enn å flytte spenn til lagringssystemet:
- For eksempel Uber sporingsresultater for å skille mellom testtrafikk og produksjonstrafikk.
- Facebook spore data for kritisk baneanalyse og for trafikkveksling under vanlige katastrofegjenopprettingstester.
- Også sosialt nettverk Jupyter-notatbøker som lar utviklere kjøre vilkårlige spørringer på sporingsresultater.
- Følgere (Lineage Driven Failure Injection) distribuerte spor for testing med feilinjeksjon.
Ingen av alternativene ovenfor gjelder fullstendig for scenariet feilsøking, der ingeniøren prøver å løse problemet ved å se på sporet.
Når det kommer ennå når feilsøkingsskriptet, forblir det primære grensesnittet diagrammet sporvisning (selv om noen også kaller det "Gantt-diagram" eller "fossefallsdiagram"). Under sporvisning я alle spennene og tilhørende metadata som til sammen utgjør sporet. Hvert åpen kildekode-sporingssystem, så vel som enhver kommersiell sporingsløsning, tilbyr en sporvisning brukergrensesnitt for visualisering, detaljering og filtrering av spor.
Problemet med alle sporingssystemene jeg har sett så langt er at resultatet visualisering (traceview) reflekterer nesten fullstendig funksjonene i sporgenereringsprosessen. Selv når alternative visualiseringer er foreslått: varmekart, tjenestetopologier, latenshistogrammer, kommer de likevel til slutt ned til sporvisning.
I det siste jeg som de fleste "innovasjoner" i UI/UX-sporing ser ut til å være begrenset til ekstra metadata i sporet, investerer i dem informasjon med høy kardinalitet (høy kardinalitet) eller gi muligheten til å gå ned i spesifikke spenn eller kjøre spørringer inter- og intra-trace... Hvor sporvisning forblir det primære visualiseringsverktøyet. Så lenge denne tilstanden fortsetter, vil distribuert sporing (i beste fall) ta 4. plass som et feilsøkingsverktøy, etter metrikk, logger og stabelspor, og i verste fall vil det vise seg å være bortkastet penger og tid.
Problem med traceview
skjebne sporvisning — gi et fullstendig bilde av bevegelsen av en enkelt forespørsel på tvers av alle komponenter i det distribuerte systemet som den er relatert til. Noen mer avanserte sporingssystemer lar deg bore ned i individuelle spenn og se et sammenbrudd over tid innenfor én prosess (når spenn har funksjonelle grenser).
Den grunnleggende forutsetningen for mikrotjenestearkitektur er ideen om at organisasjonsstrukturen vokser med bedriftens behov. Tilhengere av mikrotjenester hevder at distribusjon av ulike forretningsoppgaver til individuelle tjenester gjør det mulig for små, autonome utviklingsteam å kontrollere hele livssyklusen til slike tjenester, noe som gir dem muligheten til uavhengig å bygge, teste og distribuere disse tjenestene. Ulempen med denne distribusjonen er imidlertid tap av informasjon om hvordan hver tjeneste samhandler med andre. I slike forhold hevder distribuert sporing å være et uunnværlig verktøy for feilsøking komplekse interaksjoner mellom tjenester.
Hvis du virkelig , da er ikke en eneste person i stand til å holde det i hodet fullstendig bilde. Faktisk er det å utvikle et verktøy basert på antakelsen om at det til og med er mulig noe av et antimønster (en ineffektiv og uproduktiv tilnærming). Ideelt sett krever feilsøking et verktøy som hjelper begrense søkeområdet ditt, slik at ingeniører kan fokusere på et undersett av dimensjoner (tjenester/brukere/verter osv.) som er relevante for problemscenarioet som vurderes. Når man skal fastslå årsaken til en feil, er det ikke nødvendig at ingeniører forstår hva som skjedde under alle tjenester på en gang, siden et slikt krav ville motsi selve ideen om mikrotjenestearkitektur.
Traceview er imidlertid det nemlig Dette. Ja, noen sporingssystemer tilbyr komprimerte sporingsvisninger når antallet spenn i sporet er så stort at de ikke kan vises i én visualisering. Men på grunn av den store mengden informasjon som finnes selv i en slik nedstrippet visualisering, er ingeniører fortsatt tvunget "sile" det, manuelt begrense utvalget til et sett med tjenester som er kilder til problemer. Dessverre, på dette feltet, er maskiner mye raskere enn mennesker, mindre utsatt for feil, og resultatene deres er mer repeterbare.
En annen grunn til at jeg tror traceview er feil, er fordi det ikke er bra for hypotesedrevet feilsøking. I kjernen er feilsøking iterativ en prosess som starter med en hypotese, etterfulgt av verifisering av ulike observasjoner og fakta hentet fra systemet langs ulike vektorer, konklusjoner/generaliseringer og videre vurdering av hypotesens sannhet.
Opportunity raskt og billig teste hypoteser og forbedre den mentale modellen tilsvarende er hjørnestein feilsøking Ethvert feilsøkingsverktøy bør være interaktiv og begrense søkeområdet eller, i tilfelle en falsk kundeemne, la brukeren gå tilbake og fokusere på et annet område av systemet. Det perfekte verktøyet vil gjøre dette proaktivt, umiddelbart trekke brukerens oppmerksomhet til potensielle problemområder.
Akk, sporvisning kan ikke kalles et verktøy med et interaktivt grensesnitt. Det beste du kan håpe på når du bruker det, er å finne en kilde til økt ventetid og se på alle mulige tagger og logger knyttet til den. Dette hjelper ikke ingeniøren med å identifisere mønstre i trafikken, for eksempel detaljene i forsinkelsesfordelingen, eller oppdage korrelasjoner mellom ulike målinger. kan hjelpe å omgå noen av disse problemene. Egentlig, vellykket analyse ved hjelp av maskinlæring for å identifisere unormale spenn og identifisere et undersett av tagger som kan være assosiert med unormal oppførsel. Imidlertid har jeg ennå ikke sett overbevisende visualiseringer av maskinlæring eller datautvinningsfunn brukt på spenn som er vesentlig forskjellig fra en traceview eller en DAG (rettet asyklisk graf).
Spennene er for lave
Det grunnleggende problemet med traceview er det spenner er for lavt nivå primitiver for både latensanalyse og rotårsaksanalyse. Det er som å analysere individuelle prosessorkommandoer for å prøve å løse et unntak, vel vitende om at det er mye høyere nivåverktøy som backtrace som er mye mer praktisk å jobbe med.
Dessuten vil jeg ta meg friheten til å hevde følgende: ideelt sett trenger vi ikke hele bildet skjedde i løpet av forespørselens livssyklus, som er representert av moderne sporingsverktøy. I stedet kreves det en form for abstraksjon på høyere nivå som inneholder informasjon om hva gikk galt (ligner på tilbakesporing), sammen med en viss kontekst. I stedet for å se hele sporet, foretrekker jeg å se det часть, der noe interessant eller uvanlig skjer. For øyeblikket utføres søket manuelt: ingeniøren mottar sporet og analyserer spennene uavhengig på jakt etter noe interessant. Tilnærmingen til folk som stirrer på spenn i individuelle spor i håp om å oppdage mistenkelig aktivitet skalerer ikke i det hele tatt (spesielt når de må forstå alle metadataene som er kodet i forskjellige spenn, for eksempel spenn-ID, RPC-metodenavn, spennvarighet 'a, logger, tagger osv.).
Alternativer til traceview
Sporingsresultater er mest nyttige når de kan visualiseres på en måte som gir ikke-triviell innsikt i hva som skjer i sammenkoblede deler av systemet. Inntil dette skjer, gjenstår i stor grad feilsøkingsprosessen inert og avhenger av brukerens evne til å legge merke til de riktige korrelasjonene, sjekke de riktige delene av systemet, eller sette brikkene i puslespillet sammen – i motsetning til verktøy, som hjelper brukeren med å formulere disse hypotesene.
Jeg er ikke en visuell designer eller UX-spesialist, men i neste avsnitt vil jeg dele noen ideer om hvordan disse visualiseringene kan se ut.
Fokuser på spesifikke tjenester
I en tid hvor bransjen konsoliderer seg rundt ideer , virker det rimelig at individuelle team bør prioritere å sikre at tjenestene deres er på linje med disse målene. Det følger at serviceorientert visualisering er best egnet for slike team.
Spor, spesielt uten prøvetaking, er en skattekiste av informasjon om hver komponent i et distribuert system. Denne informasjonen kan mates til en utspekulert prosessor som vil forsyne brukerne serviceorientert funn. De kan identifiseres på forhånd - selv før brukeren ser på sporene:
- Diagrammer for latensdistribusjon kun for svært fremtredende forespørsler (avvikende forespørsler);
- Diagrammer over forsinkelsesfordeling for tilfeller der tjeneste SLO-mål ikke oppnås;
- De mest "generelle", "interessante" og "rare" taggene i søk som oftest gjentas;
- Latency breakdown for tilfeller hvor avhengig av tjenester når ikke sine SLO-mål;
- Latency breakdown for ulike nedstrømstjenester.
Noen av disse spørsmålene blir rett og slett ikke besvart av innebygde beregninger, noe som tvinger brukerne til å granske spenn. Som et resultat har vi en ekstremt brukerfiendtlig mekanisme.
Dette reiser spørsmålet: hva med komplekse interaksjoner mellom ulike tjenester kontrollert av ulike team? Ikke sant sporvisning regnes ikke som det mest hensiktsmessige verktøyet for å synliggjøre en slik situasjon?
Mobilutviklere, eiere av statsløse tjenester, eiere av administrerte stateful-tjenester (som databaser) og plattformeiere kan være interessert i noe annet presentasjon distribuert system; sporvisning er en for generisk løsning for disse fundamentalt forskjellige behovene. Selv i en svært kompleks mikrotjenestearkitektur trenger ikke tjenesteeiere dyp kunnskap om mer enn to eller tre oppstrøms- og nedstrømstjenester. I hovedsak, i de fleste scenarier, trenger brukere bare å svare på spørsmål angående begrenset sett med tjenester.
Det er som å se på en liten undergruppe av tjenester gjennom et forstørrelsesglass for å granske det. Dette vil tillate brukeren å stille mer presserende spørsmål angående de komplekse interaksjonene mellom disse tjenestene og deres umiddelbare avhengigheter. Dette ligner på backtrace i tjenesteverdenen, der ingeniøren vet at feil, og har også en viss forståelse for hva som skjer i omkringliggende tjenester å forstå Hvorfor.
Tilnærmingen jeg fremmer er det stikk motsatte av den ovenfra-ned, traceview-baserte tilnærmingen, der analysen starter med hele sporet og deretter gradvis arbeider ned til individuelle spenn. I motsetning til dette begynner en nedenfra-og-opp-tilnærming med å analysere et lite område nær den potensielle årsaken til hendelsen, og deretter utvide søkeområdet etter behov (med potensialet for å bringe inn andre team for å analysere et bredere spekter av tjenester). Den andre tilnærmingen er bedre egnet for å raskt teste innledende hypoteser. Når konkrete resultater er oppnådd, vil det være mulig å gå videre til en mer fokusert og detaljert analyse.
Bygge en topologi
Tjenestespesifikke visninger kan være utrolig nyttige hvis brukeren vet hvilken en tjeneste eller gruppe av tjenester er ansvarlig for å øke ventetiden eller forårsake feil. I et komplekst system kan imidlertid identifisering av den fornærmende tjenesten være en ikke-triviell oppgave under en feil, spesielt hvis ingen feilmeldinger ble rapportert fra tjenestene.
Å bygge en tjenestetopologi kan være en stor hjelp for å finne ut hvilken tjeneste som opplever en økning i feilfrekvenser eller en økning i ventetid som får tjenesten til å bli merkbart forringet. Når jeg snakker om å bygge en topologi, mener jeg ikke tjenester kart, som viser alle tjenester som er tilgjengelige i systemet og kjent for sine . Denne visningen er ikke bedre enn traceview basert på en rettet asyklisk graf. I stedet vil jeg gjerne se dynamisk generert tjenestetopologi, basert på visse attributter som feilrate, responstid eller en hvilken som helst brukerdefinert parameter som hjelper med å avklare situasjonen med spesifikke mistenkelige tjenester.
La oss ta et eksempel. La oss forestille oss en hypotetisk nyhetsside. Hjemmesidetjeneste (Forside) utveksler data med Redis, med en anbefalingstjeneste, med en annonsetjeneste og en videotjeneste. Videotjenesten tar videoer fra S3 og metadata fra DynamoDB. Anbefalingstjenesten mottar metadata fra DynamoDB, laster data fra Redis og MySQL, og skriver meldinger til Kafka. Annonsetjenesten mottar data fra MySQL og skriver meldinger til Kafka.
Nedenfor er en skjematisk representasjon av denne topologien (mange kommersielle rutingprogrammer bygger topologien). Det kan være nyttig hvis du trenger å forstå tjenesteavhengigheter. Imidlertid under feilsøking, når en bestemt tjeneste (f.eks. en videotjeneste) viser økt responstid, er ikke en slik topologi særlig nyttig.
Tjenestediagram av et hypotetisk nyhetsnettsted
Diagrammet nedenfor ville være bedre egnet. Det er et problem med tjenesten (Video) avbildet midt i sentrum. Brukeren merker det umiddelbart. Fra denne visualiseringen blir det klart at videotjenesten fungerer unormalt på grunn av en økning i S3-svartid, noe som påvirker lastehastigheten til en del av hovedsiden.
Dynamisk topologi som viser bare "interessante" tjenester
Dynamisk genererte topologier kan være mer effektive enn statiske tjenestekart, spesielt i elastiske infrastrukturer med automatisk skalering. Evnen til å sammenligne og kontrastere tjenestetopologier lar brukeren stille mer relevante spørsmål. Mer presise spørsmål om systemet er mer sannsynlig å føre til en bedre forståelse av hvordan systemet fungerer.
Sammenlignende visning
En annen nyttig visualisering ville være en sammenlignende visning. Foreløpig er spor lite egnet for side-ved-side sammenligninger, så sammenligninger er vanligvis spenner. Og hovedideen med denne artikkelen er nettopp at spenn er for lavt til å trekke ut den mest verdifulle informasjonen fra sporingsresultatene.
Å sammenligne to spor krever ikke fundamentalt nye visualiseringer. Faktisk er noe sånt som et histogram som representerer den samme informasjonen som en traceview tilstrekkelig. Overraskende nok kan selv denne enkle metoden gi mye mer frukt enn bare å studere to spor hver for seg. Enda kraftigere ville være muligheten visualisere sammenligning av spor Totalt. Det ville være ekstremt nyttig å se hvordan en nylig distribuert databasekonfigurasjonsendring for å aktivere GC (søppelsamling) påvirker responstiden til en nedstrømstjeneste i en skala på flere timer. Hvis det jeg beskriver her høres ut som en A/B-analyse av virkningen av infrastrukturendringer i mange tjenester ved å bruke sporresultatene, er du ikke så langt fra sannheten.
Konklusjon
Jeg stiller ikke spørsmål ved nytten av selve sporingen. Jeg tror oppriktig at det ikke finnes noen annen metode for å samle inn data så rik, kausal og kontekstuell som den som finnes i et spor. Jeg tror imidlertid også at alle sporingsløsninger bruker disse dataene ekstremt ineffektivt. Så lenge sporingsverktøy forblir fast på traceview-representasjonen, vil de være begrenset i deres evne til å få mest mulig ut av den verdifulle informasjonen som kan trekkes ut fra dataene i sporene. I tillegg risikerer man å videreutvikle et helt uvennlig og lite intuitivt visuelt grensesnitt som sterkt vil begrense brukerens mulighet til å feilsøke feil i applikasjonen.
Å feilsøke komplekse systemer, selv med de nyeste verktøyene, er utrolig vanskelig. Verktøy skal hjelpe utvikleren med å formulere og teste en hypotese, gir aktivt relevant informasjon, identifisering av uteliggere og merking av funksjoner i fordelingen av forsinkelser. For at sporing skal bli det foretrukne verktøyet for utviklere når de skal feilsøke produksjonsfeil eller løse problemer som spenner over flere tjenester, trengs originale brukergrensesnitt og visualiseringer som er mer konsistente med den mentale modellen til utviklerne som lager og driver disse tjenestene.
Det vil kreve betydelig mental innsats å designe et system som vil representere de forskjellige signalene som er tilgjengelige i sporingsresultatene på en måte som er optimalisert for enkel analyse og slutning. Du må tenke på hvordan du abstraherer systemtopologien under feilsøking på en måte som hjelper brukeren med å overvinne blindsoner uten å se på individuelle spor eller spenn.
Vi trenger gode abstraksjons- og lagdelingsevner (spesielt i brukergrensesnittet). De som passer godt inn i en hypotesedrevet feilsøkingsprosess der du iterativt kan stille spørsmål og teste hypoteser. De vil ikke automatisk løse alle observerbarhetsproblemer, men de vil hjelpe brukere med å skjerpe intuisjonen og formulere smartere spørsmål. Jeg etterlyser en mer gjennomtenkt og innovativ tilnærming til visualisering. Det er et reelt perspektiv her for å utvide horisonten.
PS fra oversetter
Les også på bloggen vår:
- «";
- «";
- «'.
Kilde: www.habr.com