SRE (Site Reliability Engineering) վեբ նախագծերի հասանելիությունն ապահովելու մոտեցում է: Այն համարվում է DevOps-ի շրջանակ և խոսում է այն մասին, թե ինչպես հաջողության հասնել DevOps-ի պրակտիկաների կիրառման գործում: Թարգմանությունը այս հոդվածում Գլուխ 6 Բաշխված համակարգերի մոնիտորինգ գրքեր Կայքի հուսալիության ճարտարագիտություն Google-ից: Ես ինքս պատրաստեցի այս թարգմանությունը և ապավինեցի մոնիտորինգի գործընթացները հասկանալու իմ սեփական փորձին: Հեռագրային ալիքում @monitorim_it и բլոգը Medium-ում Ես նաև հրապարակել եմ նույն գրքի 4-րդ գլխի թարգմանության հղումը ծառայության մակարդակի նպատակների մասին:

Թարգմանություն՝ կատու. Վայելե՛ք կարդալը:

Google-ի SRE թիմերն ունեն մոնիտորինգի և ծանուցման հաջող համակարգեր ստեղծելու հիմնական սկզբունքներն ու լավագույն փորձը: Այս գլուխը ցույց է տալիս, թե ինչ խնդիրների կարող է հանդիպել վեբ էջի այցելուը և ինչպես լուծել այն խնդիրները, որոնք դժվարացնում են վեբ էջերի ցուցադրումը:

Սահմանումներ

Մոնիտորինգի հետ կապված թեմաներ քննարկելու համար օգտագործվող բառապաշար չկա: Նույնիսկ Google-ում ստորև նշված տերմինները սովորաբար չեն օգտագործվում, բայց մենք կթվարկենք ամենատարածված մեկնաբանությունները:

Մոնիտորինգ

Համակարգի վերաբերյալ քանակական տվյալների հավաքագրում, մշակում, հավաքում և ցուցադրում իրական ժամանակում՝ հարցումների և հարցումների տեսակների, սխալների քանակի և սխալների տեսակների, հարցումների մշակման ժամանակի և սերվերի շահագործման ժամանակի:

Սպիտակ տուփի մոնիտորինգ

Մոնիտորինգ՝ հիմնված ներքին համակարգի բաղադրիչների կողմից ցուցադրվող չափումների վրա, ներառյալ տեղեկամատյանները, Java վիրտուալ մեքենայի պրոֆիլավորման չափումները կամ HTTP մշակման չափումները, որոնք ստեղծում են ներքին վիճակագրություն:

Սև տուփի մոնիտորինգ

Օգտագործողի տեսանկյունից հավելվածի վարքագծի փորձարկում:

Վահանակ

Ինտերֆեյս (սովորաբար վեբ), որն ապահովում է ծառայությունների հիմնական առողջապահական ցուցանիշների ակնարկ: Վահանակի վահանակը կարող է ունենալ զտիչներ, ցուցադրված ցուցիչները ընտրելու հնարավորություն և այլն: Ինտերֆեյսը նախատեսված է օգտատերերի համար ամենակարևոր ցուցանիշները բացահայտելու համար: Վահանակի վահանակը կարող է նաև տեղեկատվություն ցուցադրել տեխնիկական աջակցության անձնակազմի համար՝ հարցումների հերթ, առաջնահերթ սխալների ցուցակ և պատասխանատվության տվյալ ոլորտի համար նշանակված ինժեներ:

Զգուշացում (ծանուցում)

Ծանուցումներ, որոնք նախատեսված են անձի կողմից էլեկտրոնային փոստով կամ այլ միջոցներով ստանալու համար, որոնք կարող են առաջանալ սխալների կամ հարցումների հերթի ավելացման հետևանքով: Ծանուցումները դասակարգվում են հետևյալ կերպ՝ տոմսեր, էլ. ծանուցումներ և ակնթարթային հաղորդագրություններ:

Սկզբնական պատճառ

Ծրագրային ապահովման թերություն կամ մարդկային սխալ, որը շտկվելուց հետո չպետք է կրկնվի: Խնդիրը կարող է ունենալ մի քանի հիմնական պատճառ՝ գործընթացի անբավարար ավտոմատացում, ծրագրային թերություն, կիրառական տրամաբանության անբավարար մշակում։ Այս գործոններից յուրաքանչյուրը կարող է լինել հիմնական պատճառը, և դրանցից յուրաքանչյուրը պետք է վերացվի:

Հանգույց և մեքենա (հանգույց և մեքենա)

Փոխարինելի տերմիններ, որոնք վերաբերում են ֆիզիկական սերվերի, վիրտուալ մեքենայի կամ կոնտեյների վրա գործող հավելվածի մեկ օրինակին: Մեկ մեքենան կարող է հյուրընկալել մի քանի ծառայություններ: Ծառայությունները կարող են լինել.

• միացված են միմյանց. օրինակ՝ քեշավորման սերվեր և վեբ սերվեր;
• չկապված ծառայություններ մեկ սարքաշարի վրա. օրինակ՝ կոդերի պահոց և կոնֆիգուրացիայի համակարգի մոգ, ինչպես օրինակ. Տիկնիկ կամ Chef.

Հրեք

Ծրագրային կազմաձևման ցանկացած փոփոխություն:

Ինչու՞ է անհրաժեշտ մոնիտորինգը:

Կան մի քանի պատճառ, թե ինչու են դիմումները պետք է վերահսկվեն.

Երկարաժամկետ միտումների վերլուծություն

Որքա՞ն է տվյալների բազան և որքան արագ է այն աճում: Ինչպե՞ս է փոխվում օգտատերերի օրական թիվը:

Կատարողականի համեմատություն

