Opmerking. vert.: De auteur van dit materiaal is Cindy Sridharan, een ingenieur bij imgix die gespecialiseerd is in API-ontwikkeling en in het bijzonder het testen van microservices. In dit materiaal deelt ze haar gedetailleerde visie op de huidige problemen op het gebied van gedistribueerde tracering, waar er naar haar mening een gebrek is aan echt effectieve hulpmiddelen om urgente problemen op te lossen.
[Illustratie overgenomen van over gedistribueerde tracering.]
Aangenomen wordt dat moeilijk uit te voeren en het rendement ervan . Er zijn veel redenen waarom tracering problematisch is, waarbij vaak wordt verwezen naar de arbeid die betrokken is bij het configureren van elke systeemcomponent om bij elk verzoek de juiste headers te verzenden. Hoewel dit probleem bestaat, is het zeker niet onoverkomelijk. Het verklaart overigens niet waarom ontwikkelaars niet echt van tracering houden (zelfs als het al functioneert).
De grootste uitdaging bij gedistribueerde tracering is niet het verzamelen van gegevens, het standaardiseren van formaten voor het distribueren en presenteren van resultaten, of het bepalen wanneer, waar en hoe er monsters moeten worden genomen. Ik probeer het me niet voor te stellen triviaal deze "begrijpelijkheidsproblemen" zijn in feite behoorlijk technisch en (als we echt Open Source overwegen) ) politieke uitdagingen die overwonnen moeten worden voordat deze problemen als opgelost kunnen worden beschouwd.
Als we ons echter voorstellen dat al deze problemen zijn opgelost, is de kans groot dat er niets wezenlijks zal veranderen eindgebruikerservaring. Tracering is mogelijk nog steeds niet van praktisch nut in de meest voorkomende foutopsporingsscenario's, zelfs nadat het is geïmplementeerd.
Zo'n ander spoor
Gedistribueerde tracering omvat verschillende afzonderlijke componenten:
- applicaties en middleware uitrusten met besturingstools;
- gedistribueerde contextoverdracht;
- verzameling van sporen;
- sporenopslag;
- hun extractie en visualisatie.
Veel gepraat over gedistribueerde tracering heeft de neiging om het te behandelen als een soort unaire operatie waarvan het enige doel is om een volledige diagnose van het systeem te helpen. Dit is grotendeels te danken aan de manier waarop ideeën over gedistribueerde tracering historisch zijn gevormd. IN , gemaakt toen de Zipkin-bronnen werden geopend, werd dat vermeld het [Zipkin] maakt Twitter sneller. De eerste commerciële aanbiedingen voor tracering werden ook gepromoot als .
Opmerking. vert.: Om verdere tekst begrijpelijker te maken, laten we twee basistermen definiëren op basis van :
- Span — het basiselement van gedistribueerde tracering. Het is een beschrijving van een bepaalde workflow (bijvoorbeeld een databasequery) met een naam, begin- en eindtijd, tags, logs en context.
- Spans bevatten doorgaans koppelingen naar andere spans, waardoor meerdere spans kunnen worden gecombineerd Opsporen — visualisatie van de levensduur van een verzoek terwijl het door een gedistribueerd systeem beweegt.
Traces bevatten ongelooflijk waardevolle gegevens die kunnen helpen bij taken zoals productietests, noodhersteltests, foutinjectietests, enz. Sommige bedrijven gebruiken tracering zelfs al voor soortgelijke doeleinden. Laten we beginnen heeft naast het simpelweg verplaatsen van overspanningen naar het opslagsysteem nog andere toepassingen:
- Uber bijvoorbeeld traceringsresultaten om onderscheid te maken tussen testverkeer en productieverkeer.
- Facebook traceergegevens voor analyse van kritieke paden en voor het schakelen van verkeer tijdens reguliere noodhersteltests.
- Ook sociaal netwerk Jupyter-notebooks waarmee ontwikkelaars willekeurige query's op traceerresultaten kunnen uitvoeren.
- aanhangers (Lineage Driven Failure-injectie) gedistribueerde sporen voor testen met foutinjectie.
Geen van de hierboven genoemde opties is volledig van toepassing op het scenario debuggen, waarbij de ingenieur het probleem probeert op te lossen door naar het spoor te kijken.
Als het komt nog het foutopsporingsscript bereikt, blijft de primaire interface het diagram traceview (hoewel sommigen het ook wel noemen "Gantt-diagram" of "watervaldiagram"). Onder traceview я alle spans en bijbehorende metadata die samen de trace vormen. Elk open source traceringssysteem, evenals elke commerciële traceringsoplossing, biedt een traceview gebruikersinterface voor het visualiseren, detailleren en filteren van sporen.
Het probleem met alle traceersystemen die ik tot nu toe heb gezien, is dat het resultaat visualisatie (traceview) weerspiegelt bijna volledig de kenmerken van het traceringsproces. Zelfs wanneer alternatieve visualisaties worden voorgesteld: heatmaps, servicetopologieën, latentiehistogrammen, komen deze uiteindelijk nog steeds neer op traceview.
In het verleden heb ik waartoe de meeste "innovaties" op het gebied van UI/UX-tracing beperkt lijken te zijn aanvullende metagegevens in trace, waarin informatie met een hoge kardinaliteit wordt geïnvesteerd (hoge kardinaliteit) of het bieden van de mogelijkheid om in te zoomen op specifieke bereiken of query's uit te voeren inter- en intra-trace... Waarin traceview blijft het belangrijkste visualisatiehulpmiddel. Zolang deze stand van zaken voortduurt, zal gedistribueerde tracering (op zijn best) de vierde plaats innemen als debugging-tool, na metrics, logs en stacktraces, en in het slechtste geval zal het een verspilling van geld en tijd blijken te zijn.
Probleem met traceview
lot traceview — een compleet beeld geven van de beweging van een enkel verzoek over alle componenten van het gedistribueerde systeem waarmee het verband houdt. Met sommige meer geavanceerde traceersystemen kunt u dieper ingaan op individuele overspanningen en een uitsplitsing in de tijd bekijken внутри één proces (wanneer overspanningen functionele grenzen hebben).
Het uitgangspunt van de microservices-architectuur is het idee dat de organisatiestructuur meegroeit met de behoeften van het bedrijf. Voorstanders van microservices beweren dat het verdelen van verschillende bedrijfstaken in individuele services kleine, autonome ontwikkelingsteams in staat stelt de gehele levenscyclus van dergelijke services te controleren, waardoor ze de mogelijkheid krijgen om deze services onafhankelijk te bouwen, testen en implementeren. Het nadeel van deze distributie is echter het verlies van informatie over hoe elke service met anderen samenwerkt. In dergelijke omstandigheden beweert gedistribueerde tracering een onmisbaar hulpmiddel te zijn debuggen complexe interacties tussen diensten.
Als je echt , dan kan geen enkele persoon het in zijn hoofd houden compleet afbeelding. In feite is het ontwikkelen van een instrument gebaseerd op de veronderstelling dat het zelfs maar mogelijk is iets van een anti-patroon (een ineffectieve en onproductieve aanpak). Idealiter vereist foutopsporing een hulpmiddel dat helpt verfijn uw zoekgebied, zodat ingenieurs zich kunnen concentreren op een subset van dimensies (services/gebruikers/hosts, enz.) die relevant zijn voor het probleemscenario dat wordt overwogen. Bij het vaststellen van de oorzaak van een storing hoeven technici niet te begrijpen wat er tijdens de storing is gebeurd alle diensten in één keer, aangezien een dergelijke vereiste in tegenspraak zou zijn met het hele idee van microservice-architectuur.
Traceview is dat echter wel namelijk Dit. Ja, sommige traceringssystemen bieden gecomprimeerde traceviews wanneer het aantal bereiken in de trace zo groot is dat ze niet in één visualisatie kunnen worden weergegeven. Maar vanwege de grote hoeveelheid informatie die zelfs in zo’n uitgeklede visualisatie zit, blijven ingenieurs nog steeds werken gedwongen ‘zift’ het, waarbij de selectie handmatig wordt beperkt tot een reeks services die een bron van problemen zijn. Helaas zijn machines op dit gebied veel sneller dan mensen, minder gevoelig voor fouten en zijn hun resultaten beter herhaalbaar.
Een andere reden waarom ik denk dat Traceview verkeerd is, is omdat het niet goed is voor op hypothesen gebaseerd debuggen. In de kern is het debuggen iteratief een proces dat begint met een hypothese, gevolgd door verificatie van verschillende observaties en feiten verkregen uit het systeem langs verschillende vectoren, conclusies/generalisaties en verdere beoordeling van de waarheid van de hypothese.
Kans snel en goedkoop het testen van hypothesen en het dienovereenkomstig verbeteren van het mentale model is dat wel hoeksteen debuggen Elke foutopsporingstool zou dat moeten zijn interactief en de zoekruimte verkleinen of, in het geval van een valse aanwijzing, de gebruiker toestaan terug te gaan en zich op een ander deel van het systeem te concentreren. Het perfecte hulpmiddel zal dit doen proactief, waardoor de aandacht van de gebruiker onmiddellijk op potentiële probleemgebieden wordt gevestigd.
Helaas, traceview kan geen tool met een interactieve interface worden genoemd. Het beste waar je op kunt hopen als je het gebruikt, is het vinden van een bron van verhoogde latentie en het bekijken van alle mogelijke tags en logs die eraan gekoppeld zijn. Dit helpt de ingenieur niet bij het identificeren patronen in het verkeer, zoals de details van de vertragingsverdeling, of om correlaties tussen verschillende metingen te detecteren. kan sommige van deze problemen helpen omzeilen. Echt, succesvolle analyse met behulp van machine learning om afwijkende reeksen te identificeren en een subset van tags te identificeren die mogelijk verband houden met afwijkend gedrag. Ik heb echter nog geen overtuigende visualisaties gezien van de bevindingen van machine learning of datamining, toegepast op reeksen die aanzienlijk verschillen van een traceview of een DAG (gerichte acyclische grafiek).
De overspanningen zijn te laag
Het fundamentele probleem met traceview is dat overspant zijn primitieven op een te laag niveau voor zowel latentieanalyse als analyse van de hoofdoorzaak. Het is net zoiets als het ontleden van individuele processoropdrachten om een uitzondering op te lossen, wetende dat er tools van veel hoger niveau zijn, zoals backtrace, die veel handiger zijn om mee te werken.
Bovendien ben ik zo vrij om het volgende te beweren: idealiter hebben we dat niet nodig volledig beeld vond plaats tijdens de levenscyclus van het verzoek, die wordt weergegeven door moderne traceringstools. In plaats daarvan is een vorm van abstractie op een hoger niveau vereist die informatie bevat over wat ging fout (vergelijkbaar met backtrace), samen met wat context. In plaats van het hele spoor te bekijken, zie ik het liever часть, waar iets interessants of ongewoons gebeurt. Momenteel wordt de zoekopdracht handmatig uitgevoerd: de ingenieur ontvangt het spoor en analyseert zelfstandig de overspanningen op zoek naar iets interessants. De aanpak van mensen die naar reeksen in individuele sporen staren in de hoop verdachte activiteit te detecteren, schaalt helemaal niet (vooral als ze betekenis moeten geven aan alle metagegevens die in verschillende reeksen zijn gecodeerd, zoals span-ID, RPC-methodenaam, spanduur 'a, logboeken, tags, enz.).
Alternatieven voor traceview
Traceerresultaten zijn het nuttigst wanneer ze kunnen worden gevisualiseerd op een manier die een niet-triviaal inzicht geeft in wat er gebeurt in onderling verbonden delen van het systeem. Totdat dit gebeurt, blijft het foutopsporingsproces grotendeels bestaan inert en hangt af van het vermogen van de gebruiker om de juiste correlaties op te merken, de juiste delen van het systeem te controleren of de stukjes van de puzzel in elkaar te zetten - in tegenstelling tot gereedschap, waardoor de gebruiker deze hypothesen kan formuleren.
Ik ben geen visueel ontwerper of UX-specialist, maar in de volgende sectie wil ik een paar ideeën delen over hoe deze visualisaties eruit zouden kunnen zien.
Focus op specifieke diensten
In een tijd waarin de industrie zich consolideert rond ideeën lijkt het redelijk dat individuele teams er prioriteit aan moeten geven om ervoor te zorgen dat hun diensten op deze doelstellingen zijn afgestemd. Het volgt dat service gericht visualisatie is het meest geschikt voor dergelijke teams.
Sporen, vooral zonder bemonstering, vormen een schat aan informatie over elk onderdeel van een gedistribueerd systeem. Deze informatie kan worden ingevoerd in een sluwe processor die de gebruikers zal voorzien service gericht bevindingen kunnen vooraf worden geïdentificeerd – zelfs voordat de gebruiker naar de sporen kijkt:
- Latentieverdelingsdiagrammen alleen voor zeer prominente verzoeken (uitschieterverzoeken);
- Diagrammen van de vertragingsverdeling voor gevallen waarin de SLO-doelen van de service niet worden bereikt;
- De meest “algemene”, “interessante” en “rare” tags in zoekopdrachten die het vaakst voorkomen worden herhaald;
- Uitsplitsing van de latentie voor gevallen waarin зависимости diensten bereiken hun SLO-doelen niet;
- Uitsplitsing van de latentie voor verschillende downstream-services.
Sommige van deze vragen worden eenvoudigweg niet beantwoord door ingebouwde statistieken, waardoor gebruikers gedwongen worden de spanwijdten onder de loep te nemen. Als gevolg hiervan hebben we een uiterst gebruikersvijandig mechanisme.
Dit roept de vraag op: hoe zit het met de complexe interacties tussen diverse diensten die door verschillende teams worden beheerd? Is het niet? traceview niet wordt beschouwd als het meest geschikte instrument om een dergelijke situatie onder de aandacht te brengen?
Mobiele ontwikkelaars, eigenaren van stateless services, eigenaren van beheerde stateful services (zoals databases) en platformeigenaren zijn mogelijk in iets anders geïnteresseerd presentatie gedistribueerd systeem; traceview is een te generieke oplossing voor deze fundamenteel verschillende behoeften. Zelfs in een zeer complexe microservice-architectuur hebben service-eigenaren geen diepgaande kennis nodig van meer dan twee of drie upstream- en downstream-services. In wezen hoeven gebruikers in de meeste scenario's alleen vragen te beantwoorden over beperkt aanbod aan diensten.
Het is alsof je door een vergrootglas naar een klein deel van de diensten kijkt om het nauwkeurig te onderzoeken. Hierdoor kan de gebruiker dringender vragen stellen over de complexe interacties tussen deze diensten en hun onmiddellijke afhankelijkheden. Dit is vergelijkbaar met backtrace in de dienstenwereld, waar de ingenieur het weet dat verkeerd, en heeft ook enig begrip van wat er in de omliggende diensten gebeurt om te begrijpen waarom.
De aanpak die ik promoot is precies het tegenovergestelde van de top-down, op traceview gebaseerde aanpak, waarbij de analyse begint met het gehele trace en vervolgens geleidelijk wordt uitgewerkt tot individuele reeksen. Een bottom-up benadering begint daarentegen met het analyseren van een klein gebied dicht bij de potentiële oorzaak van het incident, en breidt vervolgens de zoekruimte uit als dat nodig is (met de mogelijkheid om andere teams in te schakelen om een breder scala aan diensten te analyseren). De tweede benadering is beter geschikt voor het snel testen van initiële hypothesen. Zodra concrete resultaten zijn verkregen, is het mogelijk om over te gaan tot een meer gerichte en gedetailleerde analyse.
Een topologie bouwen
Servicespecifieke weergaven kunnen ongelooflijk nuttig zijn als de gebruiker dit weet die een dienst of een groep diensten is verantwoordelijk voor het verhogen van de latentie of het veroorzaken van fouten. In een complex systeem kan het identificeren van de overtredende service echter een niet-triviale taak zijn tijdens een storing, vooral als er geen foutmeldingen van de services zijn gerapporteerd.
Het bouwen van een servicetopologie kan een grote hulp zijn bij het uitzoeken welke service een piek in het foutpercentage ervaart of een toename in de latentie waardoor de service merkbaar verslechtert. Als ik het heb over het bouwen van een topologie, bedoel ik dat niet diensten kaart, waarbij elke service wordt weergegeven die beschikbaar is in het systeem en bekend staat om zijn . Deze weergave is niet beter dan traceview gebaseerd op een gerichte acyclische grafiek. In plaats daarvan zou ik het graag willen zien dynamisch gegenereerde servicetopologie, gebaseerd op bepaalde kenmerken, zoals het foutenpercentage, de responstijd of een door de gebruiker gedefinieerde parameter die de situatie bij specifieke verdachte services helpt verduidelijken.
Laten we een voorbeeld nemen. Laten we ons een hypothetische nieuwssite voorstellen. Startpaginaservice (voorpagina) wisselt gegevens uit met Redis, met een aanbevelingsdienst, met een advertentiedienst en een videodienst. De videoservice neemt video's van S3 en metadata van DynamoDB. De aanbevelingsservice ontvangt metadata van DynamoDB, laadt gegevens van Redis en MySQL en schrijft berichten naar Kafka. De advertentiedienst ontvangt gegevens van MySQL en schrijft berichten naar Kafka.
Hieronder vindt u een schematische weergave van deze topologie (veel commerciële routeringsprogramma's bouwen de topologie). Het kan handig zijn als u serviceafhankelijkheden wilt begrijpen. Echter, tijdens debuggenWanneer een bepaalde dienst (bijvoorbeeld een videodienst) een langere responstijd vertoont, is een dergelijke topologie niet erg nuttig.
Servicediagram van een hypothetische nieuwssite
Onderstaand schema zou beter geschikt zijn. Er is een probleem met de dienst (Video) precies in het midden afgebeeld. De gebruiker merkt het onmiddellijk. Uit deze visualisatie wordt duidelijk dat de videodienst abnormaal werkt vanwege een toename van de S3-responstijd, wat de laadsnelheid van een deel van de hoofdpagina beïnvloedt.
Dynamische topologie die alleen “interessante” services weergeeft
Dynamisch gegenereerde topologieën kunnen efficiënter zijn dan statische servicekaarten, vooral in elastische, automatisch schaalbare infrastructuren. Dankzij de mogelijkheid om servicetopologieën te vergelijken en te contrasteren, kan de gebruiker relevantere vragen stellen. Nauwkeurigere vragen over het systeem leiden waarschijnlijk tot een beter begrip van de werking van het systeem.
Vergelijkende weergave
Een andere nuttige visualisatie zou een vergelijkende weergave zijn. Momenteel zijn sporen niet erg geschikt voor vergelijkingen naast elkaar, dus vergelijkingen zijn dat meestal wel overspant. En het belangrijkste idee van dit artikel is juist dat de spans te laag zijn om de meest waardevolle informatie uit de traceerresultaten te halen.
Het vergelijken van twee sporen vereist geen fundamenteel nieuwe visualisaties. In feite is zoiets als een histogram dat dezelfde informatie weergeeft als een traceview voldoende. Verrassend genoeg kan zelfs deze eenvoudige methode veel meer resultaat opleveren dan het simpelweg afzonderlijk bestuderen van twee sporen. Nog krachtiger zou de mogelijkheid zijn visualiseren vergelijking van sporen In totaal. Het zou uiterst nuttig zijn om te zien hoe een onlangs geïmplementeerde wijziging in de databaseconfiguratie om GC (garbage collection) mogelijk te maken, de responstijd van een downstream-service op een schaal van enkele uren beïnvloedt. Als wat ik hier beschrijf klinkt als een A/B-analyse van de impact van veranderingen in de infrastructuur in veel diensten Als u de traceerresultaten gebruikt, bent u niet ver van de waarheid.
Conclusie
Ik twijfel niet aan het nut van de tracering zelf. Ik geloof oprecht dat er geen andere methode bestaat voor het verzamelen van gegevens die zo rijk, causaal en contextueel zijn als die welke in een spoor zijn vervat. Ik ben echter ook van mening dat alle traceringsoplossingen deze gegevens uiterst inefficiënt gebruiken. Zolang traceringstools vast blijven zitten aan de traceview-representatie, zullen ze beperkt zijn in hun vermogen om het maximale uit de waardevolle informatie te halen die uit de gegevens in de traces kan worden gehaald. Bovendien bestaat het risico dat er een volledig onvriendelijke en niet-intuïtieve visuele interface verder wordt ontwikkeld, waardoor de mogelijkheden van de gebruiker om fouten in de applicatie op te lossen ernstig worden beperkt.
Het debuggen van complexe systemen, zelfs met de nieuwste tools, is ongelooflijk moeilijk. Tools moeten de ontwikkelaar helpen bij het formuleren en testen van een hypothese, actief aanbieden relevante informatie, het identificeren van uitschieters en het noteren van kenmerken in de verdeling van vertragingen. Om ervoor te zorgen dat tracering het voorkeursinstrument wordt voor ontwikkelaars bij het oplossen van productiestoringen of het oplossen van problemen die meerdere services omvatten, zijn originele gebruikersinterfaces en visualisaties nodig die beter consistent zijn met het mentale model van de ontwikkelaars die deze services creëren en exploiteren.
Het zal een aanzienlijke mentale inspanning vergen om een systeem te ontwerpen dat de verschillende signalen die beschikbaar zijn in de traceringsresultaten representeert op een manier die is geoptimaliseerd voor gemakkelijke analyse en gevolgtrekking. U moet nadenken over hoe u de systeemtopologie tijdens het debuggen kunt abstraheren op een manier die de gebruiker helpt blinde vlekken te overwinnen zonder naar individuele sporen of reeksen te kijken.
We hebben goede abstractie- en gelaagdheidsmogelijkheden nodig (vooral in de gebruikersinterface). Zaken die goed passen in een hypothesegestuurd foutopsporingsproces, waarbij je iteratief vragen kunt stellen en hypothesen kunt testen. Ze zullen niet automatisch alle waarneembaarheidsproblemen oplossen, maar ze zullen gebruikers helpen hun intuïtie aan te scherpen en slimmere vragen te formuleren. Ik pleit voor een meer doordachte en innovatieve benadering van visualisatie. Er is hier een reëel vooruitzicht om de horizon te verbreden.
PS van vertaler
Lees ook op onze blog:
- «";
- «";
- «.
Bron: www.habr.com