IzplatÄ«ta izsekoÅ”ana: mēs to visu izdarÄ«jām nepareizi

PiezÄ«me. tulk.: Å Ä« materiāla autore ir Sindija Sridharana, imgix inženiere, kas specializējas API izstrādē un jo Ä«paÅ”i mikropakalpojumu testÄ“Å”anā. Å ajā materiālā viņa dalās ar savu detalizēto redzējumu par aktuālajām problēmām izplatÄ«tās izsekoÅ”anas jomā, kur, viņasprāt, trÅ«kst patiesi efektÄ«vu instrumentu aktuālu problēmu risināŔanai.

IzplatÄ«ta izsekoÅ”ana: mēs to visu izdarÄ«jām nepareizi
[Ilustrācija ņemta no cits materiāls par izplatÄ«to izsekoÅ”anu.]

Tiek uzskatÄ«ts, ka izplatÄ«ta izsekoÅ”ana grÅ«ti Ä«stenot, un atdeve no tā labākajā gadÄ«jumā apÅ”aubāmi. Ir daudz iemeslu, kāpēc izsekoÅ”ana ir problemātiska, bieži atsaucoties uz darbu, kas saistÄ«ts ar katra sistēmas komponenta konfigurÄ“Å”anu, lai ar katru pieprasÄ«jumu pārsÅ«tÄ«tu atbilstoŔās galvenes. Lai gan Ŕī problēma pastāv, tā nekādā gadÄ«jumā nav nepārvarama. Starp citu, tas neizskaidro, kāpēc izstrādātājiem Ä«sti nepatÄ«k izsekoÅ”ana (pat ja tā jau darbojas).

IzplatÄ«tās izsekoÅ”anas galvenā problēma nav datu vākÅ”ana, rezultātu izplatÄ«Å”anas un prezentÄ“Å”anas formātu standartizÄ“Å”ana vai paraugu ņemÅ”anas brīža, vietas un veida noteikÅ”ana. Es nemēģinu iedomāties triviāls Ŕīs "saprotamÄ«bas problēmas" patiesÄ«bā ir diezgan nozÄ«mÄ«gas tehniskas un (ja mēs domājam par patiesi atvērtā pirmkoda) standartiem un protokoliem) politiskās problēmas, kas jāpārvar, lai Ŕīs problēmas uzskatÄ«tu par atrisinātām.

Taču, ja iedomājamies, ka visas Ŕīs problēmas ir atrisinātas, pastāv liela varbÅ«tÄ«ba, ka nekas bÅ«tiski nemainÄ«sies gala lietotāja pieredzi. IzsekoÅ”ana joprojām var nebÅ«t praktiski noderÄ«ga visbiežāk sastopamajos atkļūdoÅ”anas scenārijos ā€” pat pēc tās izvietoÅ”anas.

Tāda cita pēda

Izplatītā izsekoŔana ietver vairākas atŔķirīgas sastāvdaļas:

  • lietojumprogrammu un starpprogrammatÅ«ras aprÄ«koÅ”ana ar vadÄ«bas rÄ«kiem;
  • izplatÄ«ta konteksta pārsÅ«tÄ«Å”ana;
  • pēdu savākÅ”ana;
  • pēdu uzglabāŔana;
  • to iegÅ«Å”ana un vizualizācija.

Daudzas runas par izplatÄ«to izsekoÅ”anu mēdz to uzskatÄ«t par savdabÄ«gu operāciju, kuras vienÄ«gais mērÄ·is ir palÄ«dzēt pilnÄ«bā diagnosticēt sistēmu. Tas lielā mērā ir saistÄ«ts ar to, kā vēsturiski ir veidojuŔās idejas par izplatÄ«to izsekoÅ”anu. IN emuāra ieraksti, kas izgatavots, kad tika atvērti Zipkin avoti, tika minēts, ka tas [Zipkin] padara Twitter ātrāku. Pirmie komerciālie piedāvājumi izsekoÅ”anai tika reklamēti arÄ« kā APM rÄ«ki.