Արդյո՞ք հարցումներն ավելի արագ են Acme Bucket of Bytes 2.72-ի վրա՝ համեմատած Ajax DB 3.14-ի հետ: Որքանո՞վ են ավելի լավ խնդրանքները պահվում լրացուցիչ հանգույցի հայտնվելուց հետո: Կայքն ավելի դանդաղ է աշխատում նախորդ շաբաթվա համեմատ:

Զգուշացում (ծանուցումներ)

Ինչ-որ բան կոտրված է, և ինչ-որ մեկը պետք է շտկի այն: Կամ ինչ-որ բան շուտով կփչանա, և ինչ-որ մեկը պետք է շուտով ստուգի դա:

Վահանակների ստեղծում

Վահանակները պետք է պատասխանեն հիմնական հարցերին և ներառեն ինչ-որ բան «4 ոսկե ազդանշան» — ուշացումներ (ուշացում), երթևեկություն (երթևեկություն), սխալներ (սխալներ) և բեռի չափ (հագեցվածություն):

Հետադարձ վերլուծության անցկացում (վրիպազերծում)

Հարցումների մշակման ուշացումն աճել է, բայց էլ ի՞նչ է տեղի ունեցել նույն ժամանակ:
Մոնիտորինգի համակարգերը օգտակար են որպես բիզնես հետախուզական համակարգերի տվյալների աղբյուր և հեշտացնելու անվտանգության միջադեպերի վերլուծությունը: Քանի որ այս գիրքը կենտրոնանում է ինժեներական ոլորտների վրա, որտեղ SRE-ները ունեն փորձաքննություն, մենք այստեղ չենք քննարկի մոնիտորինգի տեխնիկան:

Մոնիտորինգը և ահազանգերը թույլ են տալիս համակարգին հայտնել ձեզ, երբ այն խափանվել է կամ պատրաստվում է փչանալ: Երբ համակարգը չի կարող ինքնաբերաբար վերանորոգվել, մենք ցանկանում ենք, որ մարդը վերլուծի ահազանգը, որոշի, թե արդյոք խնդիրը դեռ ակտիվ է, լուծի այն և որոշի հիմնական պատճառը: Եթե ​​դուք չեք ստուգում համակարգի բաղադրիչները, դուք երբեք ահազանգ չեք ստանա պարզապես այն պատճառով, որ «ինչ-որ բան մի փոքր տարօրինակ է թվում»:

Ծանուցումներով մարդուն ծանրաբեռնելը աշխատողի ժամանակի բավականին թանկ օգտագործում է: Եթե ​​աշխատողն աշխատում է, ահազանգը ընդհատում է աշխատանքային գործընթացը: Եթե ​​աշխատողը տանը է, ահազանգը ընդհատում է անձնական ժամանակը և, հնարավոր է, քունը: Երբ ահազանգերը չափազանց հաճախ են լինում, աշխատակիցները սայթաքում են դրանք, հետաձգում կամ անտեսում մուտքային ահազանգերը: Ժամանակ առ ժամանակ նրանք անտեսում են իրական զգոնությունը, որը քողարկված է աղմուկի իրադարձություններով։ Ծառայության ընդհատումները կարող են տևել երկար ժամանակ, քանի որ աղմուկի իրադարձությունները թույլ չեն տալիս խնդրի արագ ախտորոշումը և շտկումը: Արդյունավետ նախազգուշացման համակարգերն ունեն ազդանշան-աղմուկ լավ հարաբերակցություն:

Մոնիտորինգի համակարգի համար ողջամիտ ակնկալիքներ սահմանելը

Բարդ հավելվածի համար մոնիտորինգի կարգավորումն ինքնին բարդ ինժեներական խնդիր է: Նույնիսկ հավաքագրման, ցուցադրման և ազդանշանային գործիքների զգալի ենթակառուցվածքի առկայության դեպքում, Google SRE-ի 10-12 անդամներից բաղկացած թիմը սովորաբար ներառում է մեկ կամ երկու հոգի, որոնց հիմնական նպատակը մոնիտորինգի համակարգերի կառուցումն ու պահպանումն է: Այս թիվը ժամանակի ընթացքում նվազել է, քանի որ մենք համախմբում և կենտրոնացնում ենք մոնիտորինգի ենթակառուցվածքը, սակայն յուրաքանչյուր SRE թիմ սովորաբար ունենում է առնվազն մեկ մարդ, որը նվիրված է բացառապես մոնիտորինգին: Մենք պետք է ասենք, որ թեև մոնիտորինգի համակարգի վահանակները բավականին հետաքրքիր են դիտելը, SRE թիմերը զգուշորեն խուսափում են իրավիճակներից, որոնք պահանջում են, որ ինչ-որ մեկը նայի էկրանին՝ խնդիրները վերահսկելու համար:

Ընդհանուր առմամբ, Google-ը անցել է պարզ և արագ մոնիտորինգի համակարգերի, որոնք օժտված են փաստերի վերլուծության օպտիմալ գործիքներով: Մենք խուսափում ենք «կախարդական» համակարգերից, որոնք փորձում են կանխատեսել շեմերը կամ ինքնաբերաբար հայտնաբերել հիմնական պատճառը: Սենսորները, որոնք հայտնաբերում են չնախատեսված բովանդակություն վերջնական օգտագործողի հարցումներում, միակ հակաօրինակն են. Քանի դեռ այս սենսորները մնում են պարզ, նրանք կարող են արագ հայտնաբերել լուրջ անոմալիաների պատճառները: Մոնիտորինգի տվյալների օգտագործման այլ ձևաչափեր, ինչպիսիք են կարողությունների պլանավորումը կամ երթևեկության կանխատեսումը, ավելի բարդ են: Շատ երկար ժամանակահատվածում (ամիսներ կամ տարիներ) դիտումը ցածր նմուշառման արագությամբ (ժամեր կամ օրեր) կբացահայտի երկարաժամկետ միտում:

Google SRE թիմը տարբեր հաջողություններ է ունեցել կախվածության բարդ հիերարխիայի հետ: Մենք հազվադեպ ենք օգտագործում այնպիսի կանոններ, ինչպիսիք են «եթե ես հայտնաբերում եմ, որ տվյալների բազան դանդաղ է, ես ահազանգ եմ ստանում, որ տվյալների բազան դանդաղ է, հակառակ դեպքում ես ահազանգ եմ ստանում, որ կայքը դանդաղ է»: Կախվածության վրա հիմնված կանոնները սովորաբար վերաբերում են մեր համակարգի անփոփոխ մասերին, օրինակ՝ դեպի տվյալների կենտրոն օգտատերերի տրաֆիկի զտման համակարգը: Օրինակ, «եթե տվյալների կենտրոնի երթևեկության զտումը կազմաձևված է, ինձ մի զգուշացրեք օգտատերերի հարցումների մշակման հետաձգումների մասին» տվյալների կենտրոնից ծանուցումների ընդհանուր կանոններից մեկն է: Google-ի մի քանի թիմեր աջակցում են կախվածության բարդ հիերարխիաներին, քանի որ մեր ենթակառուցվածքն ունի շարունակական վերամշակման մշտական ​​տեմպեր:

Այս գլխում նկարագրված որոշ գաղափարներ դեռևս արդիական են. միշտ կա հնարավորություն ավելի արագ անցնել ախտանիշից մինչև արմատական ​​պատճառ, հատկապես անընդհատ փոփոխվող համակարգերում: Հետևաբար, թեև այս գլուխը նախանշում է մոնիտորինգի համակարգերի որոշ նպատակներ և ինչպես հասնել այդ նպատակներին, կարևոր է, որ մոնիտորինգի համակարգերը պարզ և հասկանալի լինեն թիմի բոլոր անդամների համար:

Նմանապես, աղմուկի մակարդակը ցածր և ազդանշանի մակարդակը բարձր պահելու համար զգուշացված ակտիվների մոնիտորինգի մոտեցումները պետք է լինեն շատ պարզ և հուսալի: Մարդկանց համար նախազգուշացումներ առաջացնող կանոնները պետք է հեշտ ընկալելի լինեն և հստակ խնդիր ներկայացնեն:

Ախտանիշներն ընդդեմ պատճառների

Ձեր մոնիտորինգի համակարգը պետք է պատասխանի երկու հարցի՝ «ինչը կոտրվեց» և «ինչու այն կոտրվեց»:
«Ինչը կոտրվեց»-ը խոսում է ախտանիշի մասին, իսկ «ինչու կոտրվեց»-ը խոսում է պատճառի մասին: Ստորև բերված աղյուսակը ցույց է տալիս նման կապերի օրինակներ:

Ախտանիշ
Առաջացնել

Ստանալով HTTP սխալ 500 կամ 404
Տվյալների բազայի սերվերները մերժում են կապերը

Դանդաղ սերվերի պատասխանները
CPU-ի բարձր օգտագործում կամ վնասված Ethernet մալուխ

Անտարկտիդայի օգտատերերը կատուների GIF-ներ չեն ստանում
Ձեր CDN-ն ատում է գիտնականներին և կատուներին, ուստի որոշ IP հասցեներ հայտնվեցին սև ցուցակում

Անձնական բովանդակությունը հասանելի է դարձել ամենուր
Ծրագրաշարի նոր թողարկման թողարկումը ստիպեց firewall-ին մոռանալ բոլոր ACL-ները և թույլ տալ բոլորին ներս մտնել

«Ինչը» և «ինչու»-ն ամենակարևոր կառուցվածքային բլոկներից են առավելագույն ազդանշանով և նվազագույն աղմուկով լավ մոնիտորինգի համակարգ ստեղծելու համար:

Սև արկղ vs սպիտակ տուփ

Մենք համատեղում ենք White-box-ի լայնածավալ մոնիտորինգը կրիտիկական չափումների համար համեստ սև տուփի մոնիտորինգի հետ: Black-box-ը White-box-ի հետ համեմատելու ամենահեշտ ձևն այն է, որ Black-box-ը կենտրոնացած է ախտանշանների վրա և ռեակտիվ է, քան պրոակտիվ մոնիտորինգ. «համակարգն այս պահին ճիշտ չի աշխատում»: White-box-ը կախված է համակարգերի ներքին ստուգման հնարավորություններից՝ իրադարձությունների տեղեկամատյաններից կամ վեբ սերվերներից: Այսպիսով, White-box-ը թույլ է տալիս հայտնաբերել մոտալուտ խնդիրները, սխալները, որոնք թվում է, թե խնդրանքի վերահաղորդում են և այլն:

Նկատի ունեցեք, որ բազմաշերտ համակարգում ախտանիշը մեկ ինժեների պատասխանատվության ոլորտում ախտանիշ է մեկ այլ ինժեների պատասխանատվության ոլորտում: Օրինակ, տվյալների բազայի կատարողականը նվազել է: Տվյալների տվյալների դանդաղ ընթերցումը տվյալների բազայի SRE-ի ախտանիշն է, որը հայտնաբերում է դրանք: Այնուամենայնիվ, առջևի SRE-ի համար, որը դիտում է դանդաղ կայք, տվյալների բազայի նույն դանդաղ ընթերցման պատճառը դանդաղ տվյալների բազան է: Հետևաբար, սպիտակ տուփի մոնիտորինգը երբեմն կենտրոնացած է ախտանիշների վրա, իսկ երբեմն էլ՝ պատճառի վրա՝ կախված այն բանից, թե որքանով է այն:

Վրիպազերծման համար հեռաչափություն հավաքելիս անհրաժեշտ է White-box մոնիտորինգ: Եթե ​​վեբ սերվերները դանդաղ են արձագանքում տվյալների բազայի հարցումներին, դուք պետք է իմանաք, թե որքան արագ է վեբ սերվերը շփվում տվյալների բազայի հետ և որքան արագ է այն արձագանքում: Հակառակ դեպքում, դուք չեք կարողանա տարբերակել տվյալների բազայի դանդաղ սերվերը և ցանցային խնդիրը վեբ սերվերի և տվյալների բազայի միջև:

Սև արկղի մոնիտորինգն ունի հիմնական առավելությունը ահազանգեր ուղարկելիս. դուք ծանուցում եք ստանում ստացողին, երբ խնդիրն արդեն իսկ հանգեցրել է իրական ախտանիշների: Մյուս կողմից, մոնիտորինգն անօգուտ է «Սև արկղերի» խնդրի համար, որը դեռ չի առաջացել, բայց մոտալուտ է:

Չորս ոսկե ազդանշան

Մոնիտորինգի չորս ոսկե ազդանշաններն են՝ հետաձգումը, երթևեկությունը, սխալները և հագեցվածությունը: Եթե ​​դուք կարող եք չափել միայն չորս օգտվողների համակարգի չափումներ, կենտրոնացեք այդ չորսի վրա:

Հետաձգումը

Հարցումը մշակելու համար պահանջվող ժամանակը: Կարևոր է տարբերակել հաջող և անհաջող խնդրանքների ուշացումը: Օրինակ, HTTP 500 սխալը, որը առաջացել է տվյալների բազայի կամ այլ հետին պլանի հետ կապի կորստի պատճառով, կարող է շատ արագ ախտորոշվել, սակայն, HTTP 500 սխալը կարող է ցույց տալ ձախողված հարցումը: 500 սխալի ազդեցության որոշումը ընդհանուր հետաձգման վրա կարող է հանգեցնել սխալ եզրակացությունների: Մյուս կողմից, դանդաղ սխալը նույնիսկ արագ սխալ է: Հետևաբար, կարևոր է վերահսկել սխալների ուշացումը, այլ ոչ թե պարզապես զտել սխալները:

երթեւեկություն

Ձեր համակարգին ուղղված հարցումների քանակը չափվում է բարձր մակարդակի համակարգի չափորոշիչներով: Վեբ ծառայության համար այս չափումը սովորաբար ներկայացնում է HTTP հարցումների քանակը վայրկյանում, բաժանված հարցումների բնույթով (օրինակ՝ ստատիկ կամ դինամիկ բովանդակություն): Աուդիո հոսքային համակարգի համար այս չափումը կարող է կենտրոնանալ ցանցի մուտքի/ելքի արագության կամ միաժամանակյա նիստերի քանակի վրա: Բանալին արժեքների պահպանման համակարգի համար այս չափումը կարող է լինել գործարքներ կամ որոնման արդյունքներ վայրկյանում:

Errors

Սա բացահայտ (օրինակ՝ HTTP 500), անուղղակի (օրինակ՝ HTTP 200, բայց զուգորդված անվավեր բովանդակության հետ) կամ քաղաքականություն (օրինակ՝ «Եթե պատասխան եք ստացել մեկ վայրկյանում, ցանկացած վայրկյան սխալ է») անհաջող հարցումների ցուցանիշն է։ Եթե ​​HTTP պատասխանի կոդերը բավարար չեն ձախողման բոլոր պայմաններն արտահայտելու համար, ապա կարող են պահանջվել երկրորդական (ներքին) արձանագրություններ՝ մասնակի ձախողումը հայտնաբերելու համար: Բոլոր նման ձախողված հարցումների մոնիտորինգը կարող է տեղեկատվական չլինել, մինչդեռ համակարգի վերջնական թեստերը կօգնեն բացահայտել, որ դուք սխալ բովանդակություն եք մշակում:

Հագեցվածություն

Չափանիշը ցույց է տալիս, թե որքան ինտենսիվ է օգտագործվում ձեր ծառայությունը: Սա համակարգի մոնիտորինգի միջոց է, որը բացահայտում է ռեսուրսները, որոնք առավել սահմանափակված են (օրինակ, հիշողության սահմանափակված համակարգում, ցույց է տալիս հիշողությունը, I/O-ով սահմանափակված համակարգում, ցույց է տալիս I/O-ների քանակը): Նկատի ունեցեք, որ շատ համակարգեր վատթարացնում են արդյունավետությունը մինչև 100% օգտագործման հասնելը, ուստի օգտագործման նպատակ ունենալը կարևոր է:

Բարդ համակարգերում հագեցվածությունը կարող է լրացվել ավելի բարձր մակարդակի բեռի չափումներով. կարո՞ղ է արդյոք ձեր ծառայությունը պատշաճ կերպով կառավարել կրկնակի երթևեկությունը, միայն 10%-ով ավելի շատ երթևեկել կամ նույնիսկ ավելի քիչ երթևեկել, քան ներկայումս: Պարզ ծառայությունների համար, որոնք չունեն հարցումի բարդությունը փոխող պարամետրեր (օրինակ՝ «Ինձ ոչինչ չտաս» կամ «Ինձ պետք է եզակի մեկ միապաղաղ ամբողջ թիվ»), որոնք հազվադեպ են փոխում կոնֆիգուրացիան, ստատիկ բեռի փորձարկման արժեքը կարող է համարժեք լինել: Այնուամենայնիվ, ինչպես քննարկվեց նախորդ պարբերությունում, ծառայությունների մեծ մասը պետք է օգտագործի անուղղակի ազդանշաններ, ինչպիսիք են պրոցեսորի օգտագործումը կամ ցանցի թողունակությունը, որոնք ունեն հայտնի վերին սահման: Լատենտության աճը հաճախ հագեցվածության առաջատար ցուցանիշ է: 99-րդ տոկոսային արձագանքման ժամանակը փոքր պատուհանում (օրինակ՝ մեկ րոպե) չափելը կարող է հագեցվածության շատ վաղ ազդանշան տալ:

Վերջապես, հագեցվածությունը կապված է նաև մոտալուտ հագեցվածության մասին կանխատեսումների հետ, օրինակ. «Կարծես թե ձեր տվյալների բազան 4 ժամում կլցնի ձեր կոշտ սկավառակը»:

Եթե ​​չափեք բոլոր չորս ոսկե ազդանշանները, և երբ չափիչներից որևէ մեկի հետ կապված խնդիր կա (կամ, հագեցվածության դեպքում, մոտ խնդիր), դուք զգուշացնում եք մարդուն, ձեր ծառայությունը քիչ թե շատ ծածկված կլինի մոնիտորինգով:

Անհանգստություններ «պոչի» (կամ գործիքավորման և կատարման) մասին

Մոնիտորինգի համակարգ զրոյից ստեղծելիս գայթակղություն կա զարգացնել համակարգ՝ հիմնված միջին արժեքների վրա՝ միջին ուշացում, հանգույցների միջին պրոցեսորի օգտագործում կամ տվյալների բազայի միջին լրիվություն: Վերջին երկու օրինակների վտանգն ակնհայտ է. պրոցեսորներն ու տվյալների բազաները ոչնչացվում են շատ անկանխատեսելի կերպով։ Նույնը վերաբերում է ուշացմանը։ Եթե ​​դուք գործարկում եք վեբ ծառայություն 100ms միջին ուշացումով՝ վայրկյանում 1000 հարցումով, հարցումների 1%-ը կարող է տևել 5 վայրկյան: Եթե ​​օգտատերերը կախված են բազմաթիվ նման վեբ ծառայություններից, ապա մեկ հետնամասի 99-րդ տոկոսը կարող է հեշտությամբ դառնալ ճակատային մասի արձագանքման միջին ժամանակը:

Հարցումների դանդաղ միջին և շատ դանդաղ պոչը տարբերելու ամենապարզ ձևը վիճակագրության մեջ արտահայտված հարցումների չափումներ հավաքելն է (ցուցադրելու լավ գործիք հիստոգրամներն են), այլ ոչ թե իրական ուշացումները. քանի՞ հարցում է սպասարկվել ծառայությունը, որը տևել է 0 մվ: և 10 ms, 10 ms-ի և 30 ms-ի միջև, 30 ms-ի և 100 ms-ի միջև, 100 ms-ի և 300 ms-ի միջև և այլն: Հիստոգրամի սահմանների մոտավոր ընդլայնումը (մոտավոր 3 գործակցով) հաճախ բաշխումը պատկերացնելու պարզ միջոց է: խնդրանքների.

Չափումների համար մանրամասների համապատասխան մակարդակի ընտրություն

Համակարգի տարբեր տարրերը պետք է չափվեն մանրամասների տարբեր մակարդակներում: Օրինակ:

• Ժամանակի ընթացքում CPU-ի օգտագործման մոնիտորինգը չի ցույց տա երկարաժամկետ աճեր, որոնք հանգեցնում են բարձր հետաձգման:
• Մյուս կողմից, վեբ ծառայության համար, որը նպատակաուղղված է տարեկան ոչ ավելի, քան 9 ժամ անաշխատունակության (տարեկան 99,9% աշխատաժամանակ), HTTP 200 պատասխանի ստուգումը րոպեում մեկ կամ երկու անգամից ավելի, հավանաբար, անհարկի հաճախակի կլինի:
• Նմանապես, 99,9-1 րոպեն մեկ անգամից ավելի կոշտ սկավառակի տարածությունը ստուգելը 2% հասանելիության համար, հավանաբար, անհրաժեշտ չէ:

Ուշադիր եղեք, թե ինչպես եք կառուցում ձեր չափումների հատիկությունը: CPU-ի բեռնվածությունը վայրկյանում մեկ անգամ հավաքելը կարող է հետաքրքիր տվյալներ ապահովել, սակայն նման հաճախակի չափումները կարող են շատ թանկ արժենալ հավաքելը, պահելը և վերլուծելը: Եթե ​​ձեր մոնիտորինգի նպատակը պահանջում է բարձր հստակություն և չի պահանջում բարձր արձագանքում, դուք կարող եք նվազեցնել այդ ծախսերը՝ կարգավորելով չափումների հավաքածուն սերվերում, այնուհետև ստեղծելով արտաքին համակարգ՝ այդ չափումները հավաքելու և համախմբելու համար: Կարող ես:

1. Ամեն վայրկյան չափեք պրոցեսորի բեռնվածությունը:
2. Նվազեցրեք մանրամասները մինչև 5%:
3. Համախառն չափումներ ամեն րոպե:

Այս ռազմավարությունը թույլ կտա ձեզ հավաքել տվյալներ բարձր հստակությամբ՝ առանց վերլուծության և պահեստավորման բարձր ծախսերի:

Որքան հնարավոր է պարզ, բայց ոչ ավելի պարզ

Տարբեր պահանջների միմյանց վրա ծածկելը կարող է հանգեցնել մոնիտորինգի շատ բարդ համակարգի: Օրինակ, ձեր համակարգը կարող է ունենալ հետևյալ բարդ տարրերը.

• Ծանուցումներ՝ ըստ հարցումների մշակման հետաձգման տարբեր շեմերի, տարբեր տոկոսներով, բոլոր տեսակի տարբեր ցուցանիշների համար:
• Լրացուցիչ կոդ գրելը հնարավոր պատճառները հայտնաբերելու և բացահայտելու համար:
• Ստեղծեք համապատասխան վահանակներ խնդիրների հնարավոր պատճառներից յուրաքանչյուրի համար:

Հնարավոր բարդությունների աղբյուրները երբեք չեն ավարտվում: Ինչպես բոլոր ծրագրային համակարգերը, մոնիտորինգը կարող է դառնալ այնքան բարդ, որ դառնում է փխրուն և դժվար է փոխել և պահպանել:

Հետևաբար, նախագծեք ձեր մոնիտորինգի համակարգը, որպեսզի այն հնարավորինս պարզեցվի: Ընտրելով, թե ինչին հետևել, նկատի ունեցեք հետևյալը.

• Կանոնները, որոնք ամենից հաճախ բռնում են իրական միջադեպերը, պետք է լինեն հնարավորինս պարզ, կանխատեսելի և հուսալի:
• Տվյալների հավաքագրման, համախմբման և զգուշացման կոնֆիգուրացիաները, որոնք կատարվում են հազվադեպ (օրինակ՝ եռամսյակից պակաս որոշ SRE թիմերի համար) պետք է հեռացվեն:
• Չափիչները, որոնք հավաքվում են, բայց չեն ցուցադրվում որևէ նախադիտման վահանակում կամ օգտագործվում են որևէ ազդանշանի կողմից, ջնջման թեկնածու են:

Google-ում հիմնական չափումների հավաքագրումն ու համախմբումը, զուգորդված զգուշացումների և վահանակների հետ, լավ են աշխատում որպես համեմատաբար առանձին համակարգ (Google-ի մոնիտորինգի համակարգը իրականում բաժանված է մի քանի ենթահամակարգերի, բայց մարդիկ սովորաբար տեղյակ են այս ենթահամակարգերի բոլոր կողմերին): Կարող է գայթակղիչ լինել համատեղել մոնիտորինգը բարդ համակարգերի հետազոտման այլ մեթոդների հետ. մանրամասն համակարգի պրոֆիլավորում, գործընթացի վրիպազերծում, բացառությունների կամ խափանումների վերաբերյալ մանրամասների հետևում, բեռների փորձարկում, գրանցամատյանների հավաքագրում և վերլուծություն կամ երթևեկության ստուգում: Թեև այս բաներից շատերը ընդհանուր մոնիտորինգի հետ ունեն, դրանք խառնելով կհանգեցնի չափազանց շատ արդյունքների և կստեղծի բարդ և փխրուն համակարգ: Ինչպես ծրագրային ապահովման մշակման շատ այլ ասպեկտների դեպքում, տարբեր համակարգերի աջակցությունը հստակ, պարզ, թույլ զուգակցված ինտեգրման կետերով լավագույն ռազմավարությունն է (օրինակ, վեբ API-ի օգտագործումը` հավաքագրված տվյալները այնպիսի ձևաչափով ստանալու համար, որը կարող է հետևողական մնալ երկար ժամանակ: )

Սկզբունքները միասին կապելը

Այս գլխում քննարկված սկզբունքները կարող են համակցվել մոնիտորինգի և զգուշացման փիլիսոփայության մեջ, որը հաստատվում և հետևվում է Google SRE թիմերի կողմից: Մոնիտորինգի այս փիլիսոփայությանը հավատարիմ մնալը ցանկալի է, լավ մեկնարկային կետ է ձեր ահազանգման մեթոդոլոգիան ստեղծելու կամ վերանայելու համար և կարող է օգնել ձեզ ճիշտ հարցեր տալ ձեր գործառնությունների գործառույթին՝ անկախ ձեր կազմակերպության չափից կամ ծառայության կամ համակարգի բարդությունից:

Մոնիտորինգի և ահազանգման կանոններ ստեղծելիս հետևյալ հարցերը կարող են օգնել ձեզ խուսափել կեղծ պոզիտիվներից և անհարկի ահազանգերից.

• Արդյո՞ք այս կանոնը հայտնաբերում է համակարգի այլապես չբացահայտվող վիճակ, որը հրատապ է, կոչ է անում գործողության և անխուսափելիորեն ազդում է օգտագործողի վրա:
• Կարո՞ղ եմ անտեսել այս նախազգուշացումը՝ իմանալով, որ այն բարենպաստ է: Ե՞րբ և ինչու կարող եմ անտեսել այս նախազգուշացումը և ինչպես կարող եմ խուսափել այս սցենարից:
• Արդյո՞ք այս ահազանգը նշանակում է, որ օգտատերերը բացասաբար են ազդում: Կա՞ն իրավիճակներ, երբ օգտատերերը բացասաբար չեն ազդում, օրինակ՝ երթևեկության զտման միջոցով կամ թեստային համակարգեր օգտագործելիս, որոնց համար ահազանգերը պետք է զտվեն:
• Կարո՞ղ եմ քայլեր ձեռնարկել ի պատասխան այս ահազանգին: Արդյո՞ք այս միջոցառումները հրատապ են, թե՞ կարելի է սպասել մինչև առավոտ։ Կարո՞ղ է գործողությունը անվտանգ ավտոմատացված լինել: Այս գործողությունը կլինի՞ երկարաժամկետ լուծում, թե՞ կարճաժամկետ լուծում:
• Որոշ մարդիկ այս խնդրի համար ստանում են բազմաթիվ ահազանգեր, հետևաբար կա՞ արդյոք ազդանշանների քանակը նվազեցնելու միջոց:

Այս հարցերը արտացոլում են ազդանշանների և նախազգուշացման համակարգերի հիմնարար փիլիսոփայությունը.

• Ամեն անգամ, երբ ահազանգ է գալիս, ես պետք է անմիջապես արձագանքեմ: Ես կարող եմ օրական մի քանի անգամ շտապ արձագանքել՝ հոգնելուց առաջ։
• Յուրաքանչյուր ահազանգ պետք է համապատասխան լինի:
• Զգուշացման յուրաքանչյուր արձագանք պետք է պահանջի մարդու միջամտություն: Եթե ​​ծանուցումը կարող է ավտոմատ կերպով մշակվել, այն չպետք է հասնի:
• Զգուշացումները պետք է լինեն նոր խնդրի կամ իրադարձության մասին, որը նախկինում գոյություն չի ունեցել:

Այս մոտեցումը խաթարում է որոշակի տարբերություններ. եթե ահազանգը բավարարում է նախորդ չորս պայմանները, նշանակություն չունի՝ ահազանգն ուղարկվում է White-box, թե Black-Box մոնիտորինգի համակարգից: Այս մոտեցումը նաև ամրապնդում է որոշակի տարբերություններ. ավելի լավ է շատ ավելի ջանք ծախսել ախտանիշների բացահայտման վրա, քան պատճառների վրա. երբ խոսքը վերաբերում է պատճառներին, պետք է անհանգստանալ միայն անխուսափելի պատճառների մասին:

Երկարաժամկետ մոնիտորինգ

Այսօրվա արտադրողականության միջավայրում մոնիտորինգի համակարգերը վերահսկում են անընդհատ զարգացող արտադրական համակարգը՝ փոփոխվող ծրագրային ճարտարապետությամբ, աշխատանքային ծանրաբեռնվածության բնութագրերով և կատարողականի թիրախներով: Զգուշացումները, որոնք ներկայումս դժվար է ավտոմատացնել, կարող են սովորական դառնալ, գուցե նույնիսկ արժե անդրադառնալ: Այս պահին ինչ-որ մեկը պետք է գտնի և վերացնի խնդրի բուն պատճառները. եթե նման լուծումը հնարավոր չէ, ահազանգին պատասխանը պահանջում է ամբողջական ավտոմատացում:

Կարևոր է, որ մշտադիտարկման որոշումները կայացվեն երկարաժամկետ նպատակներով: Այսօր գործարկվող յուրաքանչյուր ահազանգ մարդուն շեղում է վաղվա համակարգը բարելավելուց, ուստի հաճախ նկատվում է արդյունավետ համակարգի հասանելիության կամ արդյունավետության կրճատում այն ​​ժամանակի համար, որն անհրաժեշտ է երկարաժամկետ մոնիտորինգի համակարգը բարելավելու համար: Այս երևույթը լուսաբանելու համար նայենք երկու օրինակ։

Bigtable SRE. A Tale of Over-Alert

Google-ի ներքին ենթակառուցվածքը սովորաբար տրամադրվում և չափվում է ծառայության մակարդակով (SLO): Շատ տարիներ առաջ Bigtable-ի SLO ծառայությունը հիմնված էր կենդանի հաճախորդի մոդելավորող սինթետիկ գործարքի միջին կատարողականի վրա: Bigtable-ի և պահեստավորման ավելի ցածր մակարդակների խնդիրների պատճառով միջին կատարողականությունը պայմանավորված էր «մեծ» պոչով. հարցումների վատագույն 5%-ը հաճախ զգալիորեն ավելի դանդաղ էր, քան մնացածը:

Էլփոստով ծանուցումներ են ուղարկվել SLO-ի շեմին մոտենալուն պես, և մեսենջերի ծանուցումները ուղարկվել են SLO-ի գերազանցման դեպքում: Ծանուցումների երկու տեսակներն էլ բավականին հաճախ էին ուղարկվում՝ անթույլատրելի քանակությամբ ինժեներական ժամանակ խլելով. թիմը զգալի ժամանակ է ծախսել՝ դասավորելով ահազանգերը՝ գտնելու այն մի քանիսը, որոնք իրականում տեղին էին: Մենք հաճախ բաց ենք թողել մի խնդիր, որն իրականում ազդել է օգտատերերի վրա, քանի որ ծանուցումներից միայն որոշներն են եղել այդ կոնկրետ խնդրի համար: Ահազանգերից շատերը հրատապ չեն եղել ենթակառուցվածքում հասկանալի խնդիրների պատճառով և մշակվել են ստանդարտ ձևով կամ ընդհանրապես չեն մշակվել։

Իրավիճակը շտկելու համար թիմը կիրառեց եռակողմ մոտեցում. ջանասիրաբար աշխատելով Bigtable-ի կատարողականությունը բարելավելու համար, մենք ժամանակավորապես մեր SLO-ի նպատակը դրեցինք հարցման պատասխանի ուշացման 75-րդ տոկոսը: Մենք նաև անջատեցինք էլեկտրոնային փոստի ծանուցումները, քանի որ դրանք այնքան շատ էին, որ անհնար էր ժամանակ ծախսել դրանց ախտորոշման վրա:

Այս ռազմավարությունը թույլ տվեց մեզ շնչառական սենյակին սկսել շտկել երկարաժամկետ խնդիրները Bigtable-ում և պահեստավորման ավելի ցածր մակարդակներում, այլ ոչ թե անընդհատ շտկել մարտավարական խնդիրները: Ինժեներները կարող էին իրականում կատարել աշխատանքը՝ առանց անընդհատ ազդանշաններով ռմբակոծվելու: Ի վերջո, ահազանգերի մշակման ժամանակավոր հետաձգումը մեզ թույլ տվեց բարելավել մեր ծառայության որակը:

Gmail՝ կանխատեսելի, ալգորիթմական մարդկային պատասխաններ

Իր սկզբնավորման ժամանակ Gmail-ը ստեղծվել է փոփոխված Workqueue գործընթացների կառավարման համակարգի վրա, որը նախատեսված էր որոնման ինդեքսի հատվածների խմբաքանակի մշակման համար: Աշխատանքային հերթը հարմարեցված էր երկարատև գործընթացներին և այնուհետև կիրառվեց Gmail-ում, սակայն անթափանց ժամանակացույցի կոդի որոշ սխալներ շտկելը շատ դժվար էր:

Այն ժամանակ Gmail-ի մոնիտորինգը կառուցված էր այնպես, որ ծանուցումներ սկսվեին, երբ անհատական ​​առաջադրանքները չեղարկվեն Workqueue-ի միջոցով: Այս մոտեցումը իդեալական չէր, քանի որ նույնիսկ այն ժամանակ Gmail-ը կատարում էր հազարավոր առաջադրանքներ, որոնցից յուրաքանչյուրը տրամադրվում էր մեր օգտատերերի մի մասի տոկոսին: Մենք շատ մտահոգված էինք Gmail-ի օգտատերերին օգտատերերի լավ փորձով ապահովելու համար, սակայն այդքան շատ ծանուցումների հետ աշխատելն անհասանելի էր:

Այս խնդիրը լուծելու համար Gmail SRE-ը ստեղծեց գործիք, որը կօգնի հնարավորինս լավ կարգաբերել ժամանակացույցը, որպեսզի նվազագույնի հասցնի օգտատերերի վրա ազդեցությունը: Թիմը որոշ քննարկումներ ունեցավ այն մասին, թե արդյոք պարզապես ավտոմատացնել ամբողջ ցիկլը խնդրի հայտնաբերումից մինչև վերականգնում մինչև երկարաժամկետ լուծում գտնելը, բայց ոմանք մտահոգված էին, որ նման լուծումը կհետաձգի խնդրի իրականում շտկելը:

Այս լարվածությունը սովորական էր թիմում և հաճախ արտացոլում էր ինքնակարգապահության նկատմամբ վստահության պակասը. մինչ թիմի որոշ անդամներ ցանկանում են ժամանակ տալ ճիշտ ուղղման համար, մյուսները անհանգստանում են, որ վերջնական շտկումը կմոռացվի, իսկ ժամանակավոր շտկումը ընդմիշտ կտևի: Այս խնդիրը ուշադրության է արժանի, քանի որ չափազանց հեշտ է ժամանակավորապես շտկել խնդիրները՝ իրավիճակը մշտական ​​դարձնելու փոխարեն: Ղեկավարներն ու տեխնիկական անձնակազմը առանցքային դեր են խաղում երկարաժամկետ շտկումներ իրականացնելու գործում՝ աջակցելով և առաջնահերթություն տալով հնարավոր երկարաժամկետ շտկումներին՝ նույնիսկ նախնական «ցավը» նվազելուց հետո:

Կանոնավոր, կրկնվող ահազանգերը և ալգորիթմական պատասխանները պետք է լինեն կարմիր դրոշակ: Այս ահազանգերը ավտոմատացնելու ձեր թիմի դժկամությունը նշանակում է, որ թիմը վստահություն չունի, որ նրանք կարող են վստահել ալգորիթմներին: Սա լուրջ խնդիր է, որը պետք է լուծվի:

Երկարաժամկետ հեռանկարում

Ընդհանուր թեման կապում է Bigtable-ի և Gmail-ի օրինակները՝ մրցակցությունը կարճաժամկետ և երկարաժամկետ հասանելիության միջև: Հաճախ ուժեղ ջանքերը կարող են օգնել փխրուն համակարգին հասնել բարձր հասանելիության, սակայն այս ճանապարհը սովորաբար կարճատև է, հղի է թիմային այրմամբ և կախվածությամբ նույն հերոսական թիմի փոքրաթիվ անդամներից:

Հասանելիության վերահսկվող, կարճաժամկետ կրճատումը հաճախ ցավոտ է, բայց ռազմավարական նշանակություն ունի համակարգի երկարաժամկետ կայունության համար: Կարևոր է չդիտել յուրաքանչյուր ահազանգ առանձին-առանձին, այլ դիտարկել, թե արդյո՞ք ահազանգի ընդհանուր մակարդակը հանգեցնում է առողջ, պատշաճ կերպով հասանելի համակարգի՝ կենսունակ թիմով և բարենպաստ կանխատեսմամբ: Մենք վերլուծում ենք ահազանգերի հաճախականության վիճակագրությունը (սովորաբար արտահայտվում է որպես միջադեպեր մեկ հերթափոխով, որտեղ միջադեպը կարող է բաղկացած լինել բազմաթիվ առնչվող միջադեպերից) ղեկավարությանը տրված եռամսյակային հաշվետվություններում, ինչը որոշում կայացնողներին թույլ է տալիս շարունակական պատկերացում կազմել ազդանշանային համակարգի ծանրաբեռնվածության և ընդհանուր թիմի առողջության մասին:

Ամփոփում

Առողջ մոնիտորինգի և ահազանգման ճանապարհը պարզ է և պարզ: Այն կենտրոնանում է խնդրի ախտանիշների վրա, որոնք առաջացնում են ահազանգեր, և պատճառի մոնիտորինգը օգնում է վրիպազերծել խնդիրները: Ախտանիշների մոնիտորինգն ավելի հեշտ է, որքան ավելի բարձր եք գտնվում ձեր վերահսկողության տակ գտնվող կույտում, չնայած տվյալների բազայի բեռնվածության և կատարողականի մոնիտորինգը պետք է իրականացվի անմիջապես տվյալների բազայի վրա: Էլփոստի ծանուցումները շատ սահմանափակ օգտակարություն ունեն և հակված են հեշտությամբ վերածվել աղմուկի. փոխարենը, դուք պետք է օգտագործեք վահանակ, որը վերահսկում է բոլոր ընթացիկ խնդիրները, որոնք առաջացնում են էլփոստի ծանուցումներ: Վահանակը կարող է նաև զուգակցվել իրադարձությունների գրանցամատյանի հետ՝ պատմական հարաբերակցությունները վերլուծելու համար:

Երկարաժամկետ հեռանկարում անհրաժեշտ է հասնել ախտանշանների և մոտալուտ իրական խնդիրների մասին ահազանգերի հաջող ռոտացիայի, նպատակները հարմարեցնելով ապահովելու համար, որ մոնիտորինգն աջակցում է արագ ախտորոշմանը:

Շնորհակալություն թարգմանությունը մինչև վերջ կարդալու համար։ Բաժանորդագրվեք իմ հեռագրային ալիքին մոնիտորինգի մասին @monitorim_it и բլոգը Medium-ում.

Source: www.habr.com