Shën. përkth.: Autori i këtij materiali është Cindy Sridharan, inxhiniere në kompaninë imgix, e specializuar në zhvillimin e API-ve dhe, veçanërisht, testimin e mikroshërbimeve. Në këtë material, ajo ndan vizionin e saj të zgjeruar mbi problemet aktuale në fushën e konsolidimit të shpërndarë, ku, sipas saj, ka një mungesë të instrumenteve efektivë për të zgjidhur çështjet e ngutshme.
[Ilustrimi i huazuar nga në lidhje me konsolidimin e shpërndarë.]
Mendohet se është i vështirë për tu zbatuar, dhe përfitimi nga ai . "Problematika" e konsolidimit shpjegohet me shumë arsye, shpeshherë duke u referuar në vështirësinë e konfigurimit të çdo komponenti të sistemit për të transmetuar titujt përkatës me çdo kërkesë. Megjithëse ky problem me të vërtetë ekziston, ai nuk mund të quhet aspak i pakalueshëm. Po ashtu, nuk shpjegon pse zhvilluesit nuk e duan shumë konsolidimin (madje edhe atëherë kur është në funksion).
VĂ«shtirĂ«sia kryesore me konsolidimin e shpĂ«rndarĂ« Ă«shtĂ« se nuk Ă«shtĂ« mbledhja e tĂ« dhĂ«nave, as standardizimi i formateve tĂ« shpĂ«rndarjes dhe paraqitjes sĂ« rezultateve, dhe as pĂ«rcaktimi i kur, ku dhe si tĂ« bĂ«het mostrimi. UnĂ« nuk po pĂ«rpiqem tĂ« paraqes si triviale kĂ«to "problema tĂ« adaptueshmĂ«risĂ«" â pĂ«r tĂ« qenĂ« tĂ« sinqertĂ«, ekzistojnĂ« sfida mjaft tĂ« rĂ«ndĂ«sishme teknike dhe (nĂ«se e shohim nga njĂ« kĂ«ndvĂ«shtrim vĂ«rtet Open Source ) politike, tĂ« cilat duhet tĂ« kalohen para se kĂ«to probleme tĂ« mund tĂ« quhen tĂ« zgjidhura.
MegjithatĂ«, nĂ«se supozojmĂ« se tĂ« gjitha kĂ«to probleme janĂ« zgjidhur, ka njĂ« mundĂ«si tĂ« lartĂ« qĂ« asgjĂ« tĂ« mos ndyshojĂ« ndjeshĂ«m nga pikĂ«pamja e pĂ«rdoruesit tĂ« fundit. Konsolidimi do tĂ« vazhdojĂ« tĂ« mos sjellĂ« pĂ«rfitime praktike nĂ« skenaret mĂ« tĂ« zakonshĂ«m tĂ« debugimit â edhe pas implementimit tĂ« tij.
Një konsolidim i tillë i ndryshëm
Konsolidimi i shpërndarë përfshin disa komponente të ndara:
- arsimi i aplikacioneve dhe middleware me mjete kontrolli;
- transmetimi i kontekstit të shpërndarë;
- mbledhja e konsolidimeve;
- ruajtja e konsolidimeve;
- nxjerrja dhe vizualizimi i tyre.
Shumë biseda për gjurmimin e shpërndarë e reduktojnë atë në 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 kuptimet për gjurmimin e shpërndarë. Në , i bërë kur u hapën kodet burimore të Zipkin, u përmend se ai [Zipkin] e bën Twitter-in më të shpejtë. Ofertat e para komerciale për gjurmimin gjithashtu u promovuan si .
Shën. përkth.: Për ta bërë tekstin e mëtejmë më të kuptueshëm, le të përcaktojmë dy terminologji themelore sipas :
- Span â elementi bazĂ« i gjurmimit tĂ« shpĂ«rndarĂ«. PĂ«rfaqĂ«son pĂ«rshkrimin e njĂ« procesi tĂ« caktuar (p.sh., njĂ« kĂ«rkesĂ« nĂ« bazĂ«n e tĂ« dhĂ«nave) me emrin, kohĂ«n e fillimit dhe mbarimit, etiketat, log-et dhe kontekstin.
- Span-et zakonisht pĂ«rmbajnĂ« lidhje me span-e tĂ« tjera, duke lejuar qĂ« shumĂ« span-e tĂ« bashkohen nĂ« Trace â vizualizimi i jetĂ«s sĂ« kĂ«rkesĂ«s gjatĂ« kalimit tĂ« saj nĂ« sistemin e shpĂ«rndarĂ«.
Trace-et përmbajnë të dhëna jashtëzakonisht të vlefshme që mund të ndihmojnë në detyra të tilla si: testimi në prodhim, kryerja e testeve të rikuperimit të fatkeqësive, testimi me injeksion të gabimeve etj. Në fakt, disa kompani tashmë po e përdorin gjurmimin për këto qëllime. Le të fillojmë me atë që ka dhe aplikime të tjera përveç thjesht transferimit të span-eve në sistemin e ruajtjes:
- Për shembull, Uber rezultatet e gjurmimit për të ndarë trafikun testues dhe trafikun e prodhimit.
- Facebook të dhënat e trace-ve për analizimin e rrugës kritike dhe për kalimin e trafikut gjatë testeve të rregullta të rikuperimit nga fatkeqësitë.
- Gjithashtu, rrjeti social ditarët Jupyter, që lejojnë zhvilluesit të kryejnë kërkesa arbitrare mbi rezultatet e gjurmimit.
- Përkrahësit (Injeksioni i Dështimit të Drejtuar nga Linja) gjurmimet e shpërndara për testimin me injeksion të gabimeve.
Asnjë nga opsionet e mësipërme nuk i përket plotësisht skenarit të debunktimit, në të cilin inxhinieri përpiqet të zgjidhë problemin, duke e shqyrtuar trace.
Kur bĂ«het me tĂ« vĂ«rtetĂ« ka tĂ« bĂ«jĂ« me skenarin e debunktimit, ndĂ«rfaqja primare mbetet diagrami traceview (edhe pse disa e quajnĂ« atĂ« "diagrami Gantt" ose "diagrami kaskadĂ«"). NĂ«n traceview unĂ« tĂ« gjitha span'Ă«t dhe metadatat pĂ«rkatĂ«se, tĂ« cilat sĂ« bashku pĂ«rbĂ«jnĂ« trace. Ădo sistem gjurmimi me kod tĂ« hapur, si dhe çdo zgjidhje komerciale pĂ«r gjurmim ofron njĂ« bazĂ« tĂ« traceview ndĂ«rfaqe pĂ«rdoruesi pĂ«r vizualizimin, detajimin dhe filtrimin e trace'ave.
Problemi me të gjitha sistemet e gjurmimit me të cilat kam pasur mundësinë të njihem deri tani është se vizualizimi (traceview) praktikisht reflektimin e veçorive të procesit të gjenerimit të trace'it. Edhe kur ofrohen vizualizime alternative: harta e intensitetit (heatmap), topologjitë e shërbimeve, histogramet e vonesave (latency), në fund ato gjithmonë përfundojnë duke u shndërruar në traceview.
Në të kaluarën unë kërcënimin se shumica e "inovacioneve" në fushën e gjurmimit në lidhje me UI/UX, duket se janë të kufizuara në e metadatat e shtuara në trace, duke e ngarkuar ato me informacione me kardinalitet të lartë (high-cardinality) ose ofrimin e mundësisë për të detajuar span'të specifike ose për të bërë kërkesa midis dhe brenda trace. Ndërkohë, traceview mbetet mjeti kryesor i vizualizimit. Derisa kjo gjendje të ruhet, gjurmimi i shpërndarë do të zërë (në rastin më të mirë) vendin e katërt si një mjet debugimi, pas metrikeve, shënimeve dhe stack trace'ave, dhe në rastin më të keq, do të rezultojë një humbje e kotë parash dhe kohe.
Problemi me traceview
Qëllimi traceview është të ofrojë një pamje të plotë të lëvizjes së një kërkese të veçantë përmes të gjitha komponentëve të sistemit të shpërndarë me të cilët ka lidhje. Disa sisteme më të avancuara të gjurmimit lejojnë detajimin e span'ave të veçanta dhe shikimin e ndarjeve sipas kohës brenda një procesi (kur span'ët kanë kufij funksionalë).
Një parakusht themelor i arkitekturës së mikroshërbimeve është ideja se struktura organizative rritet së bashku me nevojat e kompanisë. Pronarët e mikroshërbimeve pohojnë se shpërndarja e detyrave të ndryshme të biznesit në shërbime të ndara lejon që grupe të vogla, autonome të zhvilluesve të kontrollojnë të gjithë ciklin e jetës së këtyre shërbimeve, duke u dhënë atyre 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 mbi mënyrën se si çdo shërbim ndërvepron me të tjerët. Në këto kushte, gjurmimi i shpërndarë pretendon të luajë rolin e një instrumenti të pazëvendësueshëm për të debunktimit ndërveprimet komplekse midis shërbimeve.
Nëse keni me të vërtetë , atëherë asnjë njeri nuk është në gjëndje ta mbajë mend pamjen e tij të plotë. Në të vërtetë, zhvillimi i një instrumenti me supozimin se kjo është e mundur, është diçka si një antipattern (një qasje e paefektshme dhe e paproduktive). Idealisht, për debugin do të kërkonte një instrument që ndihmon të ngushtohet zona e kërkimit, në mënyrë që inxhinierët të mund të përqendrohen në një nënset të matjeve (shërbimeve/përdoruesve/hosteve etj.) që kanë të bëjnë me skenarin e shqetësimit të studiuar. Kur zbulojnë shkakun e dështimit, inxhinierët nuk duhet të shqyrtojnë se çfarë ka ndodhur në të gjithë shërbimet njëherësh, pasi një kërkesë e tillë do të ishte në kontradiktë me vetë idenë e arkitekturës së mikroshërbimeve.
MegjithatĂ«, traceview pĂ«rfaqĂ«son pikĂ«risht kĂ«tĂ«. Po, disa sisteme gjurmimi ofrojnĂ« traceview tĂ« kompresuar, kur numri i spanâave nĂ« gjurmĂ« Ă«shtĂ« aq i madh sa qĂ« nuk mund tĂ« shfaqet brenda njĂ« vizualizimi. MegjithatĂ«, pĂ«r shkak tĂ« volumit tĂ« madh tĂ« informacionit, edhe nĂ« njĂ« vizualizim tĂ« tillĂ« tĂ« reduktuar, inxhinierĂ«t megjithatĂ« duhen tĂ« "filtron" atĂ«, duke ngushtuar manualisht mostrat nĂ« njĂ« grup shĂ«rbimesh qĂ« janĂ« burim i problemeve. Me tĂ« vĂ«rtetĂ«, nĂ« kĂ«tĂ« fushĂ« makinat janĂ« shumĂ« mĂ« tĂ« shpejta se njeriu, mĂ« pak tĂ« prirura ndaj gabimeve dhe rezultatet e tyre janĂ« mĂ« tĂ« pĂ«rsĂ«ritshme.
Një arsye tjetër pse unë e mendoj metodën traceview si të gabuar është se ajo nuk është e përshtatshme për debugin e bazuar në hipoteza. Në thelbin e saj, debugu është iterativ procesi që fillon me një hipotezë, pasuar nga verifikimi i vëzhgimeve dhe fakteve të ndryshme të marra nga sistemi për kanale të ndryshme, përfundimet/përmbledhjet dhe vlerësimi më tej i vërtetësisë së hipotezës.
MundĂ«sia shpejt dhe gjatĂ« testimi i hipotezave dhe pĂ«rmirĂ«simi pĂ«rkatĂ«s i modelit mendor Ă«shtĂ« thelbĂ«sor pĂ«r debugimin. Ădo mjet debugimi duhet tĂ« jetĂ« interaktiv dhe tĂ« ngushtojĂ« hapĂ«sirĂ«n e kĂ«rkimit ose, nĂ« rast tĂ« njĂ« gjurme tĂ« rremĂ«, tĂ« lejojĂ« pĂ«rdoruesin tĂ« kthehet prapa dhe tĂ« fokusohet nĂ« njĂ« zonĂ« tjetĂ«r tĂ« sistemit. Mjeti ideal do ta bĂ«j kĂ«tĂ« nĂ« mĂ«nyrĂ« proaktive, duke tĂ«rhequr menjĂ«herĂ« vĂ«mendjen e pĂ«rdoruesit nĂ« zona potencialisht problematike.
PĂ«r fat tĂ« keq, traceview nuk mund tĂ« quhet njĂ« mjet me njĂ« ndĂ«rfaqe interaktive. E mira qĂ« mund tĂ« shpresosh nga pĂ«rdorimi i tij Ă«shtĂ« tĂ« zbulojĂ« njĂ« burim tĂ« vonesave tĂ« rritura dhe tĂ« shqyrtojĂ« tĂ« gjitha etiketat dhe log-et qĂ« lidhen me tĂ«. Kjo nuk ndihmon inxhinierin tĂ« zbulojĂ« modellet nĂ« trafik, siç janĂ« specifikat e shpĂ«rndarjes sĂ« vonesave, ose tĂ« zbulojĂ« korelacionet midis matjeve tĂ« ndryshme. mund tĂ« ndihmojĂ« nĂ« kalimin e disa nga kĂ«to probleme. NĂ« tĂ« vĂ«rtetĂ«, analizash tĂ« suksesshme duke pĂ«rdorur mĂ«simin e makinave pĂ«r tĂ« zbuluar anomali tĂ« spanâave dhe identifikimin e nĂ«ndegĂ«ve tĂ« etiketave qĂ« mund tĂ« jenĂ« tĂ« lidhura me sjelljen anomale. MegjithatĂ«, deri tani, nuk kam hasur nĂ« vizualizime bindĂ«se tĂ« gjetjeve tĂ« bĂ«ra me ndihmĂ«n e mĂ«simit tĂ« makinave ose analizĂ«s sĂ« tĂ« dhĂ«nave tĂ« aplikuara nĂ« spanâave qĂ« do tĂ« ishin ndjeshĂ«m mĂ« tĂ« ndryshme nga traceview ose DAG (grafi i orientuar aciklik).
Spanâave janĂ« shumĂ« tĂ« nivelit tĂ« ulĂ«t
Problemi themelor me traceview Ă«shtĂ« se spanâave janĂ« shumĂ« tĂ« nivelit tĂ« ulĂ«t pĂ«r analizĂ«n e vonesave (latency) dhe pĂ«r analizĂ«n e shkakut tĂ« origjinĂ«s. ĂshtĂ« si tĂ« analizosh komandat e veçanta tĂ« procesorĂ«ve nĂ« pĂ«rpjekjen pĂ«r tĂ« eliminuar njĂ« pĂ«rjashtim, duke e ditur se ekzistojnĂ« mjete shumĂ« mĂ« tĂ« nivelit mĂ« tĂ« lartĂ« si backtrace, me tĂ« cilat Ă«shtĂ« shumĂ« mĂ« e lehtĂ« tĂ« punosh.
Më tej, do të marrë guximin të deklaroj këtë: në mënyrë ideale, nuk na nevojitet aspak pamja e plotë ngjarja e ndodhur gjatë ciklit të jetës së kërkesës, e cila paraqitet nga mjetet moderne për gjurmimin. Në vend të kësaj, kërkohet një formë abstrakcioni më të lartë, e cila përmban informacion mbi atë që ka shkuar keq ((përshtatur nga backtrace), së bashku me disa kontekst. Në vend që të shoh gjithë trace-n, preferoj ta shoh atë pjesën, ku ndodh diçka interesante ose të pazakontë. Në këtë moment, kërkimi bëhet manualisht: inxhinieri merr trace-n dhe analizon span-ët për të gjetur diçka interesante. Prirja, kur njerëzit shikojnë span-ët në trace të veçanta me shpresën se do të zbulojnë aktivitete të dyshimta, nuk është aspak e shkallëzueshme (sidomos kur ata duhet të kuptojnë të gjitha metadatën e koduar në span të ndryshëm, siç janë ID span, emri i metodës RPC, kohëzgjatja e span-it, log-et, etiketat etj.).
Alternativat e traceview
Rezultatet e gjurmimit janë më të dobishme kur mund të vizualizohen në një mënyrë që ofron një përfaqësim jo trivial të asaj që po ndodh në pjesët e ndërlidhura të sistemit. Derisa kjo të mos ndodhë, procesi i debugimit mbetet në masë të madhe inert dhe varet nga aftësia e përdoruesit për të vërejtur korrelacionet e sakta, për të verifikuar pjesët e duhura të sistemit ose për të mbledhur copëza të mozaikut së bashku - ndryshe nga instrumenti, i cili ndihmon përdoruesin të formulojë këto hipoteza.
Nuk jam dizajner visual dhe as specialist në UX, por në seksionin e ardhshëm dua të ndaj disa ide për atë si mund të duken këto vizualizime.
Fokusi në shërbime të caktuara
Në kushte kur industria konsolidohet rreth ideve , duket e arsyeshme që ekipet e veçanta duhet në radhë të parë të monitorojnë përputhshmërinë e shërbimeve të tyre me këto objektiva. Prej këndej, vizualizimi i orientuar drejt shërbimit është më i përshtatshëm për këto ekipe.
Trace-t, sidomos pa zgjedhje, janë një burim i çmueshëm informacioni mbi çdo komponent të një sistemi të shpërndarë. Ky informacion mund të ushqehet në një përpunues të zgjuar, i cili do t'u ofrojë përdoruesve gjetje të orientuara drejt shërbimit. Ato mund të identifikohen paraprakisht - para se përdoruesi të shikojë trace-t:
- Diagramet e shpërndarjes së vonesave janë vetëm për kërkesat që dallohet shumë (kërkesat e jashtme);
- Diagramet e shpërndarjes së vonesave për rastet kur qëllimet SLO të shërbimit nuk arrihen;
- Etiketat më "të zakonshme", "më interesante" dhe "më të çuditshme" në kërkesa që shfaqen më shpesh po përsëriten;
- Shkëputja e vonesave për rastet kur varësitë e shërbimit nuk arrijnë qëllimet e caktuara të SLO;
- Shkëputja e vonesave sipas shërbimeve të ndryshme poshtë (downstream).
Disa nga kĂ«to pyetje nuk mund tĂ« pĂ«rgjigjen nga metrikat e ndĂ«rtuara, duke detyruar pĂ«rdoruesit tĂ« shqyrtojnĂ« me kujdes spanâĂ«t. KĂ«shtu, rezulton njĂ« mekanizĂ«m jashtĂ«zakonisht armiqĂ«sor ndaj pĂ«rdoruesit.
Në këtë kontekst lind pyetja: si është për ndërveprimet komplekse midis shërbimeve të ndryshme, të kontrolluara nga ekipe të ndryshme? A nuk traceview është mjeti më i përshtatshëm për të ndriçuar 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Ă« paraqitje tjetĂ«r tĂ« sistemit tĂ« shpĂ«rndarĂ«; â Ă«shtĂ« njĂ« zgjidhje shumĂ« universale pĂ«r kĂ«to nevoja esencialisht tĂ« ndryshme. Edhe nĂ« njĂ« arkitekturĂ« shumĂ« tĂ« komplexe mikro-shĂ«rbimesh, pronarĂ«t e shĂ«rbimeve nuk kanĂ« nevojĂ« pĂ«r njohuri tĂ« thella mbi mĂ« shumĂ« se dy-tre shĂ«rbime upstream dhe downstream. NĂ« thelb, nĂ« shumicĂ«n e skenarĂ«ve, pĂ«rdoruesit duhet tĂ« pĂ«rgjigjen vetĂ«m pyetjeve qĂ« lidhen me traceview njĂ« grup tĂ« kufizuar shĂ«rbimesh Ky proces Ă«shtĂ« si tĂ« shikosh njĂ« nĂ«nçensemble tĂ« vogĂ«l shĂ«rbimesh pĂ«rmes njĂ« lupĂ« pĂ«r studim tĂ« detajuar. Kjo do t'i mundĂ«sojĂ« pĂ«rdoruesit tĂ« bĂ«jĂ« pyetje mĂ« presuese mbi ndĂ«rveprimet komplekse midis kĂ«tyre shĂ«rbimeve dhe varĂ«sive tĂ« tyre tĂ« menjĂ«hershme. Kjo Ă«shtĂ« e ngjashme me backtrace nĂ« botĂ«n e shĂ«rbimeve, ku inxhinieri di.
çfarë nuk shkon, dhe gjithashtu ka një ide për atë që ndodh në shërbimet përreth, për të kuptuar, Jo kështu, dhe gjithashtu ka njëfarë ideje për atë që po ndodh në shërbimet përreth, për të kuptuar, pse.
Qasja që unë promovoj është krejtësisht e kundërt me qasjen "nga lart poshtë", e bazuar në traceview, kur analiza fillon me të gjithë trace-in dhe pastaj gradualisht zbret deri te span-t e veçantë. Nga ana tjetër, qasja "nga poshtë lart" fillon me analizimin e një pjese të vogël, e cila është afër shkakut të mundshëm të incidentit, dhe pastaj zgjeron hapësirën e kërkimit sipas nevojës (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 kontrollin e shpejtë të hipotezave fillestare. Pas marrjes së rezultateve konkrete, mund të kalojmë në një analizë më të fokusuar dhe 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 se cili shërbim ose grup shërbimesh mund të jetë fajtori në rritjen e vonesave ose është burimi i gabimeve. Megjithatë, në një sistem kompleks, përcaktimi i shërbimit të problemit mund të jetë një detyrë e ndërlikuar gjatë ndërprerjes, veçanërisht nëse mesazhet e gabimeve nga shërbimet nuk janë marrë.
Ndërtimi i topologjisë së shërbimeve mund të ndihmojë shumë në përllogaritjen e cilit shërbim po tregon një rritje të frekuencës së gabimeve ose një rritje të vonesës, duke rezultuar në një përkeqësim të dukshëm të performancës së shërbimit. Kur flas për ndërtimin e topologjisë, nuk kam parasysh hartën e shërbimeve, e cila tregon çdo shërbim të pranishëm në sistem dhe është e njohur për . Një paraqitje e tillë nuk është më mirë se traceview në bazë të një grafi aciklike të orientuar. Në vend të kësaj, do doja të shihja topologjinë e shërbimeve që gjenerohet dinamikisht, e cila bazohet në atribute të caktuara, të tilla si frekuenca e gabimeve, koha e përgjigjes ose ndonjë parametër të dhënë nga përdoruesi që ndihmon në sqarimin e situatës me shërbime pikale.
Le të marrim një shembull. Imagjinoni një sit hipotetik lajmesh. Shërbimi i faqes kryesore (front page) ndërron të dhëna me Redis, shërbimin e rekomandimeve, shërbimin reklamues dhe shërbimin e videove. Shërbimi i videove merr videoklipet nga S3, ndërsa metadatat nga DynamoDB. Shërbimi i rekomandimeve merr metadatat nga DynamoDB, ngarkon të dhëna nga Redis dhe MySQL, dhe shkruan mesazhe në Kafka. Shërbimi reklamues merr të dhëna nga MySQL dhe shkruan mesazhe në Kafka.
Në vazhdim është një imazh skematik i kësaj topologjie (topologji që shumë programe tregtare e krijojnë për gjurmim). Ajo mund të jetë e dobishme nëse keni nevojë të kuptoni varësitë e shërbimeve. Megjithatë, gjatë të debunktimit, kur një shërbim (le të themi, shërbimi i videove) tregon një kohë të zgjatjes së përgjigjes, një topologji e tillë nuk është shumë e dobishme.
Skema e shërbimeve të një siti hipotetik lajmesh
Një diagram që ilustron më mirë do të ishte ai në vazhdim. Në të, shërbimi problematik (video) shfaqet drejtpërdrejt në qendër. Përdoruesi e vë re menjëherë atë. Nga kjo vizualizim kuptohet se shërbimi i videos funksionon anomalisht për shkak të rritjes së Kohëve të përgjigjes nga S3, e cila ndikon në shpejtësinë e ngarkesës së një pjese të faqes kryesore.
Topologjia dinamike, që tregon vetëm shërbimet "e rëndësishme"
Skemat topologjike që gjenerohen dinamikisht mund të jenë më efikase se hartat statike të shërbimeve, veçanërisht në infrastrukturat elastike dhe që auto-skalohen. Mundësia për të krahasuar dhe përputhur topologjitë e shërbimeve i lejon përdoruesit të bëjë pyetje më të aktualizuara. 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.
Paraqitja krahasuese
NjĂ« vizualizim tjetĂ«r i dobishĂ«m do tĂ« ishte paraqitja krahasuese. Aktualisht, trace-t nuk janĂ« shumĂ« tĂ« pĂ«rshtatshme pĂ«r krahasim pĂ«r krahasim, prandaj zakonisht krahasohen spanâave. Ideja kryesore e kĂ«tij artikulli Ă«shtĂ« se span-t janĂ« shumĂ« tĂ« nivelit tĂ« ulĂ«t pĂ«r tĂ« ekstraktuar informacionin mĂ« tĂ« çmuar nga rezultatet e gjurmimeve.
Krahasimi i dy trace-ve nuk kĂ«rkon vizualizime krejt tĂ« reja. NĂ« tĂ« vĂ«rtetĂ«, mjafton diçka si njĂ« histogram, qĂ« pĂ«rfaqĂ«son tĂ« njĂ«jtat tĂ« dhĂ«na si traceview. ĂshtĂ« befasuese, por madje ky metodĂ« e thjeshtĂ« mund tĂ« sjellĂ« shumĂ« mĂ« tepĂ«r pĂ«rfitime se sa thjesht studimi i dy trace-ve pĂ«r veçmas. NjĂ« mundĂ«si akoma mĂ« e fuqishme do tĂ« ishte vizualizoni krahasimi i traceâave nĂ« pĂ«rmbledhje. Do tĂ« ishte jashtĂ«zakonisht e dobishme tĂ« shihnim se si ndarja e re e konfiguracionit tĂ« bazĂ«s sĂ« tĂ« dhĂ«nave me aktivizimin e GC (grumbullimin e mbetjeve) ndikon nĂ« kohĂ«n e pĂ«rgjigjes tĂ« shĂ«rbimit downstream pĂ«r njĂ« periudhĂ« disa orĂ«she. NĂ«se ajo qĂ« po pĂ«rshkruaj kĂ«tu duket si njĂ« analizĂ« A/B e ndikimit tĂ« ndryshimeve nĂ« infrastrukturĂ« nĂ« shumĂ« shĂ«rbime me rezultatet e gjurmimit, atĂ«herĂ« nuk jeni shumĂ« larg sĂ« vĂ«rtetĂ«s.
PĂ«rfundim
Nuk e vë në dyshim përdorimin e vetë gjurmimit. I besoj sinqerisht se nuk ka metodë tjetër për të mbledhur të dhëna po aq të pasura, kalimtare dhe kontekstuale si ato që përmbahen në një trace. Megjithatë, besoj gjithashtu se të gjitha zgjidhjet e gjurmimit e përdorin këtë të dhënë jashtëzakonisht paefektivisht. Derisa mjetet e gjurmimit të përqendrohen në paraqitjen e traceview, ato do të jenë të kufizuara në aftësinë për të shfrytëzuar maksimalisht informacionin e çmuar që mund të nxirret nga të dhënat që përmbahen në gjurmë. Për më tepër, ekziston rreziku i zhvillimit të një ndërfaqe vizuale krejtësisht jo miqësore dhe jo intuitiv, e cila do të kufizojë ashpër aftësinë e përdoruesit për të zgjidhur gabimet në aplikacion.
Debugimi i sistemeve komplekse, madje edhe me përdorimin e mjeteve më të fundit, është jashtëzakonisht i vështirë. Mjetet duhet të ndihmojnë zhvilluesin të formulonte dhe testonte një hipotezë, duke ofruar aktivisht informacione relevante, duke identifikuar përjashtimet dhe duke vërejtur karakteristikat në shpërndarjen e vonesave. Në mënyrë që gjurmimi të bëhet mjeti i preferuar i zhvilluesve për të zgjidhur defektet në prodhim ose për të adresuar probleme që përfshijnë shërbime të ndryshme, nevojiten ndërfaqe dhe vizualizime origjinale që i përgjigjen më shumë modelit mendor të zhvilluesve që krijojnë dhe operojnë këto shërbime.
Do tĂ« nevojiten pĂ«rpjekje tĂ« mĂ«dha mendore 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 analizimin dhe arsyetimin. Duhet menduar se si tĂ« abstrahohet topologjia e sistemit gjatĂ« debugimit pĂ«r tĂ« ndihmuar pĂ«rdoruesin tĂ« kapĂ«rcejĂ« zonat e verbra, pa shkuar nĂ« traceâave ose spanâave tĂ« veçanta.
Na nevojiten një qasje e fortë për abstragimin dhe ndarjen në nivele (veçanërisht në UI). E tillë që përshtatet mirë në procesin e debugut të bazuar në hipoteza, ku mund të parashtroni pyetje dhe të testoni hipotezat iterativisht. Ato nuk do ta zgjidhin automatikisht të gjitha problemet me vëzhgueshmërinë, por do t'u ndihmojnë përdoruesve të rafinojnë intuitën dhe të formulojnë pyetje më të menduara. Ftoj një qasje më të reflektuar dhe inovative në fushën e vizualizimit. Këtu ka një perspektivë të vërtetë për të zgjeruar horizontet.
P.S. nga përkthyesi
Lexoni gjithashtu në blogun tonë:
- «»;
- «»;
- «».
Burimi: habr.com
