🥇Verspreide opsporing: ons het alles verkeerd gedoen

Let wel. vertaal.: Die skrywer van hierdie materiaal is Cindy Sridharan, 'n ingenieur by imgix wat spesialiseer in API-ontwikkeling en veral mikrodienstoetsing. In hierdie materiaal deel sy haar gedetailleerde visie van huidige probleme op die gebied van verspreide opsporing, waar daar na haar mening 'n gebrek is aan werklik effektiewe hulpmiddels om dringende probleme op te los.

[Illustrasie geneem uit ander materiaal oor verspreide opsporing.]

Daar word geglo dat verspreide opsporing moeilik om te implementeer, en die opbrengs daarop op sy beste twyfelagtig. Daar is baie redes waarom opsporing problematies is, met verwysing na die arbeid wat betrokke is by die opstel van elke stelselkomponent om die toepaslike kopskrifte met elke versoek te stuur. Alhoewel hierdie probleem wel bestaan, is dit geensins onoorkombaar nie. Terloops, dit verduidelik nie hoekom ontwikkelaars nie regtig van opsporing hou nie (selfs wanneer dit reeds funksioneer).

Die grootste uitdaging met verspreide opsporing is nie om data in te samel, formate te standaardiseer vir die verspreiding en aanbieding van resultate, of om te bepaal wanneer, waar en hoe om te monster nie. Ek probeer my nie voorstel nie triviale hierdie "verstaanbaarheidsprobleme" is in werklikheid nogal beduidende tegnies en (as ons werklik Oopbron oorweeg) standaarde en protokolle) politieke uitdagings wat oorkom moet word sodat hierdie probleme as opgelos beskou kan word.

As ons ons egter verbeel dat al hierdie probleme opgelos is, is daar 'n groot waarskynlikheid dat niks beduidend sal verander t.o.v. eindgebruikerservaring. Opsporing is dalk steeds nie van praktiese nut in die mees algemene ontfoutingscenario's nie - selfs nadat dit ontplooi is.

So 'n ander spoor

Verspreide opsporing sluit verskeie uiteenlopende komponente in:

toerus van toepassings en middelware met beheergereedskap;
verspreide konteksoordrag;
versameling van spore;
spoorberging;
hul onttrekking en visualisering.

Baie gepraat oor verspreide opsporing is geneig om dit te behandel as 'n soort unêre operasie waarvan die enigste doel is om die stelsel ten volle te diagnoseer. Dit is grootliks te wyte aan hoe idees oor verspreide opsporing histories gevorm is. IN bloginskrywings, gemaak toe die Zipkin-bronne oopgemaak is, is genoem dat dit [Zipkin] maak Twitter vinniger. Die eerste kommersiële aanbiedinge vir opsporing is ook bevorder as APM gereedskap.

Let wel. vertaal.: Om verdere teks makliker te verstaan, kom ons definieer twee basiese terme volgens OpenTracing-projekdokumentasie:

