Նշում. թարգմ.Այս նյութի հեղինակը Սինդի Սրիդարանն է՝ imgix-ի ինժեներ, ով մասնագիտացած է API-ի մշակման և, մասնավորապես, միկրոսերվիսների փորձարկման մեջ: Այս նյութում նա կիսվում է բաշխված հետագծման ոլորտում առկա խնդիրների իր մանրամասն տեսլականով, որտեղ, նրա կարծիքով, հրատապ խնդիրների լուծման իսկապես արդյունավետ գործիքների պակաս կա:
[Նկարազարդումը վերցված է բաշխված հետագծման մասին։]
Ենթադրվում է, որ դժվար է իրականացնել, և դրա վերադարձը . Կան բազմաթիվ պատճառներ, թե ինչու է հետագծումը խնդրահարույց, հաճախ մատնանշելով այն աշխատանքը, որը ներգրավված է համակարգի յուրաքանչյուր բաղադրիչի կազմաձևման համար՝ յուրաքանչյուր հարցումով համապատասխան վերնագրերը փոխանցելու համար: Չնայած այս խնդիրը գոյություն ունի, սակայն այն ոչ մի կերպ անհաղթահարելի չէ։ Ի դեպ, դա չի բացատրում, թե ինչու մշակողները իսկապես չեն սիրում հետագծում (նույնիսկ երբ այն արդեն գործում է):
Բաշխված հետագծման հետ կապված հիմնական մարտահրավերը տվյալների հավաքագրումը, արդյունքների բաշխման և ներկայացման ձևաչափերի ստանդարտացումը կամ ընտրանքը երբ, որտեղ և ինչպես ընտրելը չէ: Չեմ փորձում պատկերացնել չնչին Այս «հասկանալիության խնդիրները», ըստ էության, բավականին նշանակալի տեխնիկական են և (եթե մենք իսկապես բաց կոդով ենք նկատի ունենում) ) քաղաքական մարտահրավերներ, որոնք պետք է հաղթահարվեն, որպեսզի այդ խնդիրները լուծված համարվեն։
Սակայն, եթե պատկերացնենք, որ այս բոլոր խնդիրները լուծված են, ապա մեծ է հավանականությունը, որ էականորեն ոչինչ չի փոխվի. վերջնական օգտագործողի փորձը. Հետագծումը կարող է դեռևս գործնական կիրառություն չունենալ վրիպազերծման ամենատարածված սցենարներում, նույնիսկ այն գործարկվելուց հետո:
Այսքան տարբեր հետք
Բաշխված հետագծումը ներառում է մի քանի տարբեր բաղադրիչներ.
- հավելվածների և միջին ծրագրերի համալրում կառավարման գործիքներով.
- բաշխված համատեքստի փոխանցում;
- հետքերի հավաքածու;
- հետքերի պահպանում;
- դրանց արդյունահանումը և արտացոլումը:
Բաշխված հետագծման մասին շատ խոսակցությունները հակված են այն դիտարկել որպես միատարր գործողության, որի միակ նպատակն է օգնել համակարգի ամբողջական ախտորոշմանը: Սա մեծապես պայմանավորված է նրանով, թե ինչպես են պատմականորեն ձևավորվել բաշխված հետագծման մասին պատկերացումները: IN , արված այն ժամանակ, երբ բացվեցին Zipkin աղբյուրները, նշվեց, որ այն [Zipkin]-ն ավելի արագ է դարձնում Twitter-ը. Հետագծման համար առաջին առևտրային առաջարկները նույնպես խթանվեցին որպես .
Նշում. թարգմ.Հետագա տեքստը ավելի հեշտ հասկանալու համար եկեք սահմանենք երկու հիմնական տերմին ըստ :
- Span - բաշխված հետագծման հիմնական տարրը: Դա որոշակի աշխատանքային հոսքի նկարագրություն է (օրինակ՝ տվյալների բազայի հարցում)՝ անունով, սկզբի և ավարտի ժամանակներով, պիտակներով, տեղեկամատյաններով և համատեքստով:
- Ընդարձակությունները սովորաբար պարունակում են հղումներ դեպի այլ տարածություններ, ինչը թույլ է տալիս մի քանի բացվածքներ միավորել մեջ Հետեւեք — խնդրանքի կյանքի պատկերացում, երբ այն շարժվում է բաշխված համակարգով:
Հետքերը պարունակում են աներևակայելի արժեքավոր տվյալներ, որոնք կարող են օգնել այնպիսի առաջադրանքներում, ինչպիսիք են արտադրության փորձարկումը, աղետի վերականգնման փորձարկումը, սխալի ներարկման փորձարկումը և այլն: Փաստորեն, որոշ ընկերություններ արդեն օգտագործում են հետագծումը նմանատիպ նպատակների համար: Սկսենք նրանից ունի այլ կիրառումներ, բացի միայն պահեստավորման համակարգ տեղափոխելուց.
- Օրինակ՝ Uber-ը հետագծման արդյունքներ՝ փորձնական երթևեկի և արտադրական տրաֆիկի միջև տարբերակելու համար:
- facebook հետագծային տվյալներ կրիտիկական ուղիների վերլուծության և երթևեկության փոխարկման համար աղետների վերականգնման կանոնավոր փորձարկումների ժամանակ:
- Նաև սոցիալական ցանց Jupyter նոթատետրեր, որոնք ծրագրավորողներին թույլ են տալիս կամայական հարցումներ կատարել հետքի արդյունքների վրա:
- Հետևորդներ (Lineage Driven Failure Injection) բաշխված հետքեր փորձարկման համար սխալ ներարկումով:
Վերը թվարկված տարբերակներից ոչ մեկն ամբողջությամբ չի վերաբերում սցենարին վրիպազերծում, որի ընթացքում ինժեները փորձում է խնդիրը լուծել՝ նայելով հետքին։
Երբ այն գալիս է դեռեւս հասնում է վրիպազերծման սկրիպտին, առաջնային ինտերֆեյսը մնում է դիագրամը traceview (թեև ոմանք դա անվանում են «Գանտի աղյուսակ» կամ «Ջրվեժի դիագրամ») Տակ traceview я բոլոր տարածությունները և ուղեկցող մետատվյալները, որոնք միասին կազմում են հետքը: Յուրաքանչյուր բաց կոդով հետագծման համակարգ, ինչպես նաև առևտրային հետագծման յուրաքանչյուր լուծում առաջարկում է ա traceview օգտատիրոջ միջերեսը հետքերը պատկերացնելու, մանրամասնելու և զտելու համար:
Բոլոր հետագծման համակարգերի հետ կապված խնդիրն այն է, որ առաջացել է վիզուալիզացիա (հետագծում) գրեթե ամբողջությամբ արտացոլում է հետքի ստեղծման գործընթացի առանձնահատկությունները: Նույնիսկ երբ առաջարկվում են այլընտրանքային վիզուալիզացիաներ. traceview.
Նախկինում Ի որ UI/UX հետագծման «նորարարությունների» մեծ մասը կարծես սահմանափակված է լրացուցիչ մետատվյալներ հետքի մեջ՝ դրանց մեջ ներդնելով բարձր կարդինալությամբ տեղեկատվություն (բարձր կարդինալություն) կամ տրամադրելով հնարավորություն՝ ներքաշելու որոշակի տարածքներ կամ հարցումներ առաջադրելու միջ- և ներհետք. Այսպես traceview մնում է վիզուալիզացիայի առաջնային գործիքը: Քանի դեռ գործերի այս վիճակը շարունակվում է, բաշխված հետագծումը (լավագույն դեպքում) կզբաղեցնի 4-րդ տեղը որպես վրիպազերծման գործիք՝ չափիչներից, տեղեկամատյաններից և կույտերի հետքերից հետո, իսկ վատագույն դեպքում՝ դա փողի և ժամանակի վատնում կլինի:
Խնդիր traceview-ի հետ
Նպատակը traceview — տրամադրել ամբողջական պատկերացում մեկ հարցման տեղաշարժի մասին բաշխված համակարգի բոլոր բաղադրիչներով, որոնց այն կապված է: Որոշ ավելի առաջադեմ հետագծման համակարգեր թույլ են տալիս խորանալ առանձին բացվածքների մեջ և ժամանակի ընթացքում դիտել անսարքությունները ներսում մեկ գործընթաց (երբ միջանցքները ունեն ֆունկցիոնալ սահմաններ):
Միկրոծառայությունների ճարտարապետության հիմնական նախադրյալն այն գաղափարն է, որ կազմակերպչական կառուցվածքն աճում է ընկերության կարիքներին համապատասխան: Միկրոծառայությունների կողմնակիցները պնդում են, որ տարբեր բիզնես առաջադրանքների բաշխումը առանձին ծառայությունների մեջ թույլ է տալիս փոքր, ինքնավար զարգացման թիմերին վերահսկել նման ծառայությունների ողջ կյանքի ցիկլը, ինչը նրանց հնարավորություն է տալիս ինքնուրույն կառուցել, փորձարկել և տեղակայել այդ ծառայությունները: Այնուամենայնիվ, այս բաշխման թերությունը տեղեկատվության կորուստն է այն մասին, թե ինչպես է յուրաքանչյուր ծառայություն փոխազդում մյուսների հետ: Նման պայմաններում բաշխված հետագծումը պնդում է, որ անփոխարինելի գործիք է վրիպազերծում ծառայությունների միջև բարդ փոխազդեցություն:
Եթե դուք իսկապես , ապա ոչ մի մարդ չի կարողանում դա պահել իր գլխում ամբողջությամբ նկար. Իրականում, գործիք մշակելը, որը հիմնված է այն ենթադրության վրա, որ դա նույնիսկ հնարավոր է, հակաօրինաչափություն է (անարդյունավետ և անարդյունավետ մոտեցում): Իդեալում, վրիպազերծումը պահանջում է գործիք, որն օգնում է նեղացրեք ձեր որոնման տարածքը, որպեսզի ինժեներները կարողանան կենտրոնանալ չափումների ենթաբազմության վրա (ծառայություններ/օգտագործողներ/հոսթներ և այլն), որոնք վերաբերում են դիտարկվող խնդրի սցենարին: Խափանման պատճառը որոշելիս ինժեներներից չի պահանջվում հասկանալ, թե ինչ է տեղի ունեցել դրա ընթացքում բոլոր ծառայությունները միանգամից, քանի որ նման պահանջը կհակասի միկրոսպասարկման ճարտարապետության բուն գաղափարին։
Այնուամենայնիվ, traceview-ն է այն է Սա. Այո, որոշ հետագծման համակարգեր առաջարկում են սեղմված հետագծային դիտումներ, երբ հետքի միջանցքների թիվն այնքան մեծ է, որ դրանք չեն կարող ցուցադրվել մեկ վիզուալիզացիայի մեջ: Այնուամենայնիվ, ինժեներները դեռևս պարունակվող տեղեկատվության մեծ քանակի պատճառով նույնիսկ նման մերկացված վիզուալիզացիայի մեջ ստիպված «մաղեք» այն՝ ձեռքով նեղացնելով ընտրությունը մի շարք ծառայությունների, որոնք խնդիրների աղբյուր են: Ցավոք սրտի, այս ոլորտում մեքենաները շատ ավելի արագ են, քան մարդիկ, ավելի քիչ են հակված սխալների, և դրանց արդյունքներն ավելի կրկնվող են:
Մեկ այլ պատճառ, որ ես կարծում եմ, որ traceview-ը սխալ է, այն է, որ այն լավ չէ հիպոթեզի վրա հիմնված վրիպազերծման համար: Իր հիմքում վրիպազերծումն է կրկնվող գործընթաց, որը սկսվում է հիպոթեզից, որին հաջորդում է տարբեր վեկտորներով համակարգից ստացված տարբեր դիտարկումների և փաստերի ստուգում, եզրակացություններ/ընդհանրացումներ և վարկածի ճշմարտացիության հետագա գնահատում:
Հնարավորություն արագ և էժան վարկածների փորձարկում և համապատասխանաբար մտավոր մոդելի բարելավում է անկյունաքար վրիպազերծում Վրիպազերծման ցանկացած գործիք պետք է լինի ինտերակտիվ և նեղացնել որոնման տարածքը կամ, կեղծ կապարի դեպքում, թույլ տալ օգտվողին վերադառնալ և կենտրոնանալ համակարգի այլ տարածքի վրա: Կատարյալ գործիքը դա կանի ակտիվորեն, անմիջապես օգտվողի ուշադրությունը հրավիրելով պոտենցիալ խնդրահարույց տարածքների վրա:
Ավաղ, traceview չի կարելի անվանել ինտերակտիվ ինտերֆեյս ունեցող գործիք: Լավագույնը, որին կարող եք հուսալ այն օգտագործելիս՝ գտնելն է ավելացած հետաձգման աղբյուր և դիտեք դրա հետ կապված բոլոր հնարավոր պիտակները և տեղեկամատյանները: Սա չի օգնում ինժեներին նույնականացնել նախշեր երթևեկության մեջ, օրինակ՝ հետաձգման բաշխման առանձնահատկությունները, կամ հայտնաբերել տարբեր չափումների միջև փոխկապակցվածություն: կարող է օգնել շրջանցել այս խնդիրներից մի քանիսը: Իսկապես, հաջող վերլուծություն՝ օգտագործելով մեքենայական ուսուցում՝ անոմալ տարածությունները հայտնաբերելու և պիտակների ենթաբազմություն հայտնաբերելու համար, որոնք կարող են կապված լինել անոմալ վարքի հետ: Այնուամենայնիվ, ես դեռ չեմ տեսել մեքենայական ուսուցման կամ տվյալների արդյունահանման արդյունքների ազդեցիկ վիզուալիզացիաներ, որոնք կիրառվել են տարածությունների վրա, որոնք էականորեն տարբերվում են հետագծումից կամ DAG-ից (ուղղված ացիկլիկ գրաֆիկից):
Ընդարձակությունները չափազանց ցածր մակարդակ են
Traceview-ի հիմնարար խնդիրն այն է ընդարձակվում է չափազանց ցածր մակարդակի պրիմիտիվներ են ինչպես հետաձգման, այնպես էլ արմատական պատճառների վերլուծության համար: Դա նման է անհատական պրոցեսորի հրամանների վերլուծությանը` փորձելով լուծել բացառությունը, իմանալով, որ կան շատ ավելի բարձր մակարդակի գործիքներ, ինչպիսին է backtrace-ը, որոնց հետ աշխատելը շատ ավելի հարմար է:
Ավելին, ես ազատություն կվերցնեմ պնդելու հետևյալը. իդեալականը մեզ պետք չէ ամբողջական պատկերը տեղի է ունեցել հարցման կյանքի ցիկլի ընթացքում, որը ներկայացված է հետագծման ժամանակակից գործիքներով: Փոխարենը, պահանջվում է ավելի բարձր մակարդակի վերացականության ինչ-որ ձև, որը պարունակում է տեղեկատվություն ինչի մասին սխալ գնաց (նման է հետագծին), ինչ-որ համատեքստի հետ միասին: Ամբողջ հետքը դիտելու փոխարեն ես նախընտրում եմ տեսնել այն часть, որտեղ ինչ-որ հետաքրքիր կամ անսովոր բան է տեղի ունենում։ Ներկայումս որոնումն իրականացվում է ձեռքով. ինժեները ստանում է հետքը և ինքնուրույն վերլուծում է անցքերը՝ ինչ-որ հետաքրքիր բան փնտրելու համար: Մարդկանց մոտեցումը, ովքեր նայում են առանձին հետքերով ընդարձակություններին, կասկածելի գործողություններ հայտնաբերելու հույսով, բացարձակապես մասշտաբային չէ (հատկապես երբ նրանք պետք է իմաստավորեն տարբեր միջակայքերում կոդավորված բոլոր մետատվյալները, ինչպիսիք են span ID-ն, RPC մեթոդի անվանումը, միջակայքի տևողությունը: «a, տեղեկամատյաններ, պիտակներ և այլն):
Traceview-ի այլընտրանքներ
Հետագծման արդյունքներն առավել օգտակար են, երբ դրանք կարող են պատկերացվել այնպես, որ ապահովվի ոչ աննշան պատկերացում, թե ինչ է կատարվում համակարգի փոխկապակցված մասերում: Քանի դեռ դա տեղի չի ունեցել, վրիպազերծման գործընթացը հիմնականում մնում է իներտ և կախված է օգտագործողի՝ ճիշտ փոխկապակցվածությունը նկատելու, համակարգի ճիշտ մասերը ստուգելու կամ գլուխկոտրուկի մասերը միասին դնելու կարողությունից՝ ի տարբերություն գործիք, օգնելով օգտվողին ձեւակերպել այս վարկածները:
Ես վիզուալ դիզայներ կամ UX մասնագետ չեմ, բայց հաջորդ բաժնում ես ուզում եմ կիսվել մի քանի գաղափարներով, թե ինչպիսին կարող են լինել այս վիզուալիզացիաները:
Կենտրոնացեք կոնկրետ ծառայությունների վրա
Այն ժամանակ, երբ արդյունաբերությունը համախմբվում է գաղափարների շուրջ , խելամիտ է թվում, որ առանձին թիմերը պետք է առաջնահերթություն տան, որպեսզի իրենց ծառայությունները համապատասխանեն այս նպատակներին: Դրանից բխում է, որ սպասարկման կողմնորոշված վիզուալիզացիան լավագույնս հարմար է նման թիմերի համար:
Հետքերը, հատկապես առանց նմուշառման, բաշխված համակարգի յուրաքանչյուր բաղադրիչի վերաբերյալ տեղեկատվության գանձարան են: Այս տեղեկատվությունը կարող է փոխանցվել խորամանկ պրոցեսորին, որը կմատակարարի օգտվողներին սպասարկման կողմնորոշված բացահայտումներ: Դրանք կարող են նախապես նույնականացվել, նույնիսկ նախքան օգտագործողը նայելու հետքերը.
- Հապաղման բաշխման դիագրամներ միայն բարձր ակնառու հարցումների համար (օտար հարցումներ);
- Հետաձգման բաշխման դիագրամներ այն դեպքերի համար, երբ ծառայության SLO-ի նպատակները չեն իրականացվել.
- Ամենահաճախակի հարցումներում առավել «սովորական», «հետաքրքիր» և «տարօրինակ» պիտակները կրկնվում են;
- Լատենտների բաժանում այն դեպքերի համար, երբ կախվածությունը ծառայությունները չեն հասնում իրենց SLO նպատակներին.
- Տարբեր հոսանքային ծառայությունների ուշացման բաշխում:
Այս հարցերից մի քանիսին պարզապես չեն պատասխանում ներկառուցված չափումները՝ ստիպելով օգտատերերին մանրակրկիտ ուսումնասիրել միջակայքերը: Արդյունքում՝ մենք ունենք չափազանց թշնամական մեխանիզմ՝ օգտագործողի նկատմամբ։
Սա հարց է առաջացնում. ի՞նչ կասեք տարբեր թիմերի կողմից վերահսկվող տարբեր ծառայությունների միջև բարդ փոխազդեցությունների մասին: չէ՞ traceview չի՞ համարվում նման իրավիճակն ընդգծելու ամենահարմար գործիքը։
Բջջային ծրագրավորողները, քաղաքացիություն չունեցող ծառայությունների սեփականատերերը, կառավարվող պետական ծառայությունների սեփականատերերը (օրինակ՝ տվյալների բազաները) և հարթակի սեփականատերերը կարող են հետաքրքրված լինել այլ բանով ներկայացում բաշխված համակարգ; traceview չափազանց ընդհանուր լուծում է այս սկզբունքորեն տարբեր կարիքների համար: Նույնիսկ շատ բարդ միկրոսերվիսային ճարտարապետության դեպքում ծառայության սեփականատերերը կարիք չունեն ավելի քան երկու կամ երեք հոսանքով և ներքևում գտնվող ծառայությունների խորը գիտելիքների: Ըստ էության, սցենարների մեծ մասում օգտվողները պետք է պատասխանեն միայն հարցերին ծառայությունների սահմանափակ փաթեթ.
Դա նման է ծառայությունների փոքր ենթախմբին նայելու խոշորացույցի միջոցով՝ այն մանրակրկիտ ուսումնասիրելու համար: Սա թույլ կտա օգտվողին ավելի հրատապ հարցեր տալ այս ծառայությունների և դրանց անմիջական կախվածությունների միջև բարդ փոխազդեցությունների վերաբերյալ: Սա նման է հետագծին ծառայությունների աշխարհում, որտեղ ինժեները գիտի որ սխալ է, և նաև որոշակի պատկերացում ունի այն մասին, թե ինչ է կատարվում շրջակա ծառայությունների մեջ ինչու.
Մոտեցումը, որը ես խթանում եմ, ճիշտ հակառակն է վերևից ներքև, հետագծման վրա հիմնված մոտեցմանը, որտեղ վերլուծությունը սկսվում է ամբողջ հետքից և այնուհետև աստիճանաբար հասնում է առանձին ընդմիջումների: Ի հակադրություն, ներքևից վեր մոտեցումը սկսվում է՝ վերլուծելով մի փոքր տարածք, որը մոտ է միջադեպի հնարավոր պատճառին, և այնուհետև անհրաժեշտության դեպքում ընդլայնում է որոնման տարածքը (այլ թիմեր ներգրավելու հնարավորությամբ՝ վերլուծելու ծառայությունների ավելի լայն շրջանակ): Երկրորդ մոտեցումն ավելի հարմար է նախնական վարկածների արագ փորձարկման համար: Կոնկրետ արդյունքներ ձեռք բերելուց հետո հնարավոր կլինի անցնել ավելի նպատակային և մանրամասն վերլուծության։
Տոպոլոգիայի կառուցում
Ծառայության հատուկ դիտումները կարող են աներևակայելի օգտակար լինել, եթե օգտատերը գիտի ինչ ծառայությունը կամ ծառայությունների խումբը պատասխանատու է հետաձգման ավելացման կամ սխալներ առաջացնելու համար: Այնուամենայնիվ, բարդ համակարգում վիրավորող ծառայության նույնականացումը կարող է լինել ոչ աննշան խնդիր ձախողման ժամանակ, հատկապես, եթե ծառայություններից սխալի հաղորդագրություններ չեն հաղորդվել:
Ծառայությունների տոպոլոգիայի կառուցումը կարող է մեծ օգնություն ցույց տալ՝ պարզելու համար, թե որ ծառայությունն է նկատում սխալների արագության աճ կամ հետաձգման աճ, ինչը հանգեցնում է ծառայության նկատելի դեգրադացման: Երբ ես խոսում եմ տոպոլոգիա կառուցելու մասին, ես նկատի չունեմ ծառայությունների քարտեզ, ցուցադրելով համակարգում հասանելի և իր համար հայտնի յուրաքանչյուր ծառայություն . Այս տեսակետը ավելի լավ չէ, քան հետագծային դիտումը, որը հիմնված է ուղղորդված ացիկլիկ գրաֆիկի վրա: Փոխարենը ես կցանկանայի տեսնել դինամիկ ձևավորված ծառայության տոպոլոգիա, հիմնված որոշակի հատկանիշների վրա, ինչպիսիք են սխալի արագությունը, արձագանքման ժամանակը կամ օգտագործողի կողմից սահմանված ցանկացած պարամետր, որն օգնում է հստակեցնել իրավիճակը կոնկրետ կասկածելի ծառայությունների հետ:
Օրինակ բերենք. Պատկերացնենք հիպոթետիկ լրատվական կայք։ Գլխավոր էջի ծառայություն (առաջին էջ) տվյալների փոխանակում է Redis-ի, առաջարկությունների ծառայության, գովազդային ծառայության և վիդեո ծառայության հետ: Տեսածառայությունը տեսանյութեր է վերցնում S3-ից և մետատվյալներ DynamoDB-ից: Առաջարկությունների ծառայությունը ստանում է մետատվյալներ DynamoDB-ից, բեռնում է տվյալներ Redis-ից և MySQL-ից և հաղորդագրություններ գրում Kafka-ին: Գովազդային ծառայությունը տվյալներ է ստանում MySQL-ից և հաղորդագրություններ գրում Կաֆկային։
Ստորև ներկայացված է այս տոպոլոգիայի սխեմատիկ ներկայացումը (շատ առևտրային երթուղային ծրագրեր կառուցում են տոպոլոգիան): Այն կարող է օգտակար լինել, եթե դուք պետք է հասկանաք ծառայությունների կախվածությունը: Այնուամենայնիվ, ընթացքում վրիպազերծում, երբ որոշակի ծառայություն (ասենք, վիդեո ծառայություն) ցուցադրում է արձագանքման ժամանակի ավելացում, նման տոպոլոգիան այնքան էլ օգտակար չէ։
Հիպոթետիկ լրատվական կայքի սպասարկման դիագրամ
Ստորև բերված դիագրամը ավելի հարմար կլինի: Ծառայության հետ կապված խնդիր կա (տեսանյութ) պատկերված է հենց կենտրոնում։ Օգտագործողը դա անմիջապես նկատում է։ Այս վիզուալիզացիայից պարզ է դառնում, որ վիդեո ծառայությունը աննորմալ է աշխատում S3 արձագանքման ժամանակի ավելացման պատճառով, որն ազդում է հիմնական էջի մի մասի բեռնման արագության վրա։
Դինամիկ տոպոլոգիա, որը ցուցադրում է միայն «հետաքրքիր» ծառայություններ
Դինամիկ ձևավորված տոպոլոգիաները կարող են ավելի արդյունավետ լինել, քան ստատիկ սպասարկման քարտեզները, հատկապես առաձգական, ավտոմատ մասշտաբային ենթակառուցվածքներում: Ծառայությունների տոպոլոգիաները համեմատելու և հակադրելու ունակությունը թույլ է տալիս օգտվողին տալ ավելի համապատասխան հարցեր: Համակարգի վերաբերյալ ավելի ճշգրիտ հարցերն ավելի հավանական է, որ ավելի լավ ըմբռնեն, թե ինչպես է աշխատում համակարգը:
Համեմատական ցուցադրում
Մեկ այլ օգտակար պատկերացում կլինի համեմատական ցուցադրումը: Ներկայումս հետքերը այնքան էլ հարմար չեն կողք կողքի համեմատությունների համար, ուստի համեմատությունները սովորաբար լինում են ընդարձակվում է. Եվ այս հոդվածի հիմնական գաղափարը հենց այն է, որ տարածությունները չափազանց ցածր մակարդակի են՝ հետքի արդյունքներից ամենաարժեքավոր տեղեկատվությունը հանելու համար:
Երկու հետքերի համեմատությունը սկզբունքորեն նոր պատկերացումներ չի պահանջում: Իրականում, հիստոգրամայի նման մի բան, որը ներկայացնում է նույն տեղեկատվությունը, ինչ հետագծային դիտումը, բավարար է: Զարմանալիորեն, նույնիսկ այս պարզ մեթոդը կարող է շատ ավելի պտուղ բերել, քան պարզապես երկու հետք առանձին ուսումնասիրելը: Նույնիսկ ավելի հզոր կլիներ հնարավորությունը պատկերացնել հետքերի համեմատություն Ընդհանուր առմամբ. Չափազանց օգտակար կլիներ տեսնել, թե ինչպես է վերջերս տեղաբաշխված տվյալների բազայի կազմաձևման փոփոխությունը՝ GC-ն (աղբի հավաքումը) միացնելու համար, մի քանի ժամվա մասշտաբով ազդում ներքևում գտնվող ծառայության արձագանքման ժամանակի վրա: Եթե այն, ինչ ես նկարագրում եմ այստեղ, հնչում է որպես ենթակառուցվածքների փոփոխությունների ազդեցության A/B վերլուծություն բազմաթիվ ծառայություններում օգտագործելով հետքի արդյունքները, ապա դուք այնքան էլ հեռու չեք ճշմարտությունից:
Ամփոփում
Ես կասկածի տակ չեմ դնում բուն հետագծման օգտակարությունը: Ես անկեղծորեն հավատում եմ, որ չկա տվյալների հավաքման այլ մեթոդ այնքան հարուստ, պատճառահետևանքային և համատեքստային, որքան հետքի մեջ պարունակվողը: Այնուամենայնիվ, ես նաև կարծում եմ, որ հետագծման բոլոր լուծումներն օգտագործում են այս տվյալները չափազանց անարդյունավետ: Քանի դեռ հետագծման գործիքները մնում են խրված հետագծման ցուցադրման վրա, դրանք սահմանափակ կլինեն արժեքավոր տեղեկատվությունից առավելագույնս օգտագործելու իրենց կարողությամբ, որը կարելի է քաղել հետքերում պարունակվող տվյալներից: Բացի այդ, կա միանգամայն անբարյացակամ և ոչ ինտուիտիվ վիզուալ ինտերֆեյսի հետագա զարգացման ռիսկ, որը լրջորեն կսահմանափակի հավելվածի սխալները շտկելու օգտատիրոջ հնարավորությունները:
Բարդ համակարգերի վրիպազերծումը, նույնիսկ վերջին գործիքներով, աներևակայելի դժվար է: Գործիքները պետք է օգնեն մշակողին ձևակերպել և փորձարկել վարկածը, ակտիվորեն տրամադրելով համապատասխան տեղեկատվություն, բացահայտում է արտանետումները և նշում ուշացումների բաշխման առանձնահատկությունները: Որպեսզի հետագծումը դառնա ծրագրավորողների ընտրության գործիքը, երբ վերացնում են արտադրության խափանումները կամ լուծում են բազմաթիվ ծառայություններ, որոնք ընդգրկում են բազմաթիվ ծառայություններ, անհրաժեշտ են օգտատիրոջ բնօրինակ միջերեսներ և վիզուալիզացիաներ, որոնք ավելի համահունչ են այդ ծառայությունները ստեղծող և գործարկող մշակողների մտավոր մոդելին:
Զգալի մտավոր ջանքեր կպահանջվեն համակարգ նախագծելու համար, որը կներկայացնի հետագծային արդյունքներում առկա տարբեր ազդանշաններն այնպես, որ օպտիմիզացված լինի վերլուծության և եզրակացության հեշտության համար: Դուք պետք է մտածեք այն մասին, թե ինչպես կարելի է վերացականացնել համակարգի տոպոլոգիան վրիպազերծման ժամանակ այնպես, որ օգտագործողին օգնի հաղթահարել կույր կետերը՝ առանց առանձին հետքերի կամ բացվածքների նայելու:
Մեզ պետք են լավ աբստրակցիայի և շերտավորման հնարավորություններ (հատկապես UI-ում): Նրանք, որոնք լավ տեղավորվում են հիպոթեզի վրա հիմնված վրիպազերծման գործընթացում, որտեղ դուք կարող եք կրկնվող հարցեր տալ և ստուգել վարկածները: Նրանք ինքնաբերաբար չեն լուծի դիտարկելիության բոլոր խնդիրները, բայց կօգնեն օգտատերերին ավելի խորացնել իրենց ինտուիցիան և ձևակերպել ավելի խելացի հարցեր: Ես կոչ եմ անում ավելի մտածված և նորարարական մոտեցում ցուցաբերել վիզուալիզացիայի նկատմամբ: Այստեղ հորիզոններն ընդլայնելու իրական հեռանկար կա։
PS թարգմանչից
Կարդացեք նաև մեր բլոգում.
- «";
- «";
- «.
Source: www.habr.com