Այսօր, բացի մոնոլիտ կոդից, մեր նախագիծը ներառում է տասնյակ միկրոծառայություններ։ Նրանցից յուրաքանչյուրը պահանջում է վերահսկել: Նման մասշտաբով դա անելը, օգտագործելով DevOps ինժեներները, խնդրահարույց է: Մենք մշակել ենք մոնիտորինգի համակարգ, որն աշխատում է որպես ծառայություն մշակողների համար: Նրանք կարող են ինքնուրույն գրել չափումներ մոնիտորինգի համակարգում, օգտագործել դրանք, դրանց հիման վրա ստեղծել վահանակներ և դրանց կցել ազդանշաններ, որոնք կգործարկվեն, երբ սահմանային արժեքները հասնեն: DevOps-ի ինժեներների համար միայն ենթակառուցվածք և փաստաթղթեր:
Այս գրառումը մեր հետ ունեցած իմ ելույթի սղագրությունն է RIT++-ում: Շատերը մեզ խնդրում էին այնտեղից պատրաստել զեկույցների տեքստային տարբերակներ: Եթե կոնֆերանսին լինեիք կամ դիտեիք տեսանյութը, նոր բան չեք գտնի։ Եվ մնացած բոլորը - բարի գալուստ կատու: Ես ձեզ կասեմ, թե ինչպես ենք մենք եկել նման համակարգ, ինչպես է այն աշխատում և ինչպես ենք նախատեսում թարմացնել այն:
Անցյալ. սխեմաներ և պլաններ
Ինչպե՞ս հասանք մոնիտորինգի ներկայիս համակարգին: Այս հարցին պատասխանելու համար հարկավոր է գնալ 2015թ. Ահա թե ինչ տեսք ուներ այն ժամանակ.
Մենք ունեինք մոտ 24 հանգույց, որոնք պատասխանատու էին մոնիտորինգի համար: Կա տարբեր թագերի, սցենարների, դևերի մի ամբողջ փաթեթ, որոնք ինչ-որ կերպ վերահսկում են ինչ-որ բան, ուղարկում հաղորդագրություններ և կատարում գործառույթներ: Մենք կարծում էինք, որ ինչքան առաջ գնանք, այնքան ավելի քիչ կենսունակ կլինի նման համակարգը։ Այն զարգացնելն իմաստ չունի. դա չափազանց ծանր է:
Մենք որոշեցինք ընտրել մոնիտորինգի այն տարրերը, որոնք կպահենք ու զարգացնենք, և որոնք կհրաժարվենք։ Դրանք 19-ն էին։Մնացել էին միայն գրաֆիտներ, ագրեգատորներ և Grafana՝ որպես վահանակ։ Բայց ինչպիսի՞ն կլինի նոր համակարգը։ Սրա նման:
Մենք ունենք չափումների պահեստ. սրանք գրաֆիտներ են, որոնք հիմնված կլինեն արագ SSD կրիչների վրա, դրանք որոշակի ագրեգատորներ են չափումների համար։ Հաջորդը՝ Grafana վահանակները ցուցադրելու համար և Moira՝ ահազանգելու համար: Մենք նաև ցանկանում էինք մշակել անոմալիաների որոնման համակարգ։
Ստանդարտ՝ մոնիտորինգ 2.0
Ահա թե ինչպիսին էին պլանները 2015 թվականին: Բայց մենք պետք է պատրաստեինք ոչ միայն ենթակառուցվածքը և բուն ծառայությունը, այլև դրա համար փաստաթղթերը: Մենք մեզ համար մշակել ենք կորպորատիվ ստանդարտ, որը մենք անվանում ենք մոնիտորինգ 2.0։ Որո՞նք էին համակարգի պահանջները:
- մշտական հասանելիություն;
- չափումների պահպանման միջակայքը = 10 վայրկյան;
- չափումների և վահանակների կառուցվածքային պահպանում;
- SLA > 99,99%
- իրադարձությունների չափումների հավաքածու UDP-ի միջոցով (!):
Մեզ անհրաժեշտ էր UDP, քանի որ մենք ունենք երթևեկի և իրադարձությունների մեծ հոսք, որոնք առաջացնում են չափումներ: Եթե դրանք բոլորը միանգամից գրեք գրաֆիտի մեջ, պահեստը կփլուզվի: Մենք նաև ընտրեցինք առաջին մակարդակի նախածանցներ բոլոր չափումների համար:
Նախածանցներից յուրաքանչյուրն ունի որոշակի հատկություն։ Կան չափումներ սերվերների, ցանցերի, կոնտեյներների, ռեսուրսների, հավելվածների և այլնի համար: Իրականացվել է հստակ, խիստ, տպագրված զտում, որտեղ մենք ընդունում ենք առաջին մակարդակի չափումները և պարզապես թողնում ենք մնացածը: Այս համակարգը մենք 2015թ. Ի՞նչ կա ներկայում:
Ներկա՝ մոնիտորինգի բաղադրիչների փոխազդեցության դիագրամ
Առաջին հերթին մենք վերահսկում ենք հավելվածները՝ մեր PHP կոդը, հավելվածները և միկրոծառայությունները, մի խոսքով, այն ամենը, ինչ գրում են մեր մշակողները: Բոլոր հավելվածներն ուղարկում են չափումներ UDP-ի միջոցով Brubeck ագրեգատորին (statsd, վերագրված է C-ով): Պարզվել է, որ այն ամենաարագն է սինթետիկ թեստերում։ Եվ այն TCP-ի միջոցով ուղարկում է արդեն ագրեգացված չափումները Graphite-ին:
Այն ունի չափումների մի տեսակ, որը կոչվում է ժամանակաչափ: Սա շատ հարմար բան է։ Օրինակ՝ ծառայության հետ յուրաքանչյուր օգտատիրոջ միացման համար դուք Brubeck-ին ուղարկում եք չափանիշ՝ պատասխանի ժամանակով: Մեկ միլիոն պատասխան եկավ, բայց ագրեգատորը վերադարձրեց ընդամենը 10 չափումներ: Դուք ունեք եկածների թիվը, առավելագույն, նվազագույն և միջին պատասխանի ժամանակը, միջինը և 4 տոկոսը: Հետո տվյալները փոխանցվում են Graphite-ին և մենք տեսնում ենք այդ ամենը ուղիղ եթերում։
Մենք նաև ունենք ագրեգացիա ապարատային, ծրագրային ապահովման, համակարգի չափումների և մեր հին Munin մոնիտորինգի համակարգի համար (այն մեզ մոտ աշխատել է մինչև 2015 թվականը): Մենք այս ամենը հավաքում ենք C's CollectD դեյմոնի միջոցով (այն ունի իր մեջ ներկառուցված տարբեր փլագինների մի ամբողջ փունջ, այն կարող է հարցումներ կատարել հյուրընկալող համակարգի բոլոր ռեսուրսները, որոնց վրա այն տեղադրված է, պարզապես կոնֆիգուրացիայի մեջ նշեք, թե որտեղ պետք է գրել տվյալները) և գրեք տվյալները Գրաֆիտին դրա միջոցով: Այն նաև աջակցում է python պլագիններին և կեղևի սկրիպտներին, այնպես որ կարող եք գրել ձեր սեփական հատուկ լուծումները.
Այնուհետև մենք ուղարկում ենք բոլոր ցուցանիշները, որոնք հավաքել ենք Carbon-c-relay-ին: Սա Carbon Relay լուծումն է Graphite-ից, փոփոխված C-ով: Սա երթուղիչ է, որը հավաքում է բոլոր ցուցանիշները, որոնք մենք ուղարկում ենք մեր ագրեգատորներից և ուղղորդում դեպի հանգույցներ: Նաև երթուղավորման փուլում այն ստուգում է չափումների վավերականությունը: Նախ, դրանք պետք է համապատասխանեն նախածանցի սխեմային, որը ես ցույց տվեցի ավելի վաղ, և, երկրորդ, դրանք վավեր են գրաֆիտի համար: Հակառակ դեպքում դրանք կիջնեն:
Carbon-c-relay-ն այնուհետև չափումները ուղարկում է Գրաֆիտի կլաստերին: Մենք օգտագործում ենք Carbon-cache-ը, որը վերագրված է Go-ում, որպես չափումների հիմնական պահեստ: Go-carbon-ը, իր բազմաթելերի շնորհիվ, զգալիորեն գերազանցում է Carbon-cache-ին: Այն ստանում է տվյալներ և գրում այն սկավառակների վրա՝ օգտագործելով whisper փաթեթը (ստանդարտ, գրված է python-ով): Մեր պահեստներից տվյալները կարդալու համար մենք օգտագործում ենք Graphite API-ը: Այն շատ ավելի արագ է, քան ստանդարտ Graphite WEB-ը: Ի՞նչ կլինի հետո տվյալների հետ:
Նրանք գնում են Գրաֆանա: Մենք օգտագործում ենք մեր գրաֆիտի կլաստերները որպես տվյալների հիմնական աղբյուր, ինչպես նաև մենք ունենք Grafana-ն որպես վեբ ինտերֆեյս՝ չափումների ցուցադրման և վահանակներ կառուցելու համար: Իրենց յուրաքանչյուր ծառայության համար մշակողները ստեղծում են իրենց սեփական վահանակը: Այնուհետև դրանց հիման վրա կառուցում են գրաֆիկներ, որոնք ցուցադրում են այն չափումները, որոնք նրանք գրում են իրենց հավելվածներից: Բացի Grafana-ից ունենք նաև SLAM: Սա պիթոնի դև է, որը հաշվարկում է SLA-ն՝ հիմնվելով գրաֆիտի տվյալների վրա: Ինչպես արդեն ասացի, մենք ունենք մի քանի տասնյակ միկրոծառայություններ, որոնցից յուրաքանչյուրն ունի իր պահանջները։ Օգտագործելով SLAM-ը, մենք անցնում ենք փաստաթղթերին և համեմատում այն գրաֆիտում եղածի հետ և համեմատում, թե որքանով են պահանջները համապատասխանում մեր ծառայությունների հասանելիությանը:
Եկեք ավելի հեռուն գնանք՝ զգուշացնելով։ Այն կազմակերպվում է ուժեղ համակարգի միջոցով՝ Moira: Այն անկախ է, քանի որ այն ունի իր սեփական Գրաֆիտը գլխարկի տակ: Մշակված է SKB «Kontur»-ի տղաների կողմից, գրված է python-ով և Go-ով, ամբողջովին բաց կոդով: Մոիրան ստանում է նույն հոսքը, որը գնում է գրաֆիտների մեջ: Եթե ինչ-ինչ պատճառներով ձեր պահեստը մեռնի, ձեր ծանուցումը դեռ կաշխատի:
Մենք Moira-ն տեղակայեցինք Kubernetes-ում, այն օգտագործում է Redis սերվերների կլաստեր՝ որպես հիմնական տվյալների բազա: Արդյունքը եղավ սխալ հանդուրժող համակարգ: Այն համեմատում է չափումների հոսքը գործարկիչների ցանկի հետ. եթե դրանում հիշատակումներ չկան, ապա այն հանում է չափանիշը: Այսպիսով, այն կարողանում է մարսել գիգաբայթ ցուցանիշներ մեկ րոպեում:
Մենք դրան կցել ենք նաև կորպորատիվ LDAP, որի օգնությամբ կորպորատիվ համակարգի յուրաքանչյուր օգտատեր կարող է իր համար ստեղծել ծանուցումներ՝ հիմնվելով առկա (կամ նորաստեղծ) գործարկիչների վրա։ Քանի որ Moira-ն պարունակում է Գրաֆիտ, այն աջակցում է նրա բոլոր հնարավորություններին: Այսպիսով, դուք նախ վերցնում եք տողը և պատճենում այն Grafana-ում: Տեսեք, թե ինչպես են տվյալները ցուցադրվում գրաֆիկների վրա: Եվ հետո դուք վերցնում եք նույն տողը և պատճենում այն Moira-ում: Դուք այն կախում եք սահմանափակումներով և ազդանշան եք ստանում ելքի վրա: Այս ամենն անելու համար հատուկ գիտելիքներ պետք չեն։ Moira-ն կարող է զգուշացնել SMS-ի, էլ.փոստի, Jira-ի, Slack-ի միջոցով... Այն նաև աջակցում է մաքսային սկրիպտների կատարմանը: Երբ նրա հետ գործարկվում է, և նա բաժանորդագրվում է հատուկ սկրիպտի կամ երկուականի, նա գործարկում է այն և ուղարկում JSON-ին stdin այս երկուականի համար: Համապատասխանաբար, ձեր ծրագիրը պետք է վերլուծի այն: Թե ինչ կանեք այս JSON-ի հետ, կախված է ձեզանից: Եթե ուզում եք, ուղարկեք Telegram, եթե ուզում եք, Jira-ում առաջադրանքներ բացեք, ինչ արեք։
Մենք նաև օգտագործում ենք մեր սեփական զարգացումը ահազանգելու համար՝ Imagotag: Մենք հարմարեցրինք վահանակը, որը սովորաբար օգտագործվում է խանութներում էլեկտրոնային գների պիտակների համար, մեր կարիքներին համապատասխան: Մոյրայից ձգաններ բերեցինք դրան։ Այն ցույց է տալիս, թե ինչ վիճակում են նրանք և երբ են դրանք տեղի ունեցել: Մշակողներից ոմանք հրաժարվել են Slack-ում և էլփոստի ծանուցումներից՝ հօգուտ այս վահանակի:
Դե, քանի որ մենք առաջադեմ ընկերություն ենք, մենք նաև վերահսկել ենք Kubernetes-ը այս համակարգում։ Մենք այն ներառել ենք համակարգում՝ օգտագործելով Heapster-ը, որը մենք տեղադրել ենք կլաստերի մեջ, այն հավաքում է տվյալներ և ուղարկում Գրաֆիտ։ Արդյունքում դիագրամն այսպիսի տեսք ունի.
Մոնիտորինգի բաղադրիչներ
Ահա այս առաջադրանքի համար օգտագործած բաղադրիչների հղումների ցանկը: Դրանք բոլորն էլ բաց կոդով են։
Գրաֆիտ:
- go-carbon:
- շշնջալ:
- graphite-api:
Carbon-c-ռելե:
Բրուբեկ.
Հավաքված:
Մոիրա.
Գրաֆանա:
Heapster:
Վիճակագրություն
Եվ ահա որոշ թվեր, թե ինչպես է համակարգը աշխատում մեզ մոտ:
Ագրեգատոր (բրուբեկ)
Չափումների քանակը՝ ~300/վրկ
Գրաֆիտին չափումներ ուղարկելու ընդմիջումը՝ 30 վրկ
Սերվերի ռեսուրսների օգտագործում՝ ~ 6% CPU (խոսքը լիարժեք սերվերների մասին է); ~ 1 Գբ RAM; ~3 Մբիթ/վրկ LAN
Գրաֆիտ (գո-ածխածին)
Չափումների քանակը՝ ~ 1 / րոպե
Չափումների թարմացման ընդմիջումը՝ 30 վրկ
Չափումների պահպանման սխեման՝ 30 վրկ 35 դ, 5 րոպե 90 դ, 10 րոպե 365 դ (հնարավորություն է տալիս հասկանալ, թե ինչ է տեղի ունենում ծառայության հետ երկար ժամանակահատվածում)
Սերվերի ռեսուրսի օգտագործումը՝ ~10% CPU; ~ 20 Գբ RAM; ~30 Մբիթ/վրկ LAN
Ճկունություն
Մենք Avito-ում իսկապես կարևորում ենք մեր մոնիտորինգի ծառայության ճկունությունը: Ինչո՞ւ նա իրականում այսպիսի տեսք ստացավ: Նախ, դրա բաղադրիչները փոխարինելի են՝ և՛ բաղադրիչները, և՛ դրանց տարբերակները: Երկրորդ, աջակցության հնարավորությունը: Քանի որ ամբողջ նախագիծը բաց կոդով է, դուք կարող եք ինքներդ խմբագրել կոդը, փոփոխություններ կատարել և իրականացնել գործառույթներ, որոնք անհասանելի են: Օգտագործվում են բավականին տարածված կույտեր, հիմնականում Go և Python, ուստի դա արվում է բավականին պարզ:
Ահա իրական խնդրի օրինակ. Գրաֆիտում չափիչը ֆայլ է: Անուն ունի։ Ֆայլի անուն = մետրային անուն: Իսկ այնտեղ հասնելու ճանապարհ կա։ Linux-ում ֆայլերի անունները սահմանափակված են 255 նիշով: Եվ մենք ունենք (որպես «ներքին հաճախորդներ») տղաներ տվյալների բազայի բաժնից: Նրանք մեզ ասում են. «Մենք ցանկանում ենք վերահսկել մեր SQL հարցումները: Եվ դրանք ոչ թե 255 նիշ են, այլ յուրաքանչյուրը 8 ՄԲ: Մենք ցանկանում ենք դրանք ցուցադրել Grafana-ում, տեսնել այս հարցման պարամետրերը, և նույնիսկ ավելի լավ, մենք ցանկանում ենք տեսնել նման հարցումների վերին մասը: Հիանալի կլինի, եթե այն ցուցադրվի իրական ժամանակում: Իսկապես հիանալի կլիներ նրանց զգոնության մեջ դնելը»։
SQL հարցման օրինակը վերցված է որպես օրինակ
Մենք տեղադրում ենք Redis սերվեր և օգտագործում ենք մեր «Collectd» պլագինները, որոնք գնում են «Postgres» և այնտեղից վերցնում են բոլոր տվյալները՝ ուղարկելով չափումներ Graphite-ին: Բայց մենք մետրիկ անվանումը փոխարինում ենք հեշերով։ Մենք միաժամանակ ուղարկում ենք նույն հեշը Redis-ին՝ որպես բանալի, և ամբողջ SQL հարցումը՝ որպես արժեք։ Մեզ մնում է միայն համոզվել, որ Գրաֆանան կարող է գնալ Ռեդիս և վերցնել այս տեղեկատվությունը: Մենք բացում ենք Graphite API-ն, քանի որ... սա հիմնական ինտերֆեյսն է գրաֆիտի հետ մոնիտորինգի բոլոր բաղադրիչների փոխազդեցության համար, և մենք այնտեղ մուտքագրում ենք նոր գործառույթ, որը կոչվում է aliasByHash() - Grafana-ից մենք ստանում ենք չափման անվանումը և այն օգտագործում ենք Redis-ի հարցում որպես բանալի, պատասխանում մենք ստանում ենք բանալու արժեքը, որը մեր «SQL հարցումն» է»: Այսպիսով, մենք Grafana-ում ցուցադրեցինք SQL հարցման ցուցադրում, որը տեսականորեն անհնար էր ցուցադրել այնտեղ, ինչպես նաև դրա վերաբերյալ վիճակագրություն (զանգեր, տողեր, total_time, ...):
Արդյունքները
Հասանելիություն: Մեր մոնիտորինգի ծառայությունը հասանելի է 24/7 ցանկացած հավելվածից և ցանկացած կոդից: Եթե դուք մուտք ունեք պահեստավորման օբյեկտներ, կարող եք տվյալներ գրել ծառայությանը: Լեզուն կարևոր չէ, որոշումները կարևոր չեն։ Դուք միայն պետք է իմանաք, թե ինչպես բացել վարդակից, տեղադրել մետրիկ այնտեղ և փակել վարդակը:
Վստահելիություն: Բոլոր բաղադրիչները սխալ հանդուրժող են և լավ են վարում մեր բեռները:
Մուտքի ցածր խոչընդոտ. Այս համակարգը օգտագործելու համար ձեզ հարկավոր չէ Grafana-ում սովորել ծրագրավորման լեզուներ և հարցումներ: Պարզապես բացեք ձեր հավելվածը, մուտքագրեք դրա մեջ վարդակից, որը չափումներ կուղարկի Graphite-ին, կփակի այն, բացեք Grafana-ն, այնտեղ ստեղծեք վահանակներ և նայեք ձեր չափումների վարքագծին՝ ստանալով ծանուցումներ Moira-ի միջոցով:
Անկախություն. Այս ամենը կարող եք անել ինքներդ՝ առանց DevOps-ի ինժեներների օգնության։ Եվ սա առավելություն է, քանի որ դուք կարող եք վերահսկել ձեր նախագիծը հենց հիմա, պետք չէ որևէ մեկին խնդրել՝ կամ սկսել աշխատանքը, կամ փոփոխություններ կատարել:
Ինչի՞ն ենք մենք ձգտում:
Ստորև թվարկված ամեն ինչ պարզապես վերացական մտքեր չեն, այլ մի բան, որի ուղղությամբ գոնե առաջին քայլերն են արվել։
- Անոմալիայի դետեկտոր. Մենք ցանկանում ենք ստեղծել ծառայություն, որը կգնա մեր Գրաֆիտի պահեստները և կստուգի յուրաքանչյուր չափանիշ՝ օգտագործելով տարբեր ալգորիթմներ: Արդեն կան ալգորիթմներ, որոնք ուզում ենք դիտել, կան տվյալներ, մենք գիտենք՝ ինչպես աշխատել դրանց հետ։
- Մետատվյալներ. Մենք բազմաթիվ ծառայություններ ունենք, դրանք ժամանակի ընթացքում փոխվում են, ինչպես իրենց հետ աշխատող մարդիկ։ Փաստաթղթերի ձեռքով անընդհատ պահպանումը տարբերակ չէ: Ահա թե ինչու մենք այժմ մետատվյալներ ենք ներդնում մեր միկրոծառայությունների մեջ: Այն նշում է, թե ով է այն մշակել, լեզուների հետ, որոնց հետ համագործակցում է, SLA պահանջները, որտեղ և ում պետք է ուղարկվեն ծանուցումները: Ծառայությունը տեղակայելիս կազմակերպության բոլոր տվյալները ստեղծվում են ինքնուրույն: Արդյունքում դուք ստանում եք երկու հղում՝ մեկը դեպի ձգաններ, մյուսը՝ դեպի «Գրաֆանայի» վահանակներ:
- Մոնիտորինգ յուրաքանչյուր տանը: Մենք կարծում ենք, որ բոլոր մշակողները պետք է օգտագործեն նման համակարգ։ Այս դեպքում դու միշտ հասկանում ես, թե որտեղ է քո տրաֆիկը, ինչ է կատարվում նրա հետ, որտեղ է ընկնում, որտեղ են նրա թույլ կողմերը։ Եթե, օրինակ, ինչ-որ բան գա և խափանվի ձեր ծառայությունը, ապա դրա մասին կիմանաք ոչ թե մենեջերի զանգի ժամանակ, այլ ահազանգից, և կարող եք անմիջապես բացել վերջին տեղեկամատյանները և տեսնել, թե ինչ է տեղի ունեցել այնտեղ:
- Բարձր կատարողական. Մեր նախագիծն անընդհատ աճում է, և այսօր այն մշակում է րոպեում մոտ 2 մետրային արժեք: Մեկ տարի առաջ այս ցուցանիշը 000 էր, իսկ աճը շարունակվում է, և դա նշանակում է, որ որոշ ժամանակ անց Գրաֆիտը (շշուկով) կսկսի ծանրաբեռնել սկավառակի ենթահամակարգը: Ինչպես արդեն ասացի, այս մոնիտորինգի համակարգը բավականին ունիվերսալ է բաղադրիչների փոխանակելիության պատճառով: Ինչ-որ մեկը պահպանում և անընդհատ ընդլայնում է իր ենթակառուցվածքը հատուկ Graphite-ի համար, բայց մենք որոշեցինք գնալ այլ ճանապարհով՝ օգտագործել որպես մեր չափումների պահոց: Այս անցումը գրեթե ավարտված է, և շատ շուտով ես ձեզ ավելի մանրամասն կպատմեմ, թե ինչպես է դա արվել. ինչ դժվարություններ են եղել և ինչպես են դրանք հաղթահարվել, ինչպես է անցել միգրացիոն գործընթացը, ես նկարագրելու եմ որպես պարտադիր ընտրված բաղադրիչները և դրանց կոնֆիգուրացիաները:
Շնորհակալություն ուշադրության համար! Ձեր հարցերը տվեք թեմայի վերաբերյալ, կփորձեմ պատասխանել այստեղ կամ հաջորդ գրառումներում։ Միգուցե ինչ-որ մեկը նմանատիպ մոնիտորինգի համակարգ կառուցելու կամ նմանատիպ իրավիճակում Clickhouse-ին անցնելու փորձ ունի. կիսվեք այն մեկնաբանություններում:
Source: www.habr.com