Ես Անտոն Բադերինն եմ։ Աշխատում եմ Բարձր տեխնոլոգիաների կենտրոնում և զբաղվում եմ համակարգի ադմինիստրացիայով։ Մեկ ամիս առաջ ավարտվեց մեր կորպորատիվ համաժողովը, որտեղ մենք կիսեցինք մեր կուտակած փորձը մեր քաղաքի ՏՏ համայնքի հետ։ Ես խոսեցի վեբ հավելվածների մոնիտորինգի մասին: Նյութը նախատեսված էր կրտսեր կամ միջին մակարդակի համար, ովքեր այս գործընթացը զրոյից չեն կառուցել:
Ցանկացած մոնիտորինգի համակարգի հիմքում ընկած հիմնաքարը բիզնեսի խնդիրների լուծումն է: Հանուն մոնիտորինգի մոնիտորինգը ոչ մեկին չի հետաքրքրում։ Ի՞նչ է ուզում բիզնեսը: Որպեսզի ամեն ինչ աշխատի արագ և առանց սխալների: Ձեռնարկությունները ցանկանում են լինել ակտիվ, որպեսզի մենք ինքներս հայտնաբերենք ծառայության խնդիրները և հնարավորինս արագ շտկենք դրանք: Սրանք, ըստ էության, այն խնդիրներն են, որոնք ես լուծել եմ անցյալ տարի մեր հաճախորդներից մեկի նախագծում:
Ծրագրի մասին
Նախագիծը երկրում հավատարմության ամենախոշոր ծրագրերից է: Մենք օգնում ենք մանրածախ ցանցերին մեծացնել վաճառքի հաճախականությունը տարբեր մարքեթինգային գործիքների միջոցով, ինչպիսիք են բոնուսային քարտերը: Ընդհանուր առմամբ, նախագիծը ներառում է 14 հավելված, որոնք աշխատում են տասը սերվերի վրա։
Հարցազրույցի ընթացքում ես բազմիցս նկատել եմ, որ ադմինները միշտ չէ, որ ճիշտ են մոտենում վեբ հավելվածների մոնիտորինգին. շատերը դեռ կենտրոնանում են օպերացիոն համակարգի չափումների վրա և երբեմն վերահսկում են ծառայությունները:
Իմ դեպքում, հաճախորդի մոնիտորինգի համակարգը նախկինում հիմնված էր Icinga-ի վրա: Այն ոչ մի կերպ չլուծեց վերը նշված խնդիրները։ Հաճախ հաճախորդն ինքն էր մեզ տեղեկացնում խնդիրների մասին, և ավելի հաճախ մենք պարզապես չունեինք բավականաչափ տվյալներ՝ պատճառն հասկանալու համար:
Բացի այդ, հստակ պատկերացում կար դրա հետագա զարգացման ապարդյունության մասին։ Կարծում եմ՝ նրանք, ովքեր ծանոթ են Icinga-ին, կհասկանան ինձ։ Այսպիսով, մենք որոշեցինք ամբողջությամբ վերանախագծել վեբ հավելվածների մոնիտորինգի համակարգը նախագծի համար:
Պրոմեթեւս
Մենք ընտրեցինք Պրոմեթևսը երեք հիմնական ցուցանիշների հիման վրա.
- Հասանելի չափումների մեծ քանակ: Մեր դեպքում դրանք 60 հազար են։ Իհարկե, հարկ է նշել, որ մենք չենք օգտագործում դրանց ճնշող մեծամասնությունը (հավանաբար մոտ 95%): Մյուս կողմից, դրանք բոլորն էլ համեմատաբար էժան են: Մեզ համար սա մյուս ծայրահեղությունն է՝ համեմատած նախկինում օգտագործված Icinga-ի հետ: Դրանում չափորոշիչներ ավելացնելը առանձնահատուկ ցավ էր. գոյություն ունեցողները թանկ էին (ուղղակի նայեք ցանկացած plugin-ի սկզբնական կոդը): Ցանկացած փլագին Bash-ում կամ Python-ում սկրիպտ էր, որի գործարկումը թանկ է ծախսված ռեսուրսների առումով։
- Այս համակարգը սպառում է համեմատաբար փոքր քանակությամբ ռեսուրսներ: 600 ՄԲ օպերատիվ հիշողություն, մեկ միջուկի 15%-ը և մի քանի տասնյակ IOPS բավարար են մեր բոլոր չափումների համար: Իհարկե, դուք պետք է գործարկեք մետրիկ արտահանողներ, բայց դրանք բոլորը գրված են Go-ում և նույնպես շատ էներգիա չեն պահանջում: Չեմ կարծում, որ ժամանակակից իրողություններում դա խնդիր է։
- Ապահովում է Kubernetes միգրացիայի հնարավորություն: Հաշվի առնելով հաճախորդի ծրագրերը՝ ընտրությունն ակնհայտ է.
ELK
Նախկինում մենք չենք հավաքել կամ մշակել տեղեկամատյանները: Թերությունները բոլորին պարզ են. Ընտրեցինք ԵԼՔ-ը, քանի որ արդեն ունեինք այս համակարգի փորձ։ Մենք այնտեղ պահում ենք միայն հավելվածների տեղեկամատյանները: Ընտրության հիմնական չափանիշներն էին ամբողջական տեքստի որոնումը և դրա արագությունը:
Լիքհաուս
Սկզբում ընտրությունն ընկավ InfluxDB-ի վրա: Մենք հասկացանք, որ անհրաժեշտ է հավաքել Nginx տեղեկամատյանները, վիճակագրությունը pg_stat_statements-ից և պահպանել Պրոմեթևսի պատմական տվյալները: Մեզ դուր չեկավ Influx-ը, քանի որ այն պարբերաբար սկսում էր մեծ քանակությամբ հիշողություն սպառել և խափանում էր: Բացի այդ, ես ուզում էի հարցումները խմբավորել ըստ remote_addr-ի, բայց այս DBMS-ում խմբավորումը միայն թեգերով է: Թեգերը թանկ են (հիշողություն), դրանց թիվը պայմանականորեն սահմանափակ է։
Մենք նորից սկսեցինք մեր որոնումները։ Այն, ինչ անհրաժեշտ էր, վերլուծական տվյալների բազան էր՝ նվազագույն ռեսուրսների սպառմամբ, ցանկալի է՝ տվյալների սեղմումով սկավառակի վրա:
Clickhouse-ը համապատասխանում է այս բոլոր չափանիշներին, և մենք երբեք չենք զղջացել մեր ընտրության համար: Մենք դրա մեջ որևէ արտասովոր քանակի տվյալներ չենք գրում (տեղադրումների քանակը րոպեում ընդամենը մոտ հինգ հազար է):
NewRelic
NewRelic-ը պատմականորեն եղել է մեզ հետ, քանի որ դա հաճախորդի ընտրությունն էր: Մենք այն օգտագործում ենք որպես APM:
Zabbix- ը
Մենք օգտագործում ենք Zabbix-ը բացառապես տարբեր API-ների Black Box-ը վերահսկելու համար:
Մոնիտորինգի մոտեցման սահմանում
Մենք ցանկանում էինք տարրալուծել առաջադրանքը և դրանով իսկ համակարգել մոնիտորինգի մոտեցումը:
Դա անելու համար ես մեր համակարգը բաժանեցի հետևյալ մակարդակների.
- ապարատային և VMS;
- օպերացիոն համակարգ;
- համակարգային ծառայություններ, ծրագրային փաթեթ;
- դիմում;
- բիզնես տրամաբանություն.
Ինչու է այս մոտեցումը հարմար.
- մենք գիտենք, թե ով է պատասխանատու յուրաքանչյուր մակարդակի աշխատանքի համար, և դրա հիման վրա մենք կարող ենք ահազանգեր ուղարկել.
- մենք կարող ենք օգտագործել կառուցվածքը ահազանգերը ճնշելիս. տարօրինակ կլինի ահազանգ ուղարկել տվյալների բազայի անհասանելիության մասին, երբ վիրտուալ մեքենան ամբողջությամբ անհասանելի է:
Քանի որ մեր խնդիրն է բացահայտել համակարգի գործունեության խախտումները, մենք պետք է յուրաքանչյուր մակարդակում առանձնացնենք չափումների որոշակի շարք, որոնց արժե ուշադրություն դարձնել ահազանգման կանոններ գրելիս: Հաջորդը, եկեք անցնենք «VMS», «Օպերացիոն համակարգ» և «Համակարգային ծառայություններ, ծրագրային փաթեթ»:
Վիրտուալ մեքենաներ
Հոսթինգը մեզ տրամադրում է պրոցեսոր, սկավառակ, հիշողություն և ցանց: Իսկ առաջին երկուսի հետ կապված խնդիրներ ունեինք։ Այսպիսով, չափումները.
CPU-ի գողացված ժամանակը. երբ գնում եք վիրտուալ մեքենա Amazon-ում (t2.micro, օրինակ), դուք պետք է հասկանաք, որ ձեզ ոչ թե ամբողջ պրոցեսորի միջուկ է հատկացվում, այլ միայն դրա ժամանակի քվոտան: Իսկ երբ սպառես, պրոցեսորը քեզնից կխլեն։
Այս չափանիշը թույլ է տալիս հետևել նման պահերին և որոշումներ կայացնել: Օրինակ՝ անհրաժեշտ է ավելի հաստ սակագին վերցնել կամ բաշխել ֆոնային առաջադրանքների և API հարցումների մշակումը տարբեր սերվերների վրա։
IOPS + CPU iowait time - չգիտես ինչու, շատ ամպային հոսթինգներ մեղք են գործում՝ բավարար IOPS չտրամադրելով: Ավելին, ցածր IOPS-ով գրաֆիկը նրանց համար փաստարկ չէ: Հետևաբար, արժե CPU հավաքել iowait: Այս զույգ գրաֆիկներով՝ ցածր IOPS-ով և բարձր I/O սպասմամբ, դուք արդեն կարող եք խոսել հոսթինգի հետ և լուծել խնդիրը:
Օպերացիոն համակարգ
Օպերացիոն համակարգի չափումներ.
- հասանելի հիշողության քանակը %;
- swap օգտագործման ակտիվություն՝ vmstat swapin, swapout;
- հասանելի ինոդների քանակը և ֆայլային համակարգում ազատ տարածությունը %
- միջին ծանրաբեռնվածություն;
- միացումների քանակը երկու վիճակում;
- վերահսկել սեղանի լրիվությունը;
- Ցանցի որակը կարելի է վերահսկել՝ օգտագործելով ss կոմունալ ծրագիրը, iproute2 փաթեթը - ստացեք RTT կապերի ցուցիչ դրա ելքից և խմբավորեք այն ըստ dest port-ի:
Նաև օպերացիոն համակարգի մակարդակում մենք ունենք այնպիսի կառույց, ինչպիսին գործընթացներն են: Կարևոր է համակարգում բացահայտել գործընթացների մի շարք, որոնք կարևոր դեր են խաղում դրա գործունեության մեջ: Եթե, օրինակ, դուք ունեք մի քանի pgpool, ապա դուք պետք է տեղեկատվություն հավաքեք դրանցից յուրաքանչյուրի համար։
Չափումների հավաքածուն հետևյալն է.
- Պրոցեսոր;
- հիշողությունը հիմնականում ռեզիդենտ է.
- IO - նախընտրելի է IOPS-ում;
- FileFd - բաց և սահմանափակում;
- էջի զգալի ձախողումներ. այս կերպ դուք կարող եք հասկանալ, թե ինչ գործընթաց է փոխվում:
Մենք տեղադրում ենք ամբողջ մոնիտորինգը Docker-ում և օգտագործում ենք Advisor-ը՝ չափումների տվյալներ հավաքելու համար: Այլ մեքենաների վրա մենք օգտագործում ենք գործընթաց-արտահանող:
Համակարգային ծառայություններ, ծրագրային փաթեթ
Յուրաքանչյուր հավելված ունի իր առանձնահատկությունները, և դժվար է առանձնացնել չափումների որոշակի հավաքածու:
Ունիվերսալ հավաքածուն հետևյալն է.
- պահանջի տոկոսադրույքը;
- սխալների քանակը;
- ուշացում;
- հագեցվածություն.
Այս մակարդակի մոնիտորինգի մեր ամենավառ օրինակներն են Nginx-ը և PostgreSQL-ը:
Մեր համակարգում ամենաբեռնված ծառայությունը տվյալների բազան է: Նախկինում մենք հաճախ դժվարանում էինք պարզել, թե ինչ է անում տվյալների բազան:
Մենք տեսանք մեծ ծանրաբեռնվածություն սկավառակների վրա, բայց դանդաղ տեղեկամատյանները իրականում ոչինչ ցույց չտվեցին: Մենք լուծեցինք այս խնդիրը՝ օգտագործելով pg_stat_statements, տեսակետ, որը հավաքում է հարցումների վիճակագրությունը:
Դա այն ամենն է, ինչ անհրաժեշտ է ադմինիստրատորին:
Մենք կառուցում ենք կարդալու և գրելու հարցումների գործունեության գրաֆիկները.
Ամեն ինչ պարզ է և պարզ, յուրաքանչյուր խնդրանք ունի իր գույնը:
Նույնքան վառ օրինակ է Nginx տեղեկամատյանները: Զարմանալի չէ, որ քչերն են դրանք վերլուծում կամ նշում պարտադիր ապրանքների ցանկում։ Ստանդարտ ձևաչափը այնքան էլ տեղեկատվական չէ և պետք է ընդլայնվի:
Անձամբ ես ավելացրել եմ request_time, upstream_response_time, body_bytes_sent, request_length, request_id: Մենք գծագրում ենք պատասխանի ժամանակը և սխալների քանակը.
Մենք կառուցում ենք արձագանքման ժամանակի և սխալների քանակի գրաֆիկներ: Հիշո՞ւմ ես։ Ես խոսե՞լ եմ բիզնես առաջադրանքների մասին: Արդյո՞ք արագ և առանց սխալների: Այս հարցերին մենք արդեն անդրադարձել ենք երկու գծապատկերներով։ Իսկ նրանցից օգտվելով արդեն կարող եք զանգահարել հերթապահ ադմինիստրատորներին։
Սակայն մնում է ևս մեկ խնդիր՝ ապահովել միջադեպի պատճառների արագ վերացումը։
Միջադեպի լուծում
Ամբողջ գործընթացը՝ նույնականացումից մինչև խնդրի լուծում, կարելի է բաժանել մի շարք քայլերի.
- խնդրի բացահայտում;
- ծանուցում հերթապահին.
- արձագանքը միջադեպին;
- պատճառների վերացում.
Կարևոր է, որ մենք պետք է դա անենք հնարավորինս արագ։ Եվ եթե խնդրի բացահայտման և ծանուցում ուղարկելու փուլում մենք չենք կարող շատ ժամանակ շահել, ամեն դեպքում երկու րոպե կծախսվի դրանց վրա, ապա հետագաները պարզապես չհերկված դաշտ են բարելավման համար։
Պատկերացնենք, որ հերթապահի հեռախոսը զանգեց։ ի՞նչ է անելու։ Փնտրեք հարցերի պատասխանները՝ ի՞նչը կոտրվեց, որտե՞ղ կոտրվեց, ինչպե՞ս արձագանքել: Ահա թե ինչպես ենք մենք պատասխանում այս հարցերին.
Մենք պարզապես ներառում ենք այս ամբողջ տեղեկատվությունը ծանուցման տեքստում, տալիս ենք հղում դեպի վիքի էջի, որը նկարագրում է, թե ինչպես արձագանքել այս խնդրին, ինչպես լուծել այն և ընդլայնել այն:
Ես դեռ ոչինչ չեմ ասել հավելվածի շերտի և բիզնես տրամաբանության մասին։ Ցավոք, մեր հավելվածները դեռ չեն իրականացնում չափումների հավաքածու: Այս մակարդակներից որևէ տեղեկատվության միակ աղբյուրը տեղեկամատյաններն են:
Մի երկու կետ.
Նախ, գրեք կառուցվածքային տեղեկամատյաններ: Հաղորդագրության տեքստում համատեքստ ներառելու կարիք չկա։ Սա դժվարացնում է նրանց խմբավորումն ու վերլուծությունը: Logstash-ը երկար ժամանակ է պահանջում այս ամենը նորմալացնելու համար։
Երկրորդ, ճիշտ օգտագործեք խստության մակարդակները: Յուրաքանչյուր լեզու ունի իր չափանիշը: Անձամբ ես առանձնացնում եմ չորս մակարդակ.
- ոչ մի սխալ;
- հաճախորդի կողմից սխալ;
- սխալը մեր կողմն է, մենք փող չենք կորցնում, ռիսկեր չենք կրում.
- Սխալը մեր կողմն է, մենք փող ենք կորցնում։
Ամփոփեմ. Պետք է փորձել մոնիտորինգ կառուցել՝ հիմնված բիզնես տրամաբանության վրա: Փորձեք վերահսկել հավելվածն ինքնին և գործել այնպիսի չափանիշներով, ինչպիսիք են վաճառքների քանակը, նոր օգտվողների գրանցումների քանակը, ներկայումս ակտիվ օգտատերերի թիվը և այլն:
Եթե ձեր ամբողջ բիզնեսը զննարկիչում մեկ կոճակ է, դուք պետք է վերահսկեք, թե արդյոք այն կտտացնում է և ճիշտ է աշխատում: Մնացած բոլորը նշանակություն չունեն։
Եթե դուք չունեք սա, կարող եք փորձել հասնել դրան հավելվածների մատյաններում, Nginx տեղեկամատյաններում և այլն, ինչպես մենք արեցինք: Դուք պետք է հնարավորինս մոտ լինեք հավելվածին:
Օպերացիոն համակարգի չափորոշիչները, իհարկե, կարևոր են, բայց բիզնեսը դրանցով չի հետաքրքրվում, մենք դրանց դիմաց չենք վարձատրվում:
Source: www.habr.com