🥇Gjurma e shpërndarë: ne e bëmë gjithçka gabim

Shën. përk.: Autori i këtij materiali është Cindy Sridharan, inxhinere nga imgix, e specializuar në zhvillimin e API-ve dhe veçanërisht në testimin e mikroshërbimeve. Në këtë material, ajo ndan vizionin e saj të thellë mbi problemet aktuale në fushën e gjurmimit të shpërndarë, ku sipas saj, ka një mungesë të veglave vërtet efektive për zgjidhjen e problemeve akute.

[Ilustrimi është marrë nga një material tjetër në lidhje me gjurmimin e shpërndarë.]

Konsiderohet se gjurmimi i shpërndarë është i vështirë për t'u implementuar, dhe përfitimet nga ai në më të mirën e rasteve janë të dyshimta. ‘Problematika’ e gjurmimit shpjegohet me shumë arsye, dhe shpesh referohet në përpjekjen e madhe për të konfiguruar çdo komponent të sistemit për të dërguar titujt përkatës me çdo kërkesë. Megjithëse kjo problematikë është e pranishme, nuk mund të quhet e pakapërcyeshme. Sidoqoftë, kjo nuk shpjegon pse zhvilluesit nuk e preferojnë shumë gjurmimin (edhe kur ai është funksional).

Sfidha kryesore me gjurmimin e shpërndarë është se nuk është grumbullimi i të dhënave, as standardizimi i formateve të shpërndarjes dhe paraqitjes së rezultateve dhe as përcaktimi i asaj se kur, ku dhe si duhet të bëhet mostra. Unë nuk përpiqem të paraqes si triviale këto “probleme të pranueshmërisë” — në të vërtetë, ekzistojnë disa sfida teknike të rëndësishme dhe (nëse e shqyrtojmë nga një këndvështrim të vërtetë Open Source standarde dhe protokolle) sfida politike, të cilat duhet të kalohen që këto probleme të mund të merren si të zgjidhura.

Megjithatë, nëse supozojmë se të gjitha këto probleme janë zgjidhur, ka një probabilitet të lartë që asgjë të mos ndryshojë ndjeshëm nga pikëpamja e përvojës së përdoruesit të fundit. Gjurmimi ndoshta akoma nuk do të ketë një përfitim praktik në skenarët më të zakonshëm të depurimit — edhe pasi ajo është implementuar.

Një gjurmim i tillë i pazakontë

Gjurmimi i shpërndarë përfshin disa komponente të shkëputura:

níhozimin e aplikacioneve dhe middleware me mjete kontrolli;
transferimi i kontekstit të shpërndarë;
grumbullimi i gjurmimeve;
ruajtja e gjurmimeve;
ekstraktimi dhe vizualizimi i tyre.

Shumë biseda rreth gjurmimit të shpërndarë reduktohen në shqyrtimin e saj si një operacion unitar, me qëllimin e vetëm për të ndihmuar në diagnostikimin e plotë të sistemit. Kjo është në masë të madhe e lidhur me mënyrën se si historikisht janë formuar përfytyrimet rreth gjurmimit të shpërndarë. Në postim në blog, kur u hapën burimet e Zipkin, u përmend se ai [Zipkin] e bën Twitter më të shpejtë. Ofertat e para komerciale për gjurmimin gjithashtu u promovuan si mjetet APM.

Shën. përk.: Për ta bërë tekstin e mëtejmë më të kuptueshëm, le të përcaktojmë dy terma bazë sipas dokumentacionit të projektit OpenTracing:

Span — elementi bazë i gjurmimit të shpërndarë. Paraqet një përshkrim të një procesi të punës (për shembull, një kërkesë në databazë) me emrin, kohën e fillimit dhe përfundimit, etiketat, logët dhe kontekstin.
Span’ët zakonisht përmbajnë lidhje me span’ë të tjera, duke lejuar kështu bashkimin e shumë span’ëve në Trace — vizualizimin e jetës së kërkesës gjatë shpërndarjes së saj në sistemin e shpërndarë.

Trace-t ofron një informacion jashtëzakonisht të vlefshëm që mund të ndihmojë në detyra të tilla si: testimi në production, realizimi i testeve të rikuperimit nga aksidentet, testimi me implementimin e gabimeve, etj. Në të vërtetë, disa kompani tashmë po përdorin traceback për këto qëllime. Le të fillojmë me atë që transfertë universale e kontekstit ka edhe aplikime të tjera përveç thjesht transferimit të span-ave në sistemin e ruajtjes:

Për shembull, Uber përdor rezultatet e trace-t për ndarjen e trafikut të testit dhe trafikut në production.
Facebook përdor të dhënat e trace-ve për analizën e rrugës kritike dhe për kalimin e trafikut gjatë testeve të rregullta të rikuperimit nga aksidentet.
Gjithashtu rrjeti social përdor notebook-ët Jupyter, të cilat u lejojnë zhvilluesve të realizojnë kërkesa të rastësishme mbi rezultatet e traceback.
Përkrahësit LDFI (Lineage Driven Failure Injection) në kompaninë Hecla Mining, e cila nxjerr argjend dhe metale të tjera të çmuara. Kompjuteri është instaluar në një stacion në Alaska, ku përdoret për të vlerësuar parametrat e mineralit dhe për të printuar etiketat për mostra. Me rastin e kësaj, një printer po aq i vjetër po përgjigjet për etiketa. Është interesante, se shtatë vjet më parë, njëri nga inxhinierët e Hecla Mining në një postim në Reddit vuri në dukje se "ai nuk ka nevojë të luajë serinë trace të shpërndara për testimin me implementimin e gabimeve.

Asnjë nga opsionet e mësipërme nuk i takon plotësisht skenarit të debugimit, gjatë të cilit inxhinieri përpiqet të zgjidhë problemin duke shikuar në trace.

Kur bëhet për të arritur në skenarin e debugimit, ndërfaqja primare mbetet diagrami traceview (ndonëse disa e quajnë gjithashtu «diagrami i Ganttit» ose «diagrami kaskad»). Nën traceview unë kuptoj të gjithë span’ët dhe metadata përkatëse, të cilat së bashku formojnë trace. Çdo sistem gjurmimi me kod të hapur, si dhe çdo zgjidhje komerciale për gjurmimin ofron një traceview ndërfaqe përdoruesi për vizualizimin, thellimin dhe filtrimin e trace’ave.

Problemi me të gjitha sistemet e gjurmimit që kam hasur deri tani është se vizualizimi përfundimtar (traceview) reflekton praktikisht tërësisht karakteristikat e procesit të gjenerimit të trace’it. Edhe kur ofrohen vizualizime alternative: harta e intensitetit (heatmap), topologji shërbimesh, histogramet e vonesave (latency), ato përfundojnë gjithsesi në traceview.

Në të kaluarën kam vënë re se shumica e «inovacioneve» në fushën e gjurmimit në lidhje me UI/UX duket se kufizohen në përfshirjen e metadata të tjera në trace, duke përfshirë informacion me kardinalitet të lartë (high-cardinality) ose duke ofruar mundësinë për të detajuar span’ët specifikë ose për të bërë kërkesa. Në këtë mënyrë traceview mbetet mënyra kryesore e vizualizimit. Derisa të vazhdojë një situatë e tillë, gjurmimi i shpërndarë do të ketë (në rastin më të mirë) vendin e katërt si mjet debagimi, pas metrikeve, logëve dhe stack trace-ve, dhe në rastin më të keq — do të jetë një humbje e kotë e parave dhe kohës.

Problemi me traceview

Qëllimi traceview — ofrimi i një pamjeje të plotë të lëvizjes së një kërkese të veçantë përmes të gjithë komponenteve të sistemit të shpërndarë, me të cilat ajo lidhet. Disa sisteme më të avancuara të gjurmimit lejojnë detajimin e span-ve të veçanta dhe shikimin e ndarjes sipas kohës brenda e një procesi (kur span-et kanë kufij funkcionalë).

Një parakusht themelor i arkitekturës së mikrosistemave është ideja se struktura organizative rritet së bashku me nevojat e kompanisë. Mbështetësit e mikrosistemave argumentojnë se shpërndarja e detyrave të ndryshme biznesore në shërbime të veçanta u lejon ekipeve të vogla dhe autonomë të zhvilluesve të ndjekin gjithë ciklin e jetës të këtyre shërbimeve, duke u dhënë mundësinë për të krijuar, testuar dhe implementuar këto shërbime në mënyrë të pavarur. Megjithatë, një disavantazh i tillë është humbja e informacionit se si çdo shërbim ndërvepron me të tjerët. Në këto kushte, gjurmimi i shpërndarë pretendon të jetë një mjet esencial për të debugimit ndërveprimet komplekse midis shërbimeve.

Nëse keni vërtet një sistem shpërndarës tronditësisht të komplikuar, asnjë njeri nuk është në gjendje të mbajë mend vizionin e saj të plotë. Në të vërtetë, zhvillimi i një mjeti duke u bazuar në supozimin se kjo është e mundur është diçka si një anti-model (një qasje joefektive dhe jo produktive). Idealisht, për të depërtuar në thellësi është i nevojshëm një mjet që ndihmon të kufizoni zonën e kërkimit, në mënyrë që inxhinierët të mund të përqendrohen në një nëngrup matjesh (shërbimesh/përdoruesish/mikroserverësh etj.) që kanë të bëjnë me skenarin e caktuar të problemit. Kur zbulohet shkaku i dështimit, inxhinierët nuk duhet të merren me atë që ka ndodhur në të gjitha shërbimet njëkohësisht, pasi një kërkesë e tillë do të ishte në kundërshtim me ideologjinë e arkitekturës mikroshërbimore.

Megjithatë, traceview paraqet pikërisht kështu. Po, disa sisteme gjurmimi ofrojnë traceview të kompresuar, kur numri i span-ëve në trace është kaq i madh saqë nuk mund të paraqitet brenda një vizualizimi. Sidoqoftë, për shkak të sasisë së madhe të informacionit që përmban edhe kjo vizualizim e reduktuar, inxhinierët gjithsesi duhen të "filtruan" atë, duke e ngushtuar manualisht mostërn deri në një grup shërbimesh burimi të problemeve. E njohim, në këtë fushë makinat janë shumë më të shpejta se njeriu, më pak të predispozuara për gabime, dhe rezultatet e tyre janë më të përsëritshme.

Një arsye tjetër se përse metoda traceview e shoh të gabuar, lidhet me faktin se ajo është e papërshtatshme për debugging të bazuar në hipoteza. Në thelb, debugging është iterativ procesi që fillon me një hipotezë, pasuar nga verifikimi i vëzhgimeve dhe fakteve të ndryshme të marra nga sistemi për shumë drejtime, përfundimet/shtjellimet dhe vlerësimi i mëtejshëm i vërtetësisë së hipotezës.

Mundësia shpejt dhe me kosto të ulët testimi i hipotezave dhe përmirësimi përkatës i modelit mendor është thelbësor në debugim. Çdo mjet debugimi duhet të jetë interaktiv dhe të ngushtojë hapësirën e kërkimit ose, në rast të një gjurmën të rreme, të lejojë përdoruesin të kthehet dhe të përqendrohet në një fushë tjetër të sistemit. Mjeti ideal do ta bënte këtë me parapërgatitje, duke tërhequr menjëherë vëmendjen e përdoruesit në fusha potencialisht problematike.

Fatkeqësisht, traceview nuk mund të quhet një mjet me ndërfaqe interaktive. Çfarëdo që mund të shpresohet nga përdorimi i tij është të zbulojë një burim të vonesave të rritura dhe të shkruajë të gjitha etiketat dhe logjet e lidhura me të. Kjo nuk ndihmon inxhinierin të identifikojë modellet në trafik, si p.sh. specifikën e shpërndarjes së vonesave, ose të zbulojë korrelacione midis matjeve të ndryshme. Analizë e përgjithshme e trace'ave mund të ndihmojë për të kapërcyer disa nga këto probleme. Në të vërtetë, ka shembuj të analizës së suksesshme duke përdorur mësimin e makinës për identifikimin e anomalisë në span dhe identifikimin e një nëngrupi të etiketave që mund të jenë të lidhura me sjellje anormale. Megjithatë, deri më tani nuk kam hasur në vizualizime bindëse të gjetjeve të bëra me mësimin e makinës ose analizën e të dhënave të aplikuara në span, të cilat do të ishin ndjeshëm të ndryshme nga traceview ose DAG (grafi i drejtuar aciklik).

Span janë shumë primitiv

Problemi themelor me traceview është se span janë shumë primitiv për analizën e vonesave (latency) dhe për analizën e shkaqeve themelore. Është si të analizohet një grup komandash të veçanta të procesorit për të përpjekur të zgjidhet një përjashtim, duke ditur se ka mjete shumë më të larta si backtrace, me të cilat është shumë më lehtë të punohet.

Për më tepër, do të guxoja të thosha se: idealisht, nuk na nevojitet fare imagjina e plotë ndodhi gjatë ciklit të jetës së kërkesës, të cilin e ofrojnë mjetet moderne për gjurmimin. Në vend të kësaj kërkohet një formë abstraksioni më të lartë, që përmban informacione mbi atë se çfarë ka shkuar keq (në përputhje me backtrace), së bashku me disa kontekst. Në vend të tërësie të gjurmimit, unë preferoj të shoh pjesën e tij ku ndodh diçka interesante ose të pazakontë. Aktualisht, kërkimi bëhet manualisht: inxhinieri merr gjurmimin dhe analizon vetë spanet në kërkim të diçkaje interesante. Qasja, kur njerëzit përballen me spanet në gjurmime të veçanta në shpresë për të zbuluar aktivitet të dyshimtë, nuk është aspak e shkallëzuar (sidomos kur ata duhet të kuptojnë të gjitha të dhënat e metadatas, të koduara në spanet e ndryshme, si ID e spanit, emri i metodës RPC, kohëzgjatja e spanit, logjet, etiketat, etj.)., ku ndodhin gjëra interesante ose të pazakonta. Aktualisht, kërkimi bëhet manualisht: inxhinieri merr trace dhe analizon vetë span’ët për të gjetur diçka interesante. Qasja, kur njerëzit shohin span’ët në trace të veçanta me shpresën për të zbuluar aktivitet të dyshimtë, është krejtësisht e papërshkueshme (veçanërisht kur ata duhet të kuptojnë të gjitha metadatët e koduara në span’ë të ndryshme, siç janë ID e span’it, emri i metodës RPC, kohëzgjatja e span’it, logjet, etiketat, etj.).

Alternativat e traceview

Rezultatet e gjurmimit janë më të dobishme kur mund të vizualizohen në një mënyrë që ofron një paraqitje të thellë të asaj që ndodh në pjesët e ndërlidhura të sistemit. Për sa kohë që kjo nuk ndodh, procesi i depurimit mbetet në masë të madhe inert dhe varet nga aftësia e përdoruesit për të vënë re korrelacionet e sakta, për të verifikuar pjesët e duhura të sistemit ose për të mbledhur copëzat e mozaikut bashkë — ndryshe nga instrumenti, që ndihmon përdoruesin të formulojë këto hipoteza.

Nuk jam një dizajner vizual dhe as specialist në fushën e UX, megjithatë në seksionin e ardhshëm dëshiroj të ndaja disa ide se si mund të duken këto visualizime.

Fokusimi tek shërbimet specifike

Në kushte ku industria po konsolidohet rreth ideve SLO (objektivat e nivelit të shërbimit) dhe SLI (indikatorët e nivelit të shërbimit), duket e arsyeshme që ekipet e veçanta duhet të ndjekin përputhshmërinë e shërbimeve të tyre me këto qëllime. Pra, visualizimi i orientuar drejt shërbimit është më i përshtatshëm për këto ekipe.

Trace’ët, sidomos pa pasur përzgjedhje, janë një burim i pasur informacioni për çdo komponent të një sistemi të shpërndarë. Ky informacion mund të ushqehet në një procesor të zgjuar, i cili do të ofrojë përdoruesve orientimet në shërbim gjetjet. Ato mund të identifikohen paraprakisht — përpara se përdoruesi të shikojë trace’ët:

Grafikët e shpërndarjes së vonesave vetëm për kërkesat e theksuara (outlier requests);
Grafikët e shpërndarjes së vonesave për rastet kur objektivat e SLO të shërbimit nuk arrihen;
Etiketat më "të zakonshme", "më interesante" dhe "më të çuditshme" në kërkesat, që përsëriten më shpesh përsëriten;
Shpërndarja e vonesave për rastet kur varësitë e shërbimit nuk arrijnë të përmbushin objektivat e vendosur SLO;
Shpërndarja e vonesave për shërbime të ndryshme poshtë (downstream).

Për disa nga këto pyetje, metrikat e ndërtuara thjesht nuk mund të japin përgjigje, duke detyruar përdoruesit të shqyrtojnë me kujdes spanjat. Si rezultat, kemi një mekanizëm jashtëzakonisht armiqësor ndaj përdoruesit.

Në këtë kontekst, lind pyetja: çfarë do të ndodhë me ndërveprimet komplekse midis shërbimeve të ndryshme, të kontrolluara nga ekipe të ndryshme? A nuk është traceview nuk është instrumenti më i përshtatshëm për të ilustruar një situatë të tillë?

Zhvilluesit mobilë, pronarët e shërbimeve stateless, pronarët e shërbimeve stateful të menaxhuara (siç janë bazat e të dhënave) dhe pronarët e platformave mund të jenë të interesuar për një tjetër prezantim të një sistemi të shpërndarë; traceview — është një zgjidhje shumë e përgjithshme për këto nevoja që ndryshojnë rrënjësisht. Edhe në një arkitekturë të ndërlikuar mikroshërbimi, pronarët e shërbimeve nuk kanë nevojë për njohuri të thella mbi më shumë se dy deri tre shërbime upstream dhe downstream. Në thelb, në shumicën e skenarëve, përdoruesve u mjafton të përgjigjen në pyetje që lidhen me një grup të kufizuar shërbimesh.

Kjo është si të shikosh një nënset të vogël shërbimesh përmes një lenteje për disa studime të kujdesshme. Kjo do t'i lejojë përdoruesit të bëjnë pyetje më të rëndësishme në lidhje me ndërveprimin kompleks midis këtyre shërbimeve dhe varësive të tyre të menjëhershme. Kjo është e ngjashme me backtrace-in në botën e shërbimeve, ku inxhinieri e di, çfarë jo vetëm këtë, por gjithashtu ka një ide mbi atë që ndodh në shërbimet përreth, për të kuptuar, pse.

Qasja ime e promovuar është krejtësisht e kundërt me qasjen "sipër-poshtë", e cila bazohet në traceview, kur analiza fillon me tërë trace-in dhe më pas gradualisht zbret deri te span-et e veçanta. Përkundrazi, qasja "poshtë-lart" fillon me analizimin e një pjese të vogël, afër shkakut të mundshëm të incidentit, dhe më pas zgjeron hapësirën e kërkimit kur është e nevojshme (me mundësinë e angazhimit të ekipeve të tjera për të analizuar një gamë më të gjerë shërbimesh). Qasja e dytë është më e përshtatshme për verifikimin e shpejtë të hipotezave fillestare. Pasi të merret një rezultat konkret, mund të kaloni në një analizë më të fokusuar dhe më të detajuar.

Ndërtimi i topologjisë

Pamjet e lidhura me një shërbim të caktuar mund të jenë jashtëzakonisht të dobishme, nëse përdoruesi e di cili shërbim ose grup shërbimesh është përgjegjës për rritjen e vonesave ose është burim i gabimeve. Megjithatë, në një sistem të ndërlikuar, përcaktimi i shërbimit përgjegjës mund të jetë një detyrë jo triviale gjatë një dështimi, veçanërisht nëse mesazhet e gabimit nga shërbimet nuk janë dërguar.

Krijimi i topologjisë së shërbimeve mund të ndihmojë shumë në identifikimin e cilit shërbim po demonstrohet një rritje e shpeshtësisë së gabimeve ose shtim të vonesës që çon në përkeqësimin e dukshëm të performancës së shërbimit. Duke folur për ndërtimin e topologjisë, unë kam parasysh jo hartën e shërbimeve, e cila tregon çdo shërbim të pranishëm në sistem dhe është e njohur për hartat e saj të arkitekturës në formën e yllit të vdekjes. Një pamje e tillë nuk është më e mirë se sa traceview në bazë të një grafoid të drejtuar aciklik. Përkundrazi, do të doja të shihja topologjinë e shërbimeve të gjeneruar dinamikisht, e cila është e bazuar në atribute të caktuara, të tilla si frekuenca e gabimeve, koha e përgjigjes, ose çfarëdo parametri të caktuar nga përdoruesi që ndihmon në sqarimin e situatës me shërbimet e dyshuara specifike.

Le të shqyrtojmë një shembull. Le ta imagjinojmë një faqe hipotetike lajmesh. Shërbimi i faqes së parë (front page) ndërmjetëson të dhëna me Redis, shërbimin e rekomandimeve, shërbimin e reklamave dhe shërbimin e videove. Shërbimi i videove merr video nga S3, ndërsa metadata nga DynamoDB. Shërbimi i rekomandimeve merr metadatën nga DynamoDB, ngarkon të dhëna nga Redis dhe MySQL, dhe dërgon mesazhe në Kafka. Shërbimi i reklamave merr të dhëna nga MySQL dhe dërgon mesazhe në Kafka.

Më poshtë është një skemë vizuale e kësaj topologjie (topologjitë hartohen nga shumë programe komerciale për gjurmim). Ajo mund të jetë e dobishme nëse duhet të kuptoni varësitë e shërbimeve. Megjithatë, gjatë të debugimit, kur një shërbim (le të themi, shërbimi i videove) tregon një kohë përgjigjeje të shtuar, një topologji e tillë nuk është shumë e dobishme.

Diagrami i shërbimeve të një siti hipotetik lajmesh

Një diagram më i përshtatshëm do të ishte ai i paraqitur më poshtë. Në të, shërbimi problematik (video) është paraqitur direkt në qendër. Përdoruesi e vërehet menjëherë. Nga kjo vizualizim bëhet e qartë se shërbimi i videove funksionon anomalisht për shkak të rritjes së kohës së përgjigjes nga S3, që ndikon në shpejtësinë e ngarkimit të disa pjesëve të faqeve kryesore.

Topologjia dinamike, që tregon vetëm shërbimet "interesante"

Diagramet topologjike të gjeneruara dinamikisht mund të jenë më efikase se hartat statike të shërbimeve, veçanërisht në infrastrukturat elastike dhe me shkallëzim automatik. Mundësia për të krahasuar dhe përputhur topologjitë e shërbimeve u jep përdoruesve mundësinë të bëjnë pyetje më relevante. Pyetje më të sakta rreth sistemit kanë më shumë gjasa të çojnë në një kuptim më të mirë të mënyrës se si funksionon sistemi.

Krahasimi vizual

Një tjetër vizualizim i dobishëm do të ishte krahasimi vizual. Aktualisht, trace-t nuk janë shumë të përshtatshme për krahasim ballë për ballë, prandaj zakonisht krahasohen span. Ideja kryesore e këtij artikulli është se span-t janë shumë në nivel të ulët për të nxjerrë informacionin më të çmuar nga rezultatet e trazimit.

Krahasimi i dy trace’ave nuk kërkon vizualizime thelbësore të reja. Në të vërtetë, mjafton diçka si një histogram që paraqet të njëjtën informacion si traceview. E befasishme, por madje ky metodë e thjeshtë mund të sjellë shumë më tepër përfitime sesa thjesht studimi i dy trace’ave veç e veç. Një mundësi edhe më e fuqishme do të ishte vizualizimi i krahasimit të trace’ave në përmbledhje. Do të ishte jashtëzakonisht e dobishme të shihet se si një ndryshim i ri i konfiguaracionit të bazës së të dhënave me përfshirjen e GC (mbledhjes së plehrave) ndikon në kohën e përgjigjes së shërbimit downstream në shkallën e disa orëve. Nëse ajo që po përshkruaj këtu duket e ngjashme me një analizë A/B të ndikimit të ndryshimeve në infrastrukturë në shumë shërbime përmes rezultateve të gjurmimit, atëherë nuk je shumë larg së vërtetës.

Përfundimi

Nuk kam dyshime për dobishmërinë e vetë gjurmimit. Besoj sinqerisht se nuk ka metodë tjetër për të mbledhur të dhëna të pasura, rastësore dhe kontekstuale aq të rëndësishme sa ato që përmbahen në gjurmë. Megjithatë, mendoj gjithashtu se të gjitha zgjidhjet për gjurmim e shfrytëzojnë këto të dhëna në mënyrë jashtëzakonisht të paefektshme. Derisa mjetet për gjurmim të jenë të fokusuar në paraqitjen e gjurmëve, ato do të jenë të kufizuara në mundësitë për të shfrytëzuar sa më shumë informacion të vlefshëm që mund të nxirret nga të dhënat brenda gjurmëve. Për më tepër, ekziston rreziku i zhvillimit të një ndërfaqe vizuale që nuk është miqësore dhe e paintuicionshme, që do të kufizojë ndjeshëm aftësinë e përdoruesit për të zgjidhur gabimet në aplikacion.

Gabim i sistemeve të ndërlikuara, edhe me përdorimin e mjeteve më të reja, është jashtëzakonisht i vështirë. Mjetet duhet të ndihmojnë zhvilluesin në formulimin dhe verifikimin e hipotezave, duke ofruar aktivisht informacion relevante, duke zbuluar daljet dhe duke vëzhguar veçoritë në shpërndarjen e vonesave. Që gjurmimi të bëhet mjeti i preferuar i zhvilluesve për të adresuar dështimet në production ose për të zgjidhur probleme që përfshijnë shërbime të ndryshme, kërkohen ndërfaqe përdoruesi dhe vizualizime origjinale që përputhen më shumë me modelin mendor të zhvilluesve që krijojnë dhe operojnë këto shërbime.

Do të nevojiten përpjekje të konsiderueshme intelektuale për të projektuar një sistem që do të paraqesë sinjale të ndryshme të disponueshme në rezultatet e gjurmimit, në një mënyrë të optimizuar për të lehtësuar analizën dhe arsyetimin. Duhet të mendohet se si të abstrohet topologjia e sistemit gjatë debugs për të ndihmuar përdoruesin të kalojë nëpër zona të verbra, pa shikuar në gjurmët ose spanet e veçanta.

Na duhen mundësi të mira për abstraksion dhe nivele shkeputjeje (veçanërisht në UI). Njësoj që do të përshtaten mirë në procesin e debuggingut të bazuar në hipoteza, ku mund të formulohen pyetje dhe të kontrollohen hipotezat në mënyrë iteruese. Ato nuk do të zgjidhin automatikisht të gjitha problemet me vëzhgueshmërinë, megjithatë do të ndihmojnë përdoruesit të rafinojnë intuitën dhe të formulojnë pyetje më të menduara. Unë inkurajoj një qasje më të thellë dhe inovative në fushën e vizualizimit. Këtu ka një perspektivë të vërtetë për të zgjeruar horizontet.