PiezÄ«me. tulk.: Lai turpmāk teksts bÅ«tu vieglāk saprotams, definēsim divus pamatjēdzienus atbilstoÅ”i OpenTracing projekta dokumentācija:

  • SprÄ«dis ā€” izplatÄ«tās izsekoÅ”anas pamatelements. Tas ir noteiktas darbplÅ«smas (piemēram, datu bāzes vaicājuma) apraksts ar nosaukumu, sākuma un beigu laiku, tagiem, žurnāliem un kontekstu.
  • Laipumos parasti ir saites uz citiem laidumiem, ļaujot apvienot vairākus laidumus izsekot ā€” pieprasÄ«juma darbÄ«bas vizualizācija, kad tas pārvietojas pa sadalÄ«to sistēmu.

Traces satur neticami vērtÄ«gus datus, kas var palÄ«dzēt veikt tādus uzdevumus kā ražoÅ”anas testÄ“Å”ana, avārijas atkopÅ”anas pārbaude, kļūdu ievadÄ«Å”anas pārbaude utt. Faktiski daži uzņēmumi jau izmanto izsekoÅ”anu lÄ«dzÄ«giem mērÄ·iem. Sāksim ar universāla konteksta pārneÅ”ana tam ir arÄ« citi lietojumi, ne tikai vienkārÅ”i pārvietoÅ”ana uz glabāŔanas sistēmu:

  • Piemēram, Uber izmanto izsekoÅ”anas rezultātus, lai atŔķirtu testa trafiku un ražoÅ”anas trafiku.
  • Facebook izmanto izsekot datus kritisko ceļu analÄ«zei un satiksmes pārslēgÅ”anai regulāru avārijas atkopÅ”anas testu laikā.
  • ArÄ« sociālais tÄ«kls attiecas Jupyter piezÄ«mjdatori, kas ļauj izstrādātājiem palaist patvaļīgus vaicājumus izsekoÅ”anas rezultātiem.
  • Sekotāji LDFI (Lineage Driven Failure Injection) izmantot izplatÄ«ja pēdas testÄ“Å”anai ar kļūdu ievadÄ«Å”anu.

Neviena no iepriekÅ” minētajām opcijām pilnÄ«bā neattiecas uz Å”o scenāriju atkļūdoÅ”ana, kuras laikā inženieris mēģina atrisināt problēmu, aplÅ«kojot pēdas.

Kad tas nāk tomēr sasniedz atkļūdoÅ”anas skriptu, primārais interfeiss paliek diagramma traceview (lai gan daži to arÄ« sauc "Ganta diagramma" vai "Å«denskrituma diagramma"). Zem traceview я ES domāju visi laidumi un pavadoÅ”ie metadati, kas kopā veido izsekoÅ”anu. Katra atvērtā pirmkoda izsekoÅ”anas sistēma, kā arÄ« katrs komerciālais izsekoÅ”anas risinājums piedāvā a traceview lietotāja interfeiss pēdu vizualizÄ“Å”anai, detalizācijai un filtrÄ“Å”anai.

Problēma ar visām izsekoÅ”anas sistēmām, ko esmu redzējis lÄ«dz Å”im, ir tā, ka rezultāts vizualizācija (traceview) gandrÄ«z pilnÄ«bā atspoguļo pēdu Ä£enerÄ“Å”anas procesa iezÄ«mes. Pat tad, ja tiek piedāvātas alternatÄ«vas vizualizācijas: siltuma kartes, pakalpojumu topoloÄ£ijas, latentuma histogrammas, galu galā tās joprojām ir traceview.