span — die basiese element van verspreide opsporing. Dit is 'n beskrywing van 'n sekere werkvloei (byvoorbeeld 'n databasisnavraag) met 'n naam, begin- en eindtye, etikette, logs en konteks.
Spasies bevat tipies skakels na ander spans, wat dit moontlik maak om verskeie streke in te kombineer Spoor — visualisering van die lewe van 'n versoek terwyl dit deur 'n verspreide sisteem beweeg.

Spore bevat ongelooflike waardevolle data wat kan help met take soos produksietoetsing, ramphersteltoetsing, foutinspuitingtoetsing, ens. Trouens, sommige maatskappye gebruik reeds opsporing vir soortgelyke doeleindes. Kom ons begin met universele konteks oordrag het ander gebruike behalwe om net spanne na die bergingstelsel te verskuif:

Byvoorbeeld, Uber gebruike naspeurresultate om tussen toetsverkeer en produksieverkeer te onderskei.
Facebook gebruike spoor data vir kritieke pad-analise en vir verkeerskakeling tydens gereelde ramphersteltoetse.
Ook sosiale netwerk van toepassing is Jupyter-notaboeke wat ontwikkelaars toelaat om arbitrêre navrae op spoorresultate uit te voer.
Aanhangers LDFI (Lyngedrewe mislukkingsinspuiting) gebruik versprei spore vir toetsing met foutinspuiting.

Geen van die opsies wat hierbo gelys is, is heeltemal van toepassing op die scenario nie ontfout, waartydens die ingenieur probeer om die probleem op te los deur na die spoor te kyk.

Wanneer dit kom nog die ontfoutingskrip bereik, bly die primêre koppelvlak die diagram spooraansig (alhoewel sommige dit ook noem "Gantt-kaart" of "waterval diagram"). Onder spooraansig я ek bedoel al die streke en gepaardgaande metadata wat saam die spoor uitmaak. Elke oopbron-nasporingstelsel, sowel as elke kommersiële opsporingsoplossing, bied 'n spooraansig gebruikerskoppelvlak vir die visualisering, detail en filter van spore.

Die probleem met al die opsporingstelsels wat ek tot dusver gesien het, is dat die gevolg visualisering (traceview) weerspieël amper heeltemal die kenmerke van die spoorgenereringsproses. Selfs wanneer alternatiewe visualiserings voorgestel word: hittekaarte, dienstopologieë, latensiehistogramme, kom dit steeds uiteindelik neer op spooraansig.

In die verlede het ek gekla waartoe die meeste "innovasies" in UI/UX-nasporing beperk blyk te wees Aanskakel bykomende metadata in spoor, belê in hulle inligting met 'n hoë kardinaliteit (hoë kardinaliteit) of die verskaffing van die vermoë om in spesifieke strekke te drill of navrae uit te voer inter- en intra-spoor... Waarin spooraansig bly die primêre visualiseringsinstrument. Solank hierdie toedrag van sake voortduur, sal verspreide opsporing (ten beste) die 4de plek inneem as 'n ontfoutingsinstrument, na metrieke, logs en stapelspore, en in die ergste geval sal dit 'n mors van geld en tyd blyk te wees.

Probleem met traceview

lot spooraansig — verskaf 'n volledige prentjie van die beweging van 'n enkele versoek oor alle komponente van die verspreide stelsel waarmee dit verband hou. Sommige meer gevorderde opsporingstelsels stel jou in staat om in individuele strekke te boor en 'n uiteensetting met verloop van tyd te sien binne een proses (wanneer streke funksionele grense het).

Die basiese uitgangspunt van mikrodienste-argitektuur is die idee dat die organisasiestruktuur groei met die behoeftes van die maatskappy. Voorstanders van mikrodienste voer aan dat die verspreiding van verskeie besigheidstake in individuele dienste klein, outonome ontwikkelingspanne in staat stel om die hele lewensiklus van sulke dienste te beheer, wat hulle die vermoë gee om onafhanklik daardie dienste te bou, toets en ontplooi. Die nadeel van hierdie verspreiding is egter die verlies aan inligting oor hoe elke diens met ander omgaan. In sulke omstandighede beweer verspreide opsporing 'n onontbeerlike hulpmiddel vir ontfout komplekse interaksies tussen dienste.

As jy regtig verbysterend komplekse verspreide stelsel, dan is nie 'n enkele mens in staat om dit in sy kop te hou nie voltooi prent. Trouens, die ontwikkeling van 'n instrument gebaseer op die aanname dat dit selfs moontlik is, is iets van 'n anti-patroon ('n oneffektiewe en onproduktiewe benadering). Ideaal gesproke vereis ontfouting 'n hulpmiddel wat help vernou jou soekgebied, sodat ingenieurs kan fokus op 'n subset van dimensies (dienste/gebruikers/gashere, ens.) wat relevant is tot die probleemscenario wat oorweeg word. Wanneer die oorsaak van 'n mislukking bepaal word, hoef ingenieurs nie te verstaan wat tydens die gebeur het nie alle dienste gelyktydig, aangesien so 'n vereiste die idee van mikrodiensargitektuur sou weerspreek.

Traceview is egter presies Hierdie. Ja, sommige opsporingstelsels bied saamgeperste spooraansigte wanneer die aantal streke in die spoor so groot is dat hulle nie in een visualisering vertoon kan word nie. As gevolg van die groot hoeveelheid inligting wat selfs in so 'n gestroopte visualisering vervat is, is ingenieurs egter steeds gedwing "sif" dit, wat die keuse handmatig verklein tot 'n stel dienste wat bronne van probleme is. Ongelukkig is masjiene in hierdie veld baie vinniger as mense, minder geneig tot foute, en hul resultate is meer herhaalbaar.

Nog 'n rede waarom ek dink dat traceview verkeerd is, is omdat dit nie goed is vir hipotese-gedrewe ontfouting nie. In sy kern is ontfouting iteratief 'n proses wat begin met 'n hipotese, gevolg deur verifikasie van verskeie waarnemings en feite verkry uit die sisteem langs verskillende vektore, gevolgtrekkings/veralgemenings en verdere beoordeling van die waarheid van die hipotese.

Geleentheid vinnig en goedkoop hipoteses te toets en die verstandelike model daarvolgens te verbeter hoeksteen ontfouting Enige ontfoutingsinstrument moet wees interaktief en vernou die soekruimte of, in die geval van 'n vals leidraad, laat die gebruiker toe om terug te gaan en op 'n ander area van die stelsel te fokus. Die perfekte hulpmiddel sal dit doen proaktief, wat die gebruiker se aandag onmiddellik op potensiële probleemareas vestig.

Helaas, spooraansig kan nie 'n instrument met 'n interaktiewe koppelvlak genoem word nie. Die beste waarop u kan hoop wanneer u dit gebruik, is om 'n bron van verhoogde latensie te vind en na al die moontlike etikette en logboeke wat daarmee geassosieer word, te kyk. Dit help nie die ingenieur om te identifiseer nie patrone in die verkeer, soos die besonderhede van die vertragingsverspreiding, of bespeur korrelasies tussen verskillende metings. Algemene spooranalise kan help om sommige van hierdie probleme te omseil. Regtig, daar is voorbeelde suksesvolle analise deur gebruik te maak van masjienleer om abnormale omvang te identifiseer en 'n subset van etikette te identifiseer wat met anomale gedrag geassosieer kan word. Ek het egter nog nie dwingende visualiserings van masjienleer- of data-ontginning-bevindinge gesien wat toegepas word op strekke wat aansienlik verskil van 'n spooraansig of 'n DAG (gerigte asikliese grafiek).

Spanwydte is te laag

Die fundamentele probleem met traceview is dit oorspan is te lae-vlak primitiewe vir beide latensie-analise en hoofoorsaak-analise. Dit is soos om individuele verwerker-opdragte te ontleed om 'n uitsondering te probeer oplos, met die wete dat daar baie hoër-vlak nutsgoed soos backtrace is wat baie geriefliker is om mee te werk.

Verder sal ek die vrymoedigheid neem om die volgende te beweer: ideaal gesproke het ons nie nodig nie volledige prentjie het plaasgevind tydens die versoeklewensiklus, wat deur moderne opsporingsinstrumente voorgestel word. In plaas daarvan word een of ander vorm van hoërvlak abstraksie vereis wat inligting bevat oor wat verkeerd gegaan (soortgelyk aan terugspoor), saam met 'n mate van konteks. In plaas daarvan om die hele spoor te kyk, verkies ek om dit te sien deel van, waar iets interessant of ongewoon gebeur. Tans word die soektog met die hand uitgevoer: die ingenieur ontvang die spoor en ontleed die streke onafhanklik op soek na iets interessants. Die benadering van mense wat na streke in individuele spore staar in die hoop om verdagte aktiwiteit op te spoor, skaal glad nie (veral wanneer hulle sin moet maak van al die metadata wat in verskillende strekke geënkodeer is, soos span-ID, RPC-metodenaam, spanduur 'a, logs, etikette, ens.).

Alternatiewe vir traceview

Spoorresultate is die nuttigste wanneer hulle gevisualiseer kan word op 'n manier wat nie-onbeduidende insig bied in wat in onderling gekoppelde dele van die stelsel gebeur. Totdat dit gebeur, bly die ontfoutingsproses grootliks oor inert en hang af van die gebruiker se vermoë om die regte korrelasies raak te sien, die regte dele van die stelsel na te gaan, of die stukkies van die legkaart bymekaar te sit - in teenstelling met instrument, wat die gebruiker help om hierdie hipoteses te formuleer.

Ek is nie 'n visuele ontwerper of UX-spesialis nie, maar in die volgende afdeling wil ek 'n paar idees deel oor hoe hierdie visualiserings kan lyk.

Fokus op spesifieke dienste

In 'n tyd wanneer die bedryf rondom idees konsolideer SLO (diensvlakdoelwitte) en SLI (diensvlakaanwysers), lyk dit redelik dat individuele spanne moet prioritiseer om te verseker dat hul dienste in lyn is met hierdie doelwitte. Dit volg daarop diensgerig visualisering is die beste geskik vir sulke spanne.

Spore, veral sonder steekproefneming, is 'n skatkis van inligting oor elke komponent van 'n verspreide stelsel. Hierdie inligting kan aan 'n slinkse verwerker gevoer word wat gebruikers sal voorsien diensgerig bevindings. Hulle kan vooraf geïdentifiseer word - selfs voordat die gebruiker na die spore kyk:

Vertragingsverspreidingsdiagramme slegs vir hoogs prominente versoeke (uitskietversoeke);
Diagramme van vertraging verspreiding vir gevalle wanneer diens SLO doelwitte nie bereik word nie;
Die mees "algemene", "interessante" en "vreemde" merkers in navrae wat die meeste word herhaal;
Latency uiteensetting vir gevalle waar afhangende van dienste bereik nie hul SLO-doelwitte nie;
Latency-ontleding vir verskeie stroomaf-dienste.

Sommige van hierdie vrae word eenvoudig nie deur ingeboude maatstawwe beantwoord nie, wat gebruikers dwing om spanne te ondersoek. As gevolg hiervan het ons 'n uiters gebruiker-vyandige meganisme.

Dit laat die vraag ontstaan: wat van komplekse interaksies tussen diverse dienste wat deur verskillende spanne beheer word? Is dit nie spooraansig word nie as die mees geskikte hulpmiddel beskou om so 'n situasie uit te lig nie?

Mobiele ontwikkelaars, eienaars van staatlose dienste, eienaars van bestuurde staatsdienste (soos databasisse) en platformeienaars mag dalk in iets anders belangstel voorlegging verspreide stelsel; spooraansig is 'n te generiese oplossing vir hierdie fundamenteel verskillende behoeftes. Selfs in 'n baie komplekse mikrodiensargitektuur het dienseienaars nie diepgaande kennis van meer as twee of drie stroomop- en stroomafdienste nodig nie. In die meeste scenario's hoef gebruikers in wese net vrae te beantwoord oor beperkte stel dienste.

Dit is soos om na 'n klein subset van dienste deur 'n vergrootglas te kyk om dit noukeurig te ondersoek. Dit sal die gebruiker in staat stel om meer dringende vrae te vra oor die komplekse interaksies tussen hierdie dienste en hul onmiddellike afhanklikhede. Dit is soortgelyk aan terugspoor in die dienstewêreld, waar die ingenieur weet dat verkeerd is, en het ook 'n mate van begrip van wat in omliggende dienste gebeur om te verstaan hoekom.

Die benadering wat ek bevorder, is presies die teenoorgestelde van die top-down, traceview-gebaseerde benadering, waar die ontleding met die hele spoor begin en dan geleidelik afwerk na individuele streke. Daarteenoor begin ’n onder-na-bo-benadering deur ’n klein area naby die potensiële oorsaak van die voorval te ontleed, en brei dan die soekruimte uit soos nodig (met die potensiaal om ander spanne in te bring om ’n breër reeks dienste te ontleed). Die tweede benadering is beter geskik om aanvanklike hipoteses vinnig te toets. Sodra konkrete resultate verkry is, sal dit moontlik wees om na 'n meer doelgerigte en gedetailleerde ontleding oor te gaan.

Die bou van 'n topologie

Diensspesifieke aansigte kan ongelooflik nuttig wees as die gebruiker weet wat 'n diens of groep dienste is verantwoordelik vir die verhoging van latensie of om foute te veroorsaak. In 'n komplekse stelsel kan die identifisering van die oortredende diens egter 'n nie-triviale taak wees tydens 'n mislukking, veral as geen foutboodskappe vanaf die dienste gerapporteer is nie.

Die bou van 'n dienstopologie kan 'n groot hulp wees om uit te vind watter diens 'n styging in foutkoerse ervaar of 'n toename in latensie wat veroorsaak dat die diens merkbaar verswak. As ek praat oor die bou van 'n topologie, bedoel ek nie dienste kaart, wat elke diens wat in die stelsel beskikbaar is en daarvoor bekend is, vertoon kaarte van argitektuur in die vorm van 'n doodster. Hierdie aansig is niks beter as traceview gebaseer op 'n gerigte asikliese grafiek nie. In plaas daarvan sal ek graag wil sien dinamies gegenereerde dienstopologie, gebaseer op sekere eienskappe soos foutkoers, reaksietyd of enige gebruikergedefinieerde parameter wat help om die situasie met spesifieke verdagte dienste op te klaar.

Kom ons neem 'n voorbeeld. Kom ons stel ons 'n hipotetiese nuuswebwerf voor. Tuisblad diens (voorblad) ruil data uit met Redis, met 'n aanbevelingsdiens, met 'n advertensiediens en 'n videodiens. Die videodiens neem video's vanaf S3 en metadata van DynamoDB. Die aanbevelingsdiens ontvang metadata van DynamoDB, laai data vanaf Redis en MySQL, en skryf boodskappe aan Kafka. Die advertensiediens ontvang data van MySQL en skryf boodskappe aan Kafka.

Hieronder is 'n skematiese voorstelling van hierdie topologie (baie kommersiële roeteprogramme bou die topologie). Dit kan nuttig wees as jy diensafhanklikhede moet verstaan. Gedurende ontfout, wanneer 'n sekere diens (sê 'n videodiens) verhoogde reaksietyd toon, is so 'n topologie nie baie nuttig nie.

Diensdiagram van 'n hipotetiese nuuswebwerf

Die diagram hieronder sal beter gepas wees. Daar is 'n probleem met die diens (Video) reg in die middel uitgebeeld. Die gebruiker merk dit dadelik op. Uit hierdie visualisering word dit duidelik dat die videodiens abnormaal werk as gevolg van 'n toename in S3-reaksietyd, wat die laaispoed van 'n deel van die hoofblad beïnvloed.

Dinamiese topologie wat slegs "interessante" dienste vertoon

Dinamies gegenereerde topologieë kan meer doeltreffend wees as statiese dienskaarte, veral in elastiese, outo-skaal infrastruktuur. Die vermoë om dienstopologieë te vergelyk en te kontrasteer stel die gebruiker in staat om meer relevante vrae te vra. Meer presiese vrae oor die stelsel sal waarskynlik lei tot 'n beter begrip van hoe die stelsel werk.

Vergelykende vertoning

Nog 'n nuttige visualisering sou 'n vergelykende vertoning wees. Tans is spore nie baie geskik vir sy-aan-sy vergelykings nie, so vergelykings is gewoonlik oorspan. En die hoofgedagte van hierdie artikel is juis dat streke te laag is om die waardevolste inligting uit die spoorresultate te onttrek.

Om twee spore te vergelyk, vereis nie fundamenteel nuwe visualiserings nie. Trouens, iets soos 'n histogram wat dieselfde inligting as 'n spooraansig verteenwoordig, is voldoende. Verbasend genoeg kan selfs hierdie eenvoudige metode baie meer vrugte oplewer as om bloot twee spore afsonderlik te bestudeer. Selfs kragtiger sou die moontlikheid wees visualiseer vergelyking van spore In totaal. Dit sal uiters nuttig wees om te sien hoe 'n onlangs ontplooide databasiskonfigurasieverandering om GC (vullisversameling) moontlik te maak, die reaksietyd van 'n stroomafdiens op 'n skaal van etlike ure beïnvloed. As wat ek hier beskryf klink soos 'n A/B-ontleding van die impak van infrastruktuurveranderinge in baie dienste deur die spoorresultate te gebruik, dan is jy nie te ver van die waarheid nie.

Gevolgtrekking

Ek bevraagteken nie die bruikbaarheid van die opsporing self nie. Ek glo opreg dat daar geen ander metode is om data so ryk, kousaal en kontekstueel in te samel as wat in 'n spoor vervat is nie. Ek glo egter ook dat alle opsporingsoplossings hierdie data uiters ondoeltreffend gebruik. Solank as wat opsporingsinstrumente op die traceview-voorstelling vas bly, sal hulle beperk word in hul vermoë om die meeste van die waardevolle inligting te maak wat uit die data vervat in die spore onttrek kan word. Daarbenewens is daar 'n risiko om 'n heeltemal onvriendelike en onintuïtiewe visuele koppelvlak verder te ontwikkel wat die gebruiker se vermoë om foute in die toepassing op te los, ernstig sal beperk.

Om komplekse stelsels te ontfout, selfs met die nuutste gereedskap, is ongelooflik moeilik. Gereedskap moet die ontwikkelaar help om 'n hipotese te formuleer en te toets, aktief voorsien relevante inligting, identifisering van uitskieters en let op kenmerke in die verspreiding van vertragings. Vir die opsporing om die keuseinstrument vir ontwikkelaars te word wanneer produksiefoute opgespoor word of probleme opgelos word wat oor verskeie dienste strek, is oorspronklike gebruikerskoppelvlakke en visualiserings nodig wat meer ooreenstem met die verstandelike model van die ontwikkelaars wat daardie dienste skep en bedryf.

Dit sal aansienlike verstandelike inspanning verg om 'n stelsel te ontwerp wat die verskillende seine wat beskikbaar is in die spoorresultate sal verteenwoordig op 'n manier wat geoptimaliseer is vir gemak van analise en afleiding. Jy moet dink oor hoe om die stelseltopologie tydens ontfouting te abstraheer op 'n manier wat die gebruiker help om blindekolle te oorkom sonder om na individuele spore of streke te kyk.

Ons benodig goeie abstraksie- en lae-vermoëns (veral in die UI). Een wat goed sal pas in 'n hipotese-gedrewe ontfoutingsproses waar jy iteratief vrae kan vra en hipoteses kan toets. Hulle sal nie outomaties alle waarneembaarheidsprobleme oplos nie, maar hulle sal gebruikers help om hul intuïsie op te skerp en slimmer vrae te formuleer. Ek vra vir 'n meer deurdagte en innoverende benadering tot visualisering. Hier is 'n werklike vooruitsig om horisonne uit te brei.

Verspreide opsporing: ons het dit alles verkeerd gedoen