Note. iwwersat.: Den Auteur vun dësem Material ass d'Cindy Sridharan, en Ingenieur bei imgix, déi spezialiséiert ass op API Entwécklung a besonnesch Mikroservice Testen. An dësem Material, deelt si hir detailléiert Visioun vun aktuell Problemer am Beräich vun verdeelt Tracing, wou, hir Meenung, et feelt wierklech effikass Instrumenter fir dréngend Problemer ze léisen.
[Illustratioun geholl aus iwwer verdeelt Tracing.]
Et gëtt ugeholl schwéier ëmzesetzen, an de Retour op et . Et gi vill Grënn firwat Tracing problematesch ass, dacks zitéiert d'Aarbecht involvéiert fir all Systemkomponent ze konfiguréieren fir déi entspriechend Header mat all Ufro ze vermëttelen. Och wann dëse Problem existéiert, ass et op kee Fall oniwwergänglech. Iwwregens, et erkläert net firwat d'Entwéckler net wierklech gär Tracing hunn (och wann et scho funktionnéiert).
D'Haaptfuerderung mat verdeelt Tracing ass net Daten ze sammelen, Formater ze standardiséieren fir Resultater ze verdeelen an ze presentéieren, oder ze bestëmmen wéini, wou a wéi ech probéieren. Ech probéieren net virzestellen trivial dës "Verständnisproblemer" sinn tatsächlech zimlech bedeitend technesch an (wa mir wierklech Open Source berücksichtegen) ) politesch Erausfuerderungen déi iwwerwonne musse ginn, fir datt dës Problemer als geléist ugesi ginn.
Wa mir eis awer virstellen, datt all dës Problemer geléist sinn, besteet eng grouss Wahrscheinlechkeet, datt näischt wesentlech a punkto Enn Benotzer Erfahrung. Tracing ass vläicht nach ëmmer net praktesch Notzung an de meeschte verbreet Debugging Szenarien - och nodeems se ofgesat gouf.
Esou eng aner Spuer
Verdeelt Tracing enthält verschidde disparate Komponenten:
- Ausrüstung vun Uwendungen a Mëttelware mat Kontrollinstrumenter;
- verdeelt Kontext Transfert;
- Sammlung vu Spuren;
- Spuerlagerung;
- hir Extraktioun an Visualiséierung.
Vill Gespréicher iwwer verdeelt Tracing tendéieren et als eng Aart vun unärer Operatioun ze behandelen, deem säin eenzegen Zweck ass de System komplett ze diagnostizéieren. Dëst ass haaptsächlech wéinst wéi Iddien iwwer verdeelt Tracing historesch geformt goufen. IN , gemaach wann d'Zipkin Quellen opgemaach goufen, et gouf erwähnt datt et [Zipkin] mécht Twitter méi séier. Déi éischt kommerziell Affertexter fir Tracing goufen och gefördert als .
Note. iwwersat.: Fir weider Text méi einfach ze verstoen, loosst eis zwee Grondbegrëffer no definéieren :
- Span - d'Basiselement vun verdeelt Tracing. Et ass eng Beschreiwung vun engem bestëmmte Workflow (zum Beispill eng Datebank Ufro) mat engem Numm, Start- an Ennzäiten, Tags, Logbicher a Kontext.
- Spann enthalen typesch Linken op aner Spann, wat et erlaabt datt verschidde Spann an kombinéiert ginn Trace - Visualiséierung vum Liewen vun enger Ufro wéi se duerch e verdeelt System beweegt.
Spure enthalen onheemlech wäertvoll Donnéeën déi mat Aufgaben hëllefe kënnen wéi Produktiounstest, Katastropherhuelungstest, Fehlerinjektiounstest, etc. Tatsächlech benotze verschidde Firmen scho Tracing fir ähnlech Zwecker. Loosst d'mat ufänken huet aner Uwendungen nieft einfach Spannungen an de Späichersystem ze bewegen:
- Zum Beispill, Uber Tracing Resultater fir tëscht Testverkéier a Produktiounsverkéier z'ënnerscheeden.
- Facebook Spuerdaten fir kritesch Wee Analyse a fir Traffic Wiessel während reegelméissegen Katastroph Erhuelung Tester.
- Och sozialen Netzwierk Jupyter Notizbicher déi Entwéckler erlaben arbiträr Ufroen op Spuerresultater auszeféieren.
- Follower (Lineage Driven Failure Injection) verdeelt Spure fir Testen mat Feeler Sprëtz.
Keng vun den uewen opgezielt Optiounen gëlle ganz op de Szenario Debugging, während deem den Ingenieur probéiert de Problem ze léisen andeems hien d'Spuer kuckt.
Wann et kënnt nach erreecht de Debugging Skript, bleift déi primär Interface den Diagramm traceview (obwuel e puer et och nennen "Gantt Chart" oder "Waasserfall Diagramm"). Ënner traceview я all d'Spannungen an déi begleedend Metadaten, déi zesummen d'Spuer ausmaachen. All Open Source Tracing System, wéi och all kommerziell Tracing Léisung, bitt eng traceview User-Interface fir d'Spure ze visualiséieren, ze detailléiert an ze filteren.
De Problem mat all de Tracing Systemer déi ech bis elo gesinn hunn ass datt d'Resultat Visualiséierung (Traceview) bal komplett reflektéiert d'Features vum Trace Generatiounsprozess. Och wann alternativ Visualiséierunge proposéiert ginn: Hëtztkaarten, Servicetopologien, Latenzhistogramme, kommen se nach ëmmer op traceview.
An der Vergaangenheet hunn ech datt déi meescht "Innovatiounen" am UI / UX Tracing schéngen limitéiert ze sinn zousätzlech Metadaten a Spuer, investéieren an hinnen Informatioun mat héijer Kardinalitéit (héich Kardinalitéit) oder d'Fähigkeit ubitt fir a spezifesch Spannungen ze dréinen oder Ufroen auszeféieren inter- an intra-Trace... Woubäi traceview bleift de primäre Visualiséierungsinstrument. Soulaang dësen Zoustand weidergeet, wäert verdeelt Tracing (am beschten) 4. Plaz als Debugging-Tool huelen, no Metriken, Logbicher a Stackspuren, an am schlëmmste wäert et eng Verschwendung vu Suen an Zäit ginn.
Problem mat traceview
Zilsetzung traceview - liwwert e komplett Bild vun der Bewegung vun enger eenzeger Ufro iwwer all Komponente vum verdeelte System mat deem et verbonnen ass. E puer méi fortgeschratt Tracing Systemer erlaaben Iech an eenzel Spannungen erofzebauen an en Decompte iwwer Zäit ze gesinn innerhalb ee Prozess (wann Spann funktionell Grenzen hunn).
D'Basisviraussetzung vun der Mikroservicearchitektur ass d'Iddi datt d'Organisatiounsstruktur mat de Bedierfnesser vun der Firma wiisst. Verdeedeger vu Mikroservicer argumentéieren datt d'Verdeelung vu verschidde Geschäftsaufgaben an eenzel Servicer erlaabt kleng, autonom Entwécklungsteams de ganze Liewenszyklus vun esou Servicer ze kontrolléieren, wat hinnen d'Fäegkeet gëtt onofhängeg dës Servicer ze bauen, ze testen an z'installéieren. Wéi och ëmmer, den Nodeel vun dëser Verdeelung ass de Verloscht vun Informatioun iwwer wéi all Service mat aneren interagéiert. An esou Konditiounen, verdeelt Tracing behaapt en onverzichtbare Tool fir Debugging komplex Interaktiounen tëscht Servicer.
Wann Dir wierklech , da kann net eng eenzeg Persoun et am Kapp halen voll Bild. Tatsächlech ass d'Entwécklung vun engem Tool baséiert op der Virgab datt et souguer méiglech ass eppes vun engem Anti-Muster (eng ineffektiv an onproduktiv Approche). Idealerweis erfuerdert Debugging en Tool dat hëlleft Är Sich Beräich schmuel, sou datt d'Ingenieuren sech op eng Ënnerdeelung vun Dimensiounen konzentréieren (Servicer / Benotzer / Hosten, asw.) relevant fir de Problemszenario dat berécksiichtegt gëtt. Beim Bestëmmung vun der Ursaach vun engem Echec, Ingenieuren sinn net néideg ze verstoen wat während der geschitt ass all Servicer op eemol, well sou eng Fuerderung déi ganz Iddi vun der Mikroservicearchitektur widdersprécht.
Wéi och ëmmer, Traceview ass genau Dëst. Jo, e puer Tracing Systemer bidden kompriméiert Traceviews wann d'Zuel vun de Spannen an der Spuer sou grouss ass datt se net an enger Visualiséierung ugewise kënne ginn. Wéi och ëmmer, wéinst der grousser Quantitéit un Informatioun enthale souguer an esou enger ofgeschniddener Visualiséierung, sinn d'Ingenieuren ëmmer nach gezwongen "siften" et, manuell d'Auswiel op eng Rei vu Servicer verklengert, déi Quelle vu Probleemer sinn. Leider sinn an dësem Beräich Maschinnen vill méi séier wéi Mënschen, manner ufälleg fir Feeler, an hir Resultater si méi widderholl.
En anere Grond, deen ech mengen, datt Traceview falsch ass, ass well et net gutt ass fir Hypothese-gedriwwen Debugging. Am Kär ass Debugging iterativ e Prozess, deen mat enger Hypothese ufänkt, gefollegt vun der Verifizéierung vu verschiddenen Observatiounen a Fakten aus dem System laanscht verschidde Vektoren, Conclusiounen / Generalisatiounen a weider Bewäertung vun der Wahrheet vun der Hypothese.
Geleeënheet séier a bëlleg Hypothesen testen an de mentale Modell deementspriechend verbesseren ass Ecksteen Debugging All Debugging Tool soll sinn interaktiv a schmuel de Sichraum oder, am Fall vun engem falschen Lead, erlaabt de Benotzer zréck ze goen an op en anert Gebitt vum System ze fokusséieren. De perfekte Tool wäert dëst maachen proaktiv, direkt de Benotzer op potenziell Problemberäicher opmierksam ze maachen.
Ach, traceview kann net en Tool mat engem interaktiven Interface genannt ginn. Dat Bescht wat Dir kënnt hoffen wann Dir et benotzt ass eng Quell vu verstäerkter latency ze fannen an all méiglech Tags a Logbicher ze kucken, déi domat verbonne sinn. Dëst hëlleft den Ingenieur net z'identifizéieren Musteren am Traffic, wéi d'Spezifizitéiten vun der Verzögerungsverdeelung, oder Korrelatiounen tëscht verschiddene Miessunge erkennen. kann hëllefen, e puer vun dëse Problemer ëmzegoen. Wierklech, erfollegräich Analyse mat Maschinnléieren fir anomal Spann z'identifizéieren an eng Ënnergrupp vun Tags z'identifizéieren déi mat anomalem Verhalen verbonne kënne sinn. Wéi och ëmmer, ech hunn nach iwwerzeegend Visualiséierunge vu Maschinnléieren oder Datemining Erkenntnisser ugewannt op Spannungen, déi wesentlech anescht sinn wéi eng Traceview oder engem DAG (directed acyclic graph).
Spannungen sinn ze niddereg Niveau
De fundamentale Problem mat Traceview ass dat spant sinn ze niddereg-Niveau Primitiv fir béid latency Analyse an root Ursaach Analyse. Et ass wéi eenzel Prozessor Kommandoen ze analyséieren fir ze probéieren eng Ausnahm ze léisen, wëssend datt et vill méi héije Tools wéi Backtrace sinn, déi vill méi bequem si fir mat ze schaffen.
Ausserdeem wäert ech d'Fräiheet huelen, folgend ze behaapten: Idealfall brauche mir net voll Bild geschitt während der Ufro Liewenszyklus, déi duerch modern Tracing Tools vertruede gëtt. Amplaz ass eng Form vu méi héije Abstraktioun erfuerderlech déi Informatioun iwwer wat enthält falsch gaangen (ähnlech wéi Backtrace), zesumme mat e puer Kontext. Amplaz déi ganz Spuer ze kucken, gesinn ech et léiwer Deel, wou eppes interessant oder ongewéinlech geschitt. De Moment gëtt d'Sich manuell duerchgefouert: den Ingenieur kritt d'Spuer an analyséiert onofhängeg d'Spannungen op der Sich no eppes Interessantes. D'Approche vu Leit, déi Spannungen an eenzel Spure kucken an der Hoffnung op verdächteg Aktivitéit z'entdecken, skaléiert guer net (besonnesch wa se Sënn musse maachen vun all de Metadaten, déi a verschiddene Spann kodéiert sinn, wéi Spann ID, RPC Method Numm, Spanndauer. 'a, Logbicher, Tags, etc.).
Alternativen zu traceview
Spuerresultater sinn am meeschten nëtzlech wann se visualiséiert kënne ginn op eng Manéier déi net-trivial Abléck gëtt an wat an interkonnektéierten Deeler vum System geschitt. Bis dat geschitt, bleift den Debugging Prozess gréisstendeels inert an hänkt vun der Fäegkeet vum Benotzer of fir déi richteg Korrelatiounen ze bemierken, déi richteg Deeler vum System ze kontrolléieren oder d'Stécker vum Puzzle zesummen ze setzen - am Géigesaz zu ze benotzen, hëlleft dem Benotzer dës Hypothesen ze formuléieren.
Ech sinn keen visuellen Designer oder UX Spezialist, awer an der nächster Sektioun wëll ech e puer Iddien deelen iwwer wéi dës Visualiséierunge kéinte ausgesinn.
Focus op spezifesch Servicer
Zu enger Zäit wou d'Industrie ronderëm Iddien konsolidéiert , et schéngt raisonnabel datt eenzel Équipë Prioritéit solle garantéieren datt hir Servicer mat dësen Ziler ausgeriicht sinn. Et follegt dat service orientéiert Visualiséierung ass am Beschten fir sou Teams.
Spuren, besonnesch ouni Prouf, sinn e Schatzkëscht vun Informatioun iwwer all Komponent vun engem verdeelt System. Dës Informatioun kann un e lëschtege Prozessor gefüttert ginn deen d'Benotzer liwwert service orientéiert Erkenntnisser Si kënnen am Viraus identifizéiert ginn - och ier de Benotzer d'Spure kuckt:
- Latenzverdeelungsdiagrammer nëmme fir héich prominent Ufroen (outlier Ufroen);
- Diagrammer vun Verspéidung Verdeelung fir Fäll wou Service SLO Ziler net erreecht ginn;
- Déi meescht "üblech", "interessant" an "komesch" Tags an Ufroen déi meeschtens ginn widderholl;
- Latency Decompte fir Fäll wou Ofhängegkeet Servicer erreechen net hir SLO Ziler;
- Latency Decompte fir verschidde Downstream Servicer.
E puer vun dëse Froen ginn einfach net vun agebaute Metriken beäntwert, wat d'Benotzer forcéiere Spannungen ze iwwerpréiwen. Als Resultat hu mir en extrem userfeindleche Mechanismus.
Dëst stellt d'Fro op: wat iwwer komplex Interaktiounen tëscht diversen Servicer, déi vu verschiddenen Teams kontrolléiert ginn? Ass et net traceview gët net als dat gëeegentst Instrument ugesinn fir esou eng Situatioun ze markéieren?
Mobil Entwéckler, Besëtzer vu staatleche Servicer, Besëtzer vu verwalteten staatleche Servicer (wéi Datenbanken) a Plattformbesëtzer kënnen un eppes anescht interesséiert sinn Presentatioun verdeelt System; traceview ass eng ze generesch Léisung fir dës fundamental verschidde Bedierfnesser. Och an enger ganz komplexer Mikroservicearchitektur brauche Servicebesëtzer keng déif Kenntnisser vu méi wéi zwee oder dräi Upstream an Downstream Servicer. Weesentlechen, an de meeschte Szenarie, mussen d'Benotzer nëmme Froen beäntweren limitéiert Set vu Servicer.
Et ass wéi wann Dir e klengen Ënnerdeel vu Servicer duerch eng Lupe kuckt fir se ze iwwerpréiwen. Dëst erlaabt de Benotzer méi dréngend Froen iwwer déi komplex Interaktiounen tëscht dëse Servicer an hir direkt Ofhängegkeeten ze stellen. Dëst ass ähnlech wéi Backtrace an der Servicer Welt, wou den Ingenieur weess dass falsch, an huet och e puer Versteesdemech vun wat geschitt an Emgéigend Servicer ze verstoen firwat.
D'Approche, déi ech förderen, ass de genaue Géigendeel vun der Top-down, Traceview-baséiert Approche, wou d'Analyse mat der ganzer Spuer ufänkt an duerno graduell op eenzel Spannungen erof geet. Am Géigesaz, fänkt eng Bottom-up Approche un andeems Dir e klengt Gebitt no bei der potenzieller Ursaach vum Tëschefall analyséiert, an dann de Sichraum erweidert wéi néideg (mat dem Potenzial fir aner Teams ze bréngen fir eng méi breet Palette vu Servicer ze analyséieren). Déi zweet Approche ass besser fir séier initial Hypothesen ze testen. Wann ee konkret Resultater kritt, kann een op eng méi konzentréiert an detailléiert Analyse weidergoen.
Bauen eng Topologie
Servicespezifesch Usiichten kënnen onheemlech nëtzlech sinn wann de Benotzer et weess wat e Service oder Grupp vu Servicer ass verantwortlech fir d'Erhéijung vun der latency oder d'Verursaach vu Feeler. Wéi och ëmmer, an engem komplexe System kann d'Identifikatioun vum beleidegende Service eng net-trivial Aufgab während engem Echec sinn, besonnesch wa keng Fehlermeldungen vun de Servicer gemellt goufen.
Eng Servicetopologie bauen kann eng grouss Hëllef sinn fir erauszefannen, wéi ee Service e Spike a Fehlerraten erliewt oder eng Erhéijung vun der Latenz, déi de Service bemierkbar degradéiert. Wann ech iwwer eng Topologie bauen, mengen ech net Servicer Kaart, weist all Service verfügbar am System a bekannt fir seng . Dës Vue ass net besser wéi Traceview baséiert op enger riichter azyklescher Grafik. Amplaz géif ech gär gesinn dynamesch generéiert Servicetopologie, baséiert op bestëmmten Attributer wéi Fehlerquote, Äntwertzäit oder all Benotzerdefinéiert Parameter, deen hëlleft d'Situatioun mat spezifesche verdächtege Servicer ze klären.
Loosst eis e Beispill huelen. Loosst eis e hypotheteschen Neiegkeetssite virstellen. Homepage Service (virun Säit) austauscht Daten mat Redis, mat engem Empfehlungsservice, mat engem Werbeservice an engem Videoservice. De Videoservice hëlt Videoe vu S3 a Metadaten vun DynamoDB. De Empfehlungsservice kritt Metadaten vun DynamoDB, lued Daten vu Redis a MySQL, a schreift Messagen un Kafka. De Werbeservice kritt Daten vu MySQL a schreift Messagen un Kafka.
Drënner ass eng schematesch Duerstellung vun dëser Topologie (vill kommerziell Routing Programmer bauen d'Topologie). Et kann nëtzlech sinn wann Dir Service Ofhängegkeeten muss verstoen. Allerdéngs, während Debugging, wann e bestëmmte Service (z.b. e Video-Service) eng erhéicht Äntwertzäit weist, ass sou eng Topologie net ganz nëtzlech.
Service Diagramm vun engem hypotheteschen News Site
D'Diagramm hei drënner wier besser ugepasst. Et gëtt e Problem mam Service (Video) direkt am Zentrum duergestallt. De Benotzer mierkt et direkt. Vun dëser Visualiséierung gëtt et kloer datt de Video Service onnormal funktionnéiert wéinst enger Erhéijung vun der S3 Äntwertzäit, wat d'Laaschtgeschwindegkeet vun engem Deel vun der Haaptsäit beaflosst.
Dynamesch Topologie déi nëmmen "interessant" Servicer weist
Dynamesch generéiert Topologien kënne méi effizient sinn wéi statesch Servicekaarten, besonnesch an elasteschen, autoskaléierende Infrastrukturen. D'Kapazitéit fir Servicetopologien ze vergläichen an ze kontrastéieren erlaabt de Benotzer méi relevant Froen ze stellen. Méi präzis Froen iwwer de System si méi wahrscheinlech zu engem bessere Verständnis wéi de System funktionnéiert.
Comparativ Display
Eng aner nëtzlech Visualiséierung wier e vergläichende Display. Am Moment sinn Spure net ganz gëeegent fir Säit-vun-Säit Vergläicher, sou datt Vergläicher normalerweis sinn spant. An d'Haaptidee vun dësem Artikel ass genau datt d'Spann ze niddereg sinn fir déi wäertvollst Informatioun aus de Spuerresultater ze extrahieren.
Zwee Spure vergläichen erfuerdert keng fundamental nei Visualiséierungen. Tatsächlech ass eppes wéi en Histogramm, deen déiselwecht Informatioun representéiert wéi eng Traceview, genuch. Iwwerraschend kann och dës einfach Method vill méi Uebst bréngen wéi einfach zwee Spure separat ze studéieren. Nach méi staark wier d'Méiglechkeet visualiséieren Verglach vu Spuren Am Ganzen. Et wier extrem nëtzlech ze gesinn wéi eng kierzlech ofgebauter Datebankkonfiguratiounsännerung fir GC z'erméiglechen (Müllsammlung) d'Äntwertzäit vun engem Downstream Service op enger Skala vun e puer Stonnen beaflosst. Wann dat wat ech hei beschreiwen kléngt wéi eng A/B Analyse vum Impakt vun Infrastrukturännerungen a ville Servicer d'Spureresultater benotzt, da sidd Dir net ze wäit vun der Wourecht.
Konklusioun
Ech stellen d'Nëtzlechkeet vum Tracing selwer net a Fro. Ech gleewen oprecht datt et keng aner Method ass fir Daten ze sammelen sou räich, kausal a kontextuell wéi déi an enger Spuer enthale sinn. Wéi och ëmmer, ech gleewen och datt all Tracing-Léisungen dës Donnéeën extrem ineffizient benotzen. Soulaang d'Tracing-Tools op der Traceview Representatioun hänke bleiwen, wäerte se limitéiert sinn an hirer Fäegkeet fir déi meescht wäertvoll Informatioun ze maachen, déi aus den Donnéeën an de Spuren extrahéiert kënne ginn. Zousätzlech ass et e Risiko fir eng komplett onfrëndlech an unintuitiv visuell Interface weider z'entwéckelen, déi de Benotzer seng Fäegkeet fir Feeler an der Applikatioun ze léisen staark limitéiert.
Debugging komplex Systemer, och mat de leschten Tools, ass onheemlech schwéier. Tools sollen den Entwéckler hëllefen eng Hypothese ze formuléieren an ze testen, aktiv zur Verfügung gestallt relevant Informatiounen, Identifikatioun Auslänner an Notéieren Fonctiounen an der Verdeelung vun Verspéidungen. Fir Tracing fir d'Tool vun der Wiel fir Entwéckler ze ginn wann d'Produktiounsfehler léisen oder Probleemer léisen déi verschidde Servicer spanen, sinn originell User-Interfaces a Visualiséierunge gebraucht, déi méi konsequent mam mentale Modell vun den Entwéckler sinn, déi dës Servicer erstellen an operéieren.
Et wäert bedeitend mental Effort huelen fir e System ze designen deen déi verschidde Signaler, déi an de Spuerresultater verfügbar sinn, vertrieden op eng Manéier déi optimiséiert ass fir einfach Analyse an Inferenz. Dir musst nodenken wéi Dir d'Systemtopologie während der Debugging abstrakéiert op eng Manéier déi de Benotzer hëlleft blann Flecken ze iwwerwannen ouni op eenzel Spuren oder Spannen ze kucken.
Mir brauche gutt Abstraktioun a Schichtenfäegkeeten (besonnesch an der UI). Déi, déi gutt an en hypothese-driven Debugging-Prozess passen, wou Dir iterativ Froen stellen an Hypothesen testen. Si wäerten net automatesch all Observatiounsproblemer léisen, awer si hëllefen d'Benotzer hir Intuition ze schärfen a méi schlau Froen ze formuléieren. Ech ruffe fir eng méi nodenklech an innovativ Approche zur Visualiséierung. Et gëtt eng reell Perspektiv hei fir den Horizont auszebauen.
PS vum Iwwersetzer
Liest och op eisem Blog:
- «";
- «";
- «".
Source: will.com