Agrāk es sÅ«dzējās Ŕķiet, ka lielākā daļa "inovāciju" UI/UX izsekoÅ”anas jomā ir ierobežotas ieslēdzoties papildu metadatus izsekot, ieguldot tajos informāciju ar augstu kardinalitāti (augsta kardinalitāte) vai nodroÅ”inot iespēju veikt dziļas darbÄ«bas konkrētos diapazonos vai izpildÄ«t vaicājumus inter- un intra-trace... Kurā vietā traceview joprojām ir galvenais vizualizācijas rÄ«ks. Kamēr Å”is stāvoklis turpināsies, izplatÄ«tā izsekoÅ”ana (labākajā gadÄ«jumā) ieņems 4. vietu kā atkļūdoÅ”anas rÄ«ks pēc metrikas, žurnāliem un steku pēdām, un sliktākajā gadÄ«jumā tā izrādÄ«sies naudas un laika izŔķieÅ”ana.

Problēma ar traceview

Destinies traceview ā€” sniedz pilnÄ«gu priekÅ”statu par viena pieprasÄ«juma kustÄ«bu visos izplatÄ«tās sistēmas komponentos, ar kuriem tas ir saistÄ«ts. Dažas uzlabotas izsekoÅ”anas sistēmas ļauj urbt atseviŔķos diapazonos un skatÄ«t sadalÄ«jumu laika gaitā laikā viens process (kad laidumiem ir funkcionālas robežas).

Mikropakalpojumu arhitektÅ«ras pamatprincips ir ideja, ka organizatoriskā struktÅ«ra aug lÄ«dz ar uzņēmuma vajadzÄ«bām. Mikropakalpojumu atbalstÄ«tāji apgalvo, ka dažādu biznesa uzdevumu sadale atseviŔķos pakalpojumos ļauj mazām, autonomām izstrādes komandām kontrolēt visu Ŕādu pakalpojumu dzÄ«ves ciklu, dodot tām iespēju neatkarÄ«gi izveidot, pārbaudÄ«t un izvietot Å”os pakalpojumus. Tomēr Ŕīs izplatÄ«Å”anas trÅ«kums ir informācijas zudums par to, kā katrs pakalpojums mijiedarbojas ar citiem. Šādos apstākļos izplatÄ«tā izsekoÅ”ana tiek uzskatÄ«ta par neaizstājamu lÄ«dzekli atkļūdoÅ”ana sarežģīta mijiedarbÄ«ba starp pakalpojumiem.

Ja jÅ«s patieŔām satriecoÅ”i sarežģīta izplatÄ«ta sistēma, tad ne viens vien nespēj to paturēt savā galvā pabeigta bilde. Faktiski tāda rÄ«ka izstrāde, kas balstās uz pieņēmumu, ka tas ir pat iespējams, ir kaut kas tāds kā pretmodelis (neefektÄ«va un neproduktÄ«va pieeja). Ideālā gadÄ«jumā atkļūdoÅ”anai ir nepiecieÅ”ams rÄ«ks, kas palÄ«dz saÅ”auriniet meklÄ“Å”anas apgabalu, lai inženieri varētu koncentrēties uz dimensiju apakÅ”kopu (pakalpojumi/lietotāji/saimnieki utt.), kas attiecas uz aplÅ«kojamo problēmas scenāriju. Nosakot kļūmes cēloni, inženieriem nav jāsaprot, kas notika darbÄ«bas laikā visus pakalpojumus uzreiz, jo Ŕāda prasÄ«ba bÅ«tu pretrunā paÅ”ai mikropakalpojumu arhitektÅ«ras idejai.

Tomēr traceview ir proti Å is. Jā, dažas izsekoÅ”anas sistēmas piedāvā saspiestus trasÄ“Å”anas skatus, ja trasē esoÅ”o laidumu skaits ir tik liels, ka tos nevar parādÄ«t vienā vizualizācijā. Tomēr, ņemot vērā lielo informācijas daudzumu, kas ietverts pat Ŕādā attÄ«rÄ«tā vizualizācijā, inženieri joprojām piespiedu kārtā ā€œizsijātā€ to, manuāli saÅ”aurinot atlasi lÄ«dz pakalpojumu kopumam, kas rada problēmas. Diemžēl Å”ajā jomā maŔīnas ir daudz ātrākas par cilvēkiem, mazāk pakļautas kļūdām, un to rezultāti ir vairāk atkārtojami.

Vēl viens iemesls, kāpēc es uzskatu, ka traceview ir nepareizs, ir tas, ka tas nav piemērots hipotēžu vadÄ«tai atkļūdoÅ”anai. Tās pamatā ir atkļūdoÅ”ana iteratÄ«vs process sākas ar hipotēzi, kam seko dažādu novērojumu un no sistēmas iegÅ«to faktu pārbaude pa dažādiem vektoriem, secinājumi/vispārinājumi un tālāka hipotēzes patiesuma izvērtÄ“Å”ana.

Iespēja ātri un lēti hipotēžu pārbaude un attiecÄ«gi garÄ«gā modeļa uzlaboÅ”ana ir stÅ«rakmens atkļūdoÅ”ana Jebkuram atkļūdoÅ”anas rÄ«kam jābÅ«t interaktÄ«vs un saÅ”auriniet meklÄ“Å”anas laukumu vai, ja ir viltus potenciāls, ļaujiet lietotājam atgriezties un koncentrēties uz citu sistēmas apgabalu. Ideāls rÄ«ks to darÄ«s aktÄ«vi, nekavējoties pievērÅ”ot lietotāja uzmanÄ«bu iespējamām problēmzonām.

Diemžēl traceview nevar saukt par rÄ«ku ar interaktÄ«vu saskarni. Labākais, uz ko varat cerēt, to lietojot, ir atrast kādu palielināta latentuma avotu un apskatÄ«t visus iespējamos ar to saistÄ«tos tagus un žurnālus. Tas nepalÄ«dz inženierim identificēt modeļiem satiksmē, piemēram, aizkaves sadalÄ«juma specifiku, vai atklāt korelācijas starp dažādiem mērÄ«jumiem. Vispārēja pēdu analÄ«ze var palÄ«dzēt apiet dažas no Ŕīm problēmām. TieŔām, ir piemēri veiksmÄ«ga analÄ«ze, izmantojot maŔīnmācÄ«Å”anos, lai identificētu anomālus diapazonus un noteiktu tagu apakÅ”kopu, kas var bÅ«t saistÄ«ta ar anomālu uzvedÄ«bu. Tomēr es vēl neesmu redzējis pārliecinoÅ”as maŔīnmācÄ«Å”anās vai datu ieguves atklājumu vizualizācijas, kas tiek piemērotas diapazoniem, kas ievērojami atŔķiras no trasÄ“Å”anas skata vai DAG (virzÄ«tā acikliskā diagramma).

Laidieni ir pārāk zemā līmenī

Traceview galvenā problēma ir tā laidumi ir pārāk zema lÄ«meņa primitÄ«vi gan latentuma analÄ«zei, gan pamatcēloņa analÄ«zei. Tas ir tāpat kā atseviŔķu procesora komandu parsÄ“Å”ana, lai mēģinātu atrisināt izņēmumu, zinot, ka ir daudz augstāka lÄ«meņa rÄ«ki, piemēram, backtrace, ar kuriem ir daudz ērtāk strādāt.

Turklāt es atļauÅ”os apgalvot sekojoÅ”o: ideālā gadÄ«jumā mums tas nav vajadzÄ«gs pilns attēls radās pieprasÄ«juma dzÄ«ves cikla laikā, ko attēlo mÅ«sdienÄ«gi izsekoÅ”anas rÄ«ki. Tā vietā ir nepiecieÅ”ama kāda augstāka lÄ«meņa abstrakcijas forma, kas satur informāciju par to, ko nogāja greizi (lÄ«dzÄ«gi kā backtrace), kopā ar kādu kontekstu. Tā vietā, lai skatÄ«tos visu pēdu, es labprātāk to redzu чŠ°ŃŃ‚ŃŒ, kur notiek kas interesants vai neparasts. PaÅ”laik meklÄ“Å”ana tiek veikta manuāli: inženieris saņem izsekojumu un neatkarÄ«gi analizē diapazonus, meklējot kaut ko interesantu. Cilvēku pieeja, kas skatās uz diapazoniem atseviŔķās pēdās, cerot atklāt aizdomÄ«gu darbÄ«bu, vispār nav mērogota (Ä«paÅ”i, ja viņiem ir jāsaprot visi dažādos diapazonos kodētie metadati, piemēram, diapazona ID, RPC metodes nosaukums, diapazona ilgums 'a, žurnāli, tagi utt.).

Traceview alternatīvas

IzsekoÅ”anas rezultāti ir visnoderÄ«gākie, ja tos var vizualizēt tādā veidā, kas sniedz nenozÄ«mÄ«gu ieskatu par to, kas notiek savstarpēji savienotajās sistēmas daļās. Kamēr tas nenotiek, atkļūdoÅ”anas process lielākoties turpinās inerts un tas ir atkarÄ«gs no lietotāja spējas pamanÄ«t pareizās korelācijas, pārbaudÄ«t pareizās sistēmas daļas vai salikt puzles daļas ā€“ pretēji rÄ«ks, palÄ«dzot lietotājam formulēt Ŕīs hipotēzes.

Es neesmu vizuālais dizainers vai UX speciālists, bet nākamajā sadaļā vēlos dalÄ«ties ar dažām idejām par to, kā Ŕīs vizualizācijas varētu izskatÄ«ties.

Koncentrējieties uz konkrētiem pakalpojumiem

Laikā, kad nozare konsolidējas ap idejām SLO (pakalpojuma lÄ«meņa mērÄ·i) un SLI (pakalpojuma lÄ«meņa rādÄ«tāji), Ŕķiet saprātÄ«gi, ka atseviŔķām komandām par prioritāti ir jānodroÅ”ina to pakalpojumu atbilstÄ«ba Å”iem mērÄ·iem. No tā izriet, ka orientēts uz pakalpojumu vizualizācija ir vislabāk piemērota Ŕādām komandām.

Trases, Ä«paÅ”i bez paraugu ņemÅ”anas, ir informācijas dārgums par katru sadalÄ«tās sistēmas komponentu. Å o informāciju var ievadÄ«t viltÄ«gam procesoram, kas apgādās lietotājus orientēts uz pakalpojumu atklājumus. Tos var identificēt jau iepriekÅ” ā€“ pat pirms lietotājs apskata pēdas:

  1. Latenta sadalījuma diagrammas tikai ļoti pamanāmiem pieprasījumiem (ārpusēji pieprasījumi);
  2. Aizkaves sadalījuma diagrammas gadījumiem, kad pakalpojuma SLO mērķi nav sasniegti;
  3. ā€œVisparastākieā€, ā€œinteresantākieā€ un ā€œdÄ«vainākieā€ tagi vaicājumos, kas visbiežāk tiek atkārtoti;
  4. Latenta sadalījums gadījumiem, kad atkarības pakalpojumi nesasniedz savus SLO mērķus;
  5. Latenta sadalījums dažādiem pakārtotajiem pakalpojumiem.

IebÅ«vētie rādÄ«tāji vienkārÅ”i neatbild uz dažiem no Å”iem jautājumiem, liekot lietotājiem rÅ«pÄ«gi pārbaudÄ«t diapazonus. Rezultātā mums ir lietotājam ārkārtÄ«gi naidÄ«gs mehānisms.

Tas rada jautājumu: kā ir ar sarežģītu mijiedarbÄ«bu starp dažādiem pakalpojumiem, ko kontrolē dažādas komandas? Vai nav traceview netiek uzskatÄ«ts par piemērotāko lÄ«dzekli Ŕādas situācijas izcelÅ”anai?

Mobilo ierīču izstrādātājus, bezvalstnieku pakalpojumu Ä«paÅ”niekus, pārvaldÄ«tu statusu pakalpojumu (piemēram, datubāzu) Ä«paÅ”niekus un platformu Ä«paÅ”niekus var interesēt kas cits prezentācija izplatÄ«ta sistēma; traceview ir pārāk vispārÄ«gs risinājums Ŕīm bÅ«tiski atŔķirÄ«gajām vajadzÄ«bām. Pat ļoti sarežģītā mikropakalpojumu arhitektÅ«rā pakalpojumu Ä«paÅ”niekiem nav vajadzÄ«gas dziļas zināŔanas par vairāk nekā diviem vai trim augÅ”upējiem un pakārtotiem pakalpojumiem. BÅ«tÄ«bā vairumā gadÄ«jumu lietotājiem ir jāatbild tikai uz jautājumiem par ierobežots pakalpojumu komplekts.

Tas ir tāpat kā skatÄ«t nelielu pakalpojumu apakÅ”kopu caur palielināmo stiklu, lai to rÅ«pÄ«gi pārbaudÄ«tu. Tas ļaus lietotājam uzdot aktuālākus jautājumus par sarežģīto mijiedarbÄ«bu starp Å”iem pakalpojumiem un to tieÅ”ajām atkarÄ«bām. Tas ir lÄ«dzÄ«gi kā backtrace pakalpojumu pasaulē, kur inženieris zina ka nepareizi, un viņam ir arÄ« zināma izpratne par to, kas notiek apkārtējos pakalpojumos kāpēc.

Manis popularizētā pieeja ir tieÅ”i pretēja lejupējai, uz traceview balstÄ«tai pieejai, kur analÄ«ze sākas ar visu trasÄ“Å”anu un pēc tam pakāpeniski pāriet uz atseviŔķiem diapazoniem. Turpretim augÅ”upējā pieeja sākas, analizējot nelielu apgabalu, kas atrodas tuvu iespējamajam incidenta cēlonim, un pēc tam paplaÅ”ina meklÄ“Å”anas telpu pēc vajadzÄ«bas (ar iespēju piesaistÄ«t citas komandas, lai analizētu plaŔāku pakalpojumu klāstu). Otrā pieeja ir labāk piemērota sākotnējo hipotēžu ātrai pārbaudei. Kad bÅ«s iegÅ«ti konkrēti rezultāti, bÅ«s iespējams pāriet uz mērÄ·tiecÄ«gāku un detalizētāku analÄ«zi.

Topoloģijas veidoŔana

Pakalpojuma skati var bÅ«t neticami noderÄ«gi, ja lietotājs to zina ko pakalpojums vai pakalpojumu grupa ir atbildÄ«gs par latentuma palielināŔanu vai kļūdu izraisÄ«Å”anu. Tomēr sarežģītā sistēmā pārkāpēja pakalpojuma identificÄ“Å”ana kļūmes laikā var bÅ«t nenozÄ«mÄ«gs uzdevums, it Ä«paÅ”i, ja no pakalpojumiem netika ziņots par kļūdu ziņojumiem.

Pakalpojuma topoloÄ£ijas izveide var bÅ«t ļoti noderÄ«ga, lai noskaidrotu, kurā pakalpojumā ir kļūdas lÄ«meņa pieaugums vai latentuma palielināŔanās, kas izraisa pakalpojuma ievērojamu pasliktināŔanos. Kad es runāju par topoloÄ£ijas veidoÅ”anu, es to nedomāju pakalpojumu karte, kurā tiek parādÄ«ti visi sistēmā pieejamie un ar to pazÄ«stami pakalpojumi arhitektÅ«ras kartes nāves zvaigznes formā. Å is skats nav labāks par traceview, kas balstÄ«ts uz virzÄ«tu aciklisku grafiku. Tā vietā es gribētu redzēt dinamiski Ä£enerēta pakalpojumu topoloÄ£ija, pamatojoties uz noteiktiem atribÅ«tiem, piemēram, kļūdu biežumu, reakcijas laiku vai jebkuru lietotāja definētu parametru, kas palÄ«dz noskaidrot situāciju ar konkrētiem aizdomÄ«giem pakalpojumiem.

Ņemsim piemēru. Iedomāsimies hipotētisku ziņu vietni. Mājas lapas pakalpojums (priekŔējā lapa) apmainās ar datiem ar Redis, ar ieteikumu pakalpojumu, ar reklāmas pakalpojumu un video pakalpojumu. Video pakalpojums ņem video no S3 un metadatus no DynamoDB. Ieteikumu pakalpojums saņem metadatus no DynamoDB, ielādē datus no Redis un MySQL un raksta ziņojumus Kafka. Reklāmas pakalpojums saņem datus no MySQL un raksta ziņojumus Kafkai.

Zemāk ir shematisks Ŕīs topoloÄ£ijas attēlojums (daudzas komerciālas marÅ”rutÄ“Å”anas programmas veido topoloÄ£iju). Tas var bÅ«t noderÄ«gi, ja jums ir jāsaprot pakalpojumu atkarÄ«bas. Tomēr laikā atkļūdoÅ”ana, ja noteiktam pakalpojumam (piemēram, video pakalpojumam) ir palielināts reakcijas laiks, Ŕāda topoloÄ£ija nav Ä«paÅ”i noderÄ«ga.

IzplatÄ«ta izsekoÅ”ana: mēs to visu izdarÄ«jām nepareizi
Hipotētiskas ziņu vietnes pakalpojumu diagramma

Zemāk redzamā diagramma bÅ«tu piemērotāka. Radās problēma ar pakalpojumu (video) attēlots tieÅ”i centrā. Lietotājs to uzreiz pamana. No Ŕīs vizualizācijas kļūst skaidrs, ka video pakalpojums darbojas neparasti, jo palielinās S3 reakcijas laiks, kas ietekmē galvenās lapas daļas ielādes ātrumu.

IzplatÄ«ta izsekoÅ”ana: mēs to visu izdarÄ«jām nepareizi
Dinamiskā topoloÄ£ija, kas parāda tikai ā€œinteresantosā€ pakalpojumus

Dinamiski Ä£enerētas topoloÄ£ijas var bÅ«t efektÄ«vākas nekā statiskās pakalpojumu kartes, Ä«paÅ”i elastÄ«gās, automātiskās mērogoÅ”anas infrastruktÅ«rās. Iespēja salÄ«dzināt un pretstatÄ«t pakalpojumu topoloÄ£ijas ļauj lietotājam uzdot atbilstoŔākus jautājumus. PrecÄ«zāki jautājumi par sistēmu, visticamāk, ļaus labāk izprast, kā sistēma darbojas.

SalīdzinoŔais displejs

Vēl viena noderÄ«ga vizualizācija bÅ«tu salÄ«dzinoÅ”s displejs. PaÅ”laik pēdas nav Ä«paÅ”i piemērotas salÄ«dzināŔanai lÄ«dzās, tāpēc salÄ«dzinājumi parasti ir laidumi. Un Ŕī raksta galvenā doma ir tieÅ”i tāda, ka laidumi ir pārāk zemi, lai no izsekoÅ”anas rezultātiem iegÅ«tu visvērtÄ«gāko informāciju.

Divu pēdu salÄ«dzināŔanai nav nepiecieÅ”amas principiāli jaunas vizualizācijas. Faktiski pietiek ar tādu paÅ”u informāciju kā histogramma, kas attēlo traceview. PārsteidzoÅ”i, pat Ŕī vienkārŔā metode var dot daudz vairāk augļu nekā vienkārÅ”a divu pēdu izpēte atseviŔķi. Iespēja bÅ«tu vēl jaudÄ«gāka vizualizēt pēdu salÄ«dzinājums Kopā. BÅ«tu ļoti noderÄ«gi redzēt, kā nesen izvietotās datu bāzes konfigurācijas izmaiņas, lai iespējotu GC (atkritumu savākÅ”anu), ietekmē pakārtotā pakalpojuma reakcijas laiku vairāku stundu mērogā. Ja tas, ko es Å”eit aprakstu, izklausās pēc A/B analÄ«zes par infrastruktÅ«ras izmaiņu ietekmi daudzos pakalpojumos izmantojot izsekoÅ”anas rezultātus, jÅ«s neesat pārāk tālu no patiesÄ«bas.

Secinājums

Es neapÅ”aubu paÅ”as izsekoÅ”anas lietderÄ«bu. Es patiesi uzskatu, ka nav citas metodes, lai savāktu tik bagātÄ«gus, cēloņsakarÄ«gus un kontekstuālus datus kā pēdās. Tomēr es arÄ« uzskatu, ka visi izsekoÅ”anas risinājumi Å”os datus izmanto ārkārtÄ«gi neefektÄ«vi. Kamēr izsekoÅ”anas rÄ«ki paliks iestrēguÅ”i traceview attēlojumā, to spēja maksimāli izmantot vērtÄ«go informāciju, ko var iegÅ«t no trasēs ietvertajiem datiem, bÅ«s ierobežota. Turklāt pastāv risks, ka turpmāk tiks izstrādāts pilnÄ«gi nedraudzÄ«gs un neintuitÄ«vs vizuālais interfeiss, kas ievērojami ierobežos lietotāja iespējas novērst kļūdas lietojumprogrammā.

Sarežģītu sistēmu atkļūdoÅ”ana pat ar jaunākajiem rÄ«kiem ir neticami sarežģīta. RÄ«kiem ir jāpalÄ«dz izstrādātājam formulēt un pārbaudÄ«t hipotēzi, aktÄ«vi nodroÅ”inot attiecÄ«go informāciju, identificējot novirzes un atzÄ«mējot kavējumu sadalÄ«juma pazÄ«mes. Lai izsekoÅ”ana kļūtu par izstrādātāju izvēles rÄ«ku, novērÅ”ot ražoÅ”anas kļūmes vai risinot problēmas, kas aptver vairākus pakalpojumus, ir nepiecieÅ”amas oriÄ£inālas lietotāja saskarnes un vizualizācijas, kas vairāk atbilst to izstrādātāju garÄ«gajam modelim, kuri veido un apkalpo Å”os pakalpojumus.

Lai izstrādātu sistēmu, kas attēlos dažādos izsekoÅ”anas rezultātos pieejamos signālus tādā veidā, kas ir optimizēts, lai atvieglotu analÄ«zi un secinājumus, bÅ«s vajadzÄ«gas ievērojamas pÅ«les. Jums ir jādomā par to, kā atkļūdoÅ”anas laikā abstrahēt sistēmas topoloÄ£iju tā, lai palÄ«dzētu lietotājam pārvarēt aklās zonas, neapskatot atseviŔķas pēdas vai laidumus.

Mums ir vajadzÄ«gas labas abstrakcijas un slāņoÅ”anas iespējas (Ä«paÅ”i lietotāja saskarnē). Tie, kas labi iederētos uz hipotēzēm balstÄ«tā atkļūdoÅ”anas procesā, kurā varat iteratÄ«vi uzdot jautājumus un pārbaudÄ«t hipotēzes. Tie automātiski neatrisinās visas novērojamÄ«bas problēmas, taču palÄ«dzēs lietotājiem uzlabot intuÄ«ciju un formulēt gudrākus jautājumus. Aicinu uz pārdomātāku un inovatÄ«vāku pieeju vizualizācijai. Å eit ir reālas iespējas paplaÅ”ināt redzesloku.

PS no tulka

Lasi arī mūsu emuārā:

Avots: www.habr.com

Pievieno komentāru