Մոնիտորինգը մեռա՞ծ է: — Կեցցե մոնիտորինգը

2008 թվականից մեր ընկերությունը հիմնականում զբաղվում է ենթակառուցվածքների կառավարմամբ և վեբ նախագծերի շուրջօրյա տեխնիկական աջակցությամբ. մենք ունենք ավելի քան 400 հաճախորդ, ինչը կազմում է ռուսական էլեկտրոնային առևտրի մոտ 15%-ը: Համապատասխանաբար, աջակցվում է շատ բազմազան ճարտարապետություն: Եթե ​​ինչ-որ բան ընկնում է, մենք պարտավոր ենք 15 րոպեի ընթացքում շտկել։ Բայց հասկանալու համար, որ վթար է տեղի ունեցել, պետք է վերահսկել նախագիծը և արձագանքել միջադեպերին: Ինչպե՞ս դա անել:

Կարծում եմ, որ խնդիր կա մոնիտորինգի պատշաճ համակարգ կազմակերպելու հարցում։ Եթե ​​որևէ դժվարություն չլիներ, ապա իմ ելույթը բաղկացած կլիներ մեկ թեզից. «Խնդրում եմ տեղադրել Prometheus + Grafana և plugins 1, 2, 3»: Ցավոք, դա այլեւս այդպես չի աշխատում: Իսկ հիմնական խնդիրն այն է, որ բոլորը շարունակում են հավատալ մի բանի, որը կար 2008 թվականին՝ ծրագրային բաղադրիչների առումով։

Ինչ վերաբերում է մոնիթորինգի համակարգի կազմակերպմանը, ես համարձակվում եմ ասել, որ... իրավասու մոնիտորինգով նախագծեր գոյություն չունեն։ Եվ իրավիճակն այնքան վատ է, որ եթե ինչ-որ բան ընկնի, վտանգ կա, որ այն աննկատ կմնա, ի վերջո, բոլորը վստահ են, որ «ամեն ինչ վերահսկվում է»:
Երևի ամեն ինչ վերահսկվում է։ Բայց ինչպես?

Մենք բոլորս էլ հանդիպել ենք հետևյալ պատմության հետ. ինչ-որ devops, որոշակի ադմին է աշխատում, մշակողների թիմը գալիս է նրանց մոտ և ասում. «մենք ազատ ենք, հիմա մոնիտորինգ»: Ինչի՞ մոնիտորինգ: Ինչպես է դա աշխատում?

ԼԱՎ. Մենք վերահսկում ենք հին ձևով. Եվ դա արդեն փոխվում է, և պարզվում է, որ դուք վերահսկել եք A ծառայությունը, որը դարձել է ծառայություն B, որը փոխազդում է ծառայության C-ի հետ: Բայց մշակողների թիմն ասում է ձեզ.

Այսպիսով, ի՞նչ է փոխվել: - Ամեն ինչ փոխվել է!

2008 թ Ամեն ինչ լավ է

Կան մի քանի մշակող, մեկ սերվեր, մեկ տվյալների բազայի սերվեր: Ամեն ինչ այստեղից է գնում: Որոշ տեղեկություններ ունենք, տեղադրում ենք zabbix, Nagios, cacti: Եվ հետո մենք հստակ ազդանշաններ ենք սահմանում պրոցեսորի, սկավառակի աշխատանքի և սկավառակի տարածության վրա: Մենք նաև մի քանի ձեռքով ստուգումներ ենք անում՝ համոզվելու, որ կայքը արձագանքում է, և որ պատվերները հասնում են տվյալների բազա: Եվ վերջ. մենք քիչ թե շատ պաշտպանված ենք:

Եթե ​​համեմատենք ադմինիստրատորի աշխատանքի ծավալը մոնիտորինգ ապահովելու համար, ապա դրա 98%-ը ավտոմատ է եղել. մոնիտորինգ անողը պետք է հասկանա, թե ինչպես տեղադրել Zabbix-ը, ինչպես կարգավորել այն և կարգավորել ազդանշանները: Իսկ 2%՝ արտաքին ստուգումների համար. որ կայքը պատասխանում է և հարցում է անում տվյալների բազային, որ նոր պատվերներ են եկել։

2010 թ Բեռը մեծանում է

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

Ավելին, ենթակառուցվածքների հետ կապված կազմակերպությունը շարունակում է մնալ ամենամեծը կառավարչի գլխում: Իմ գլխում դեռ մի միտք կա, որ մոնիտորինգ անողն այն մարդն է, ով կտեղադրի zabbix-ը և կկարողանա կարգավորել այն։

Բայց միևնույն ժամանակ, աշխատանք է հայտնվում արտաքին ստուգումներ իրականացնելու, որոնման ինդեքսավորող հարցման սկրիպտների մի շարք ստեղծելու վրա, սկրիպտների մի շարք՝ ստուգելու, որ որոնումը փոխվում է ինդեքսավորման գործընթացում, սկրիպտների մի շարք, որոնք ստուգում են, որ ապրանքները փոխանցվում են առաքման ծառայություն և այլն։ եւ այլն։

Նշում. Ես գրել եմ «մի շարք սցենարներ» 3 անգամ: Այսինքն՝ մոնիտորինգի համար պատասխանատուն այլեւս պարզապես zabbix տեղադրողը չէ։ Սա մարդ է, ով սկսում է կոդավորել: Բայց թիմի մտքում դեռ ոչինչ չի փոխվել.

Բայց աշխարհը փոխվում է, դառնում ավելի ու ավելի բարդ: Ավելացվում է վիրտուալացման շերտ և մի քանի նոր համակարգեր: Նրանք սկսում են շփվել միմյանց հետ: Ո՞վ ասաց, որ «միկրոծառայությունների հոտ է գալիս»: Բայց յուրաքանչյուր ծառայություն, այնուամենայնիվ, առանձին-առանձին վեբկայքի տեսք ունի: Մենք կարող ենք դիմել դրան և հասկանալ, որ այն տրամադրում է անհրաժեշտ տեղեկատվություն և գործում է ինքնուրույն: Իսկ եթե դու ադմին ես, որը մշտապես ներգրավված է 5-7-10 տարի զարգացող նախագծում, ապա այս գիտելիքները կուտակվում են՝ հայտնվում է նոր մակարդակ՝ դու հասկացար, մեկ այլ մակարդակ՝ դու հասկացար...

Բայց հազվադեպ է, որ որևէ մեկը 10 տարի ուղեկցում է նախագծին:

Monitoringman-ի ռեզյումեն

Ենթադրենք, դուք եկել եք նոր ստարտափ, որն անմիջապես վարձել է 20 ծրագրավորող, գրել է 15 միկրոսերվիս, և դուք ադմին եք, ում ասվում է. «Կառուցեք CI/CD: Խնդրում եմ»։ Դուք կառուցել եք CI/CD և հանկարծ լսում եք. «Մեզ համար դժվար է աշխատել արտադրության հետ «խորանարդով»՝ չհասկանալով, թե հավելվածն ինչպես է աշխատելու դրանում։ Մեզ ավազատուփ դարձրեք նույն «խորանարդում»:
Այս խորանարդի մեջ դուք ավազատուփ եք պատրաստում: Նրանք անմիջապես ասում են ձեզ. «Մենք ուզում ենք բեմական տվյալների բազա, որը թարմացվում է ամեն օր արտադրությունից, որպեսզի հասկանանք, որ այն աշխատում է տվյալների բազայի վրա, բայց միևնույն ժամանակ չի փչացնում արտադրության տվյալների բազան»:

Դուք ապրում եք այս ամենի մեջ: Թողարկմանը 2 շաբաթ է մնացել, քեզ ասում են. «Հիմա եկեք վերահսկենք այս ամենը...»: Այսինքն. վերահսկել կլաստերային ենթակառուցվածքը, վերահսկել միկրոսերվիսային ճարտարապետությունը, վերահսկել աշխատանքը արտաքին ծառայությունների հետ...

Իսկ իմ գործընկերներն իրենց գլխից հանում են սովորական սխեման ու ասում. «Դե, այստեղ ամեն ինչ պարզ է։ Տեղադրեք մի ծրագիր, որը կվերահսկի այս ամենը»։ Այո, այո՝ Պրոմեթևս + Գրաֆանա + պլագիններ։
Եվ նրանք ավելացնում են. «Դուք ունեք երկու շաբաթ, համոզվեք, որ ամեն ինչ ապահով է»:

Շատ նախագծերում, որ մենք տեսնում ենք, մեկ հոգի է հատկացվում մոնիտորինգի համար։ Պատկերացրեք, որ ուզում ենք մարդուն աշխատանքի ընդունել 2 շաբաթով մոնիտորինգ անելու, նրա համար ռեզյումե ենք գրում։ Ի՞նչ հմտություններ պետք է ունենա այս մարդը՝ հաշվի առնելով այն ամենը, ինչ մենք ասել ենք մինչ այժմ:

• Նա պետք է հասկանա երկաթե ենթակառուցվածքի շահագործման մոնիտորինգն ու առանձնահատկությունները։
• Նա պետք է հասկանա Kubernetes-ի մոնիտորինգի առանձնահատկությունները (և բոլորն ուզում են գնալ «խորանարդ», քանի որ դուք կարող եք վերացվել ամեն ինչից, թաքնվել, քանի որ ադմինը կզբաղվի մնացածով) - ինքն իրեն, դրա ենթակառուցվածքը և հասկանա, թե ինչպես վերահսկել հավելվածները: ներսում։
• Նա պետք է հասկանա, որ ծառայությունները միմյանց հետ շփվում են հատուկ ձևերով, և իմանա այն առանձնահատկությունները, թե ինչպես են ծառայությունները փոխազդում միմյանց հետ: Միանգամայն հնարավոր է տեսնել մի նախագիծ, որտեղ որոշ ծառայություններ սինխրոն շփվում են, քանի որ այլ ճանապարհ չկա։ Օրինակ, backend-ը գնում է REST-ի միջոցով, gRPC-ի միջոցով կատալոգի ծառայություն, ստանում է ապրանքների ցանկը և հետ է վերադարձնում այն: Դուք չեք կարող սպասել այստեղ: Իսկ այլ ծառայությունների հետ այն աշխատում է ասինխրոն։ Պատվերը փոխանցեք առաքման ծառայությանը, նամակ ուղարկեք և այլն։
  Երևի արդեն լողացե՞լ եք այս ամենից: Եվ ադմինը, ով պետք է վերահսկի սա, ավելի շփոթվեց:
• Նա պետք է կարողանա ճիշտ պլանավորել և պլանավորել, քանի որ աշխատանքն ավելի ու ավելի է դառնում:
• Հետևաբար, նա պետք է ռազմավարություն ստեղծի ստեղծված ծառայությունից, որպեսզի հասկանա, թե ինչպես պետք է հատուկ վերահսկել այն: Նրան անհրաժեշտ է նախագծի ճարտարապետության և դրա զարգացման ըմբռնում + մշակման մեջ օգտագործվող տեխնոլոգիաների իմացություն:

Հիշենք մի բացարձակ նորմալ դեպք՝ որոշ ծառայություններ PHP-ում են, որոշ ծառայություններ՝ Go-ում, որոշ ծառայություններ՝ JS-ում։ Նրանք ինչ-որ կերպ աշխատում են միմյանց հետ: Այստեղից է գալիս «միկրոծառայություն» տերմինը. կան այնքան անհատական ​​համակարգեր, որ մշակողները չեն կարողանում հասկանալ նախագիծն ամբողջությամբ: Թիմի մի մասը գրում է ծառայություններ JS-ում, որոնք աշխատում են ինքնուրույն և չգիտեն, թե ինչպես է աշխատում համակարգի մնացած մասը: Մյուս մասը գրում է ծառայություններ Python-ում և չի խանգարում այլ ծառայությունների աշխատանքին, դրանք մեկուսացված են իրենց տարածքում։ Երրորդը PHP-ով ծառայություններ գրելն է կամ այլ բան:
Այս բոլոր 20 հոգին բաժանված են 15 ծառայության, և կա միայն մեկ ադմին, ով պետք է հասկանա այս ամենը։ Կանգ առեք մենք պարզապես բաժանեցինք համակարգը 15 միկրոծառայությունների, քանի որ 20 հոգի չեն կարողանում հասկանալ ամբողջ համակարգը:

Բայց դա ինչ-որ կերպ պետք է վերահսկվի...

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

Ի՞նչ ասեմ... Հյուսթոն, մենք խնդիրներ ունենք։

Ժամանակակից ծրագրային նախագծի մոնիտորինգն ինքնին ծրագրային նախագիծ է

Այն կեղծ համոզմունքից, որ մոնիտորինգը ծրագրային ապահովում է, մենք զարգացնում ենք հրաշքների հանդեպ հավատ: Բայց հրաշքներ, ավաղ, չեն լինում։ Դուք չեք կարող տեղադրել zabbix-ը և սպասել, որ ամեն ինչ կաշխատի: Իմաստ չկա Grafana-ն տեղադրել և հուսալ, որ ամեն ինչ լավ կլինի: Ժամանակի մեծ մասը կծախսվի ծառայությունների աշխատանքի և միմյանց հետ փոխգործակցության ստուգումների կազմակերպման վրա, ստուգելու, թե ինչպես են աշխատում արտաքին համակարգերը: Իրականում ժամանակի 90%-ը կծախսվի ոչ թե սցենարներ գրելու, այլ ծրագրային ապահովման մշակման վրա։ Եվ դրանով պետք է զբաղվի մի թիմ, որը հասկանում է նախագծի աշխատանքը:
Եթե ​​այս իրավիճակում մեկ մարդ նետվի մոնիտորինգի, ապա աղետ կլինի։ Ինչը տեղի է ունենում ամենուր:

Օրինակ, կան մի քանի ծառայություններ, որոնք միմյանց հետ շփվում են Կաֆկայի միջոցով։ Պատվերը եկավ, պատվերի մասին հաղորդագրություն ուղարկեցինք Կաֆկային։ Կա ծառայություն, որը լսում է պատվերի մասին տեղեկությունները և առաքում ապրանքները: Կա ծառայություն, որը լսում է պատվերի մասին տեղեկատվությունը և նամակ է ուղարկում օգտատիրոջը։ Եվ հետո հայտնվում են ավելի շատ ծառայություններ, և մենք սկսում ենք շփոթվել:

Եվ եթե դուք դա տալիս եք նաև ադմինիստրատորին և մշակողներին այն փուլում, երբ թողարկումից կարճ ժամանակ է մնացել, անձը պետք է հասկանա այս ամբողջ արձանագրությունը: Նրանք. Այս մասշտաբի նախագիծը զգալի ժամանակ է պահանջում, և դա պետք է հաշվի առնել համակարգի զարգացման մեջ:
Բայց շատ հաճախ, հատկապես ստարտափներում, տեսնում ենք, թե ինչպես է մոնիտորինգը հետաձգվում ավելի ուշ։ «Հիմա մենք Proof of Concept-ը կանենք, դրանով կգործարկենք, թող ընկնի, մենք պատրաստ ենք զոհաբերության։ Եվ հետո մենք կվերահսկենք այդ ամենը»: Երբ (կամ եթե) նախագիծը սկսում է գումար վաստակել, բիզնեսը ցանկանում է ավելացնել ավելի շատ հնարավորություններ, քանի որ այն սկսել է աշխատել, ուստի այն պետք է հետագա տարածվի: Եվ դուք գտնվում եք այն կետում, որտեղ դուք նախ պետք է վերահսկեք ամեն ինչ նախկինում, ինչը խլում է ոչ թե ժամանակի 1%-ը, այլ շատ ավելին: Եվ, ի դեպ, մոնիտորինգի համար ծրագրավորողներ կպահանջվեն, և ավելի հեշտ է նրանց թույլ տալ աշխատել նոր գործառույթների վրա: Արդյունքում գրվում են նոր հնարավորություններ, ամեն ինչ խճճվում է, և դու հայտնվել ես անվերջ փակուղում։

Այսպիսով, ինչպե՞ս վերահսկել նախագիծը՝ սկսած սկզբից, և ի՞նչ անել, եթե ստանաք նախագիծ, որը պետք է մոնիտորինգի ենթարկվի, բայց չգիտեք, թե որտեղից սկսել:

Նախ, դուք պետք է պլանավորեք.

Լիրիկական շեղում. շատ հաճախ դրանք սկսում են ենթակառուցվածքի մոնիտորինգից: Օրինակ, մենք ունենք Kubernetes: Սկսենք Prometheus-ի տեղադրմամբ Grafana-ով, տեղադրելով «խորանարդի» մոնիտորինգի համար նախատեսված պլագիններ: Ոչ միայն մշակողները, այլև ադմինիստրատորներն ունեն դժբախտ պրակտիկա. «Մենք կտեղադրենք այս փլագինը, բայց փլագինը հավանաբար գիտի, թե ինչպես դա անել»: Մարդիկ սիրում են սկսել ոչ թե կարևոր գործողություններից, այլ պարզից և պարզից: Իսկ ենթակառուցվածքի մոնիտորինգը հեշտ է:

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

Եթե ​​դուք սկսեք վերահսկել ենթակառուցվածքը, և ձեր հավելվածի հետնամասը դադարի արձագանքել, բոլոր օգտվողները կկորցնեն կապը բջջային հավելվածի հետ: Սխալ կհայտնվի: Կգան ձեզ մոտ և կասեն՝ «Հավելվածը չի աշխատում, ի՞նչ եք անում այստեղ»: - «Մենք դիտարկում ենք». - «Ինչպե՞ս եք վերահսկում, եթե չեք տեսնում, որ հավելվածը չի աշխատում»:

1. Կարծում եմ, որ դուք պետք է սկսեք մոնիտորինգը հենց օգտագործողի մուտքի կետից: Եթե ​​օգտատերը չի տեսնում, որ հավելվածն աշխատում է, դա այդպես է, դա ձախողում է: Եվ այս մասին նախ պետք է զգուշացնի մոնիտորինգի համակարգը։
2. Եվ միայն դրանից հետո մենք կարող ենք վերահսկել ենթակառուցվածքները: Կամ դա արեք զուգահեռ: Ենթակառուցվածքով ավելի հեշտ է. այստեղ մենք վերջապես կարող ենք պարզապես տեղադրել zabbix-ը:
3. Եվ հիմա դուք պետք է գնաք հավելվածի արմատներին, որպեսզի հասկանաք, թե որտեղ բաները չեն աշխատում:

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

Ամեն ինչ ըստ մակարդակների

Ես այսպես եմ տեսնում մոնիտորինգի համակարգի կազմակերպումը։

1) Կիրառման մակարդակ.

• կիրառման բիզնես տրամաբանության մոնիտորինգ;
• ծառայությունների առողջական ցուցանիշների մոնիտորինգ;
• ինտեգրման մոնիտորինգ:

2) Ենթակառուցվածքի մակարդակը.

• նվագախմբային մակարդակի մոնիտորինգ;
• համակարգի ծրագրային մոնիտորինգ;
• երկաթի մակարդակի մոնիտորինգ:

3) Կրկին կիրառման մակարդակը, բայց որպես ինժեներական արտադրանք.

• հավելվածների տեղեկամատյանների հավաքում և մոնիտորինգ;
• APM;
• հետագծում.

4) Զգուշացում.

• նախազգուշացման համակարգի կազմակերպում;
• հերթապահության կազմակերպում;
• միջադեպերի մշակման համար «գիտելիքների բազայի» և աշխատանքային գործընթացի կազմակերպում:

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

Application Layer - Business Logic Monitoring

Այստեղ մենք խոսում ենք հենց այն փաստի ստուգման մասին, որ հավելվածն աշխատում է օգտատիրոջ համար։

Այս մակարդակը պետք է կատարվի զարգացման փուլում: Օրինակ, մենք ունենք պայմանական Պրոմեթևս. այն գնում է սերվեր, որը կատարում է ստուգումները, քաշում է վերջնակետը, և վերջնակետը գնում և ստուգում է API-ն:

Երբ հաճախ խնդրում են վերահսկել գլխավոր էջը՝ համոզվելու համար, որ կայքը աշխատում է, ծրագրավորողները տալիս են բռնակ, որը կարելի է քաշել ամեն անգամ, երբ նրանք պետք է համոզվեն, որ API-ն աշխատում է: Իսկ ծրագրավորողները այս պահին դեռ վերցնում և գրում են /api/test/helloworld
Միակ միջոցը համոզվելու համար, որ ամեն ինչ աշխատում է: -Ոչ!

• Նման ստուգումների ստեղծումն ըստ էության ծրագրավորողների խնդիրն է։ Միավոր թեստերը պետք է գրեն կոդը գրող ծրագրավորողները: Որովհետև, եթե դուք այն արտահոսեք ադմինիստրատորին, «Ժողովուրդ, ահա API արձանագրությունների ցուցակը բոլոր 25 գործառույթների համար, խնդրում ենք վերահսկել ամեն ինչ»: - ոչինչ չի ստացվի:
• Եթե ​​տպեք «բարև աշխարհ», ոչ ոք երբեք չի իմանա, որ API-ն պետք է և աշխատում է: API-ի յուրաքանչյուր փոփոխություն պետք է հանգեցնի ստուգումների փոփոխության:
• Եթե ​​դուք արդեն ունեք նման խնդիր, դադարեցրեք գործառույթները և հատկացրեք մշակողներին, ովքեր կգրեն այս չեկերը, կամ ընդունեք կորուստները, ընդունեք, որ ոչինչ ստուգված չէ և չի հաջողվի:

Տեխնիկական խորհուրդներ.

• Համոզվեք, որ կազմակերպեք արտաքին սերվեր՝ ստուգումներ կազմակերպելու համար. դուք պետք է վստահ լինեք, որ ձեր նախագիծը հասանելի է արտաքին աշխարհին:
• Կազմակերպեք ստուգումներ ամբողջ API արձանագրության մեջ, ոչ միայն առանձին վերջնակետերում:
• Փորձարկման արդյունքներով ստեղծեք պրոմեթևս-վերջակետ:

Կիրառական շերտ - առողջության չափման մոնիտորինգ

Այժմ մենք խոսում ենք ծառայությունների արտաքին առողջության ցուցանիշների մասին:

Մենք որոշեցինք, որ մենք վերահսկում ենք հավելվածի բոլոր «բռնակները»՝ օգտագործելով արտաքին ստուգումներ, որոնք մենք կանչում ենք արտաքին մոնիտորինգի համակարգից: Բայց սրանք այն «բռնակներն» են, որոնք օգտատերը «տեսնում է»: Մենք ցանկանում ենք վստահ լինել, որ մեր ծառայություններն իրենք են աշխատում: Այստեղ ավելի լավ պատմություն կա. K8-ն ունի առողջական ստուգումներ, որպեսզի գոնե «խորանարդն» ինքը կարողանա համոզվել, որ ծառայությունն աշխատում է: Բայց իմ տեսած չեկերի կեսը նույն տպագիր «բարև աշխարհ» է: Նրանք. Այսպիսով, նա մեկ անգամ քաշում է տեղակայումից հետո, նա պատասխանեց, որ ամեն ինչ լավ է. Իսկ ծառայությունը, եթե այն տրամադրում է իր սեփական API-ն, ունի հսկայական քանակությամբ մուտքի կետեր այդ նույն API-ի համար, որը նույնպես պետք է մոնիտորինգի ենթարկվի, քանի որ մենք ուզում ենք իմանալ, որ այն աշխատում է: Իսկ ներսում մենք արդեն վերահսկում ենք։

Ինչպես դա ճիշտ իրականացնել տեխնիկապես. յուրաքանչյուր ծառայություն բացահայտում է իր ընթացիկ կատարողականի վերջնական կետը, և Grafana-ի (կամ որևէ այլ հավելվածի) գրաֆիկներում մենք տեսնում ենք բոլոր ծառայությունների կարգավիճակը:

• API-ի յուրաքանչյուր փոփոխություն պետք է հանգեցնի ստուգումների փոփոխության:
• Անմիջապես ստեղծեք նոր ծառայություն՝ հաշվի առնելով առողջության ցուցանիշները:
• Ադմինը կարող է գալ ծրագրավորողների մոտ և խնդրել «ավելացրեք ինձ մի քանի առանձնահատկություն, որպեսզի ես հասկանամ ամեն ինչ և այս մասին տեղեկատվություն ավելացնեմ իմ մոնիտորինգի համակարգում»: Բայց մշակողները սովորաբար պատասխանում են. «Մենք ոչինչ չենք ավելացնի թողարկումից երկու շաբաթ առաջ»:
  Թող զարգացման մենեջերները իմանան, որ նման կորուստներ են լինելու, թող իմանան զարգացման մենեջերների ղեկավարությունն էլ։ Որովհետև երբ ամեն ինչ ընկնում է, ինչ-որ մեկը դեռ կկանչի և կպահանջի վերահսկել «անընդհատ ընկնող ծառայությունը» (գ)
• Ի դեպ, հատկացրեք ծրագրավորողներին Grafana-ի համար պլագիններ գրելու համար, սա լավ օգնություն կլինի ադմինների համար:

Application Layer - Ինտեգրման մոնիտորինգ

Ինտեգրման մոնիտորինգը կենտրոնանում է բիզնեսի համար կարևոր համակարգերի միջև հաղորդակցությունների մոնիտորինգի վրա:

Օրինակ, կա 15 ծառայություն, որոնք շփվում են միմյանց հետ։ Սրանք այլևս առանձին կայքեր չեն: Նրանք. մենք չենք կարող ինքնուրույն դուրս բերել ծառայությունը, ստանալ /helloworld և հասկանալ, որ ծառայությունն աշխատում է: Քանի որ պատվիրող վեբ ծառայությունը պետք է պատվերի մասին տեղեկատվություն ուղարկի ավտոբուսին` ավտոբուսից, պահեստի ծառայությունը պետք է ստանա այս հաղորդագրությունը և հետագայում աշխատի դրա հետ: Եվ էլփոստի բաշխման ծառայությունը պետք է ինչ-որ կերպ վերամշակի դա և այլն:

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

Ինչ ես խորհուրդ եմ տալիս անել.

• Սինքրոն հաղորդակցության համար. վերջնակետը հարցումներ է կատարում հարակից ծառայություններին: Նրանք. մենք վերցնում ենք այս վերջնակետը, քաշում ենք սկրիպտը ծառայության ներսում, որը գնում է բոլոր կետերին և ասում է.
• Ասինխրոն հաղորդակցության համար. մուտքային հաղորդագրություններ - վերջնակետը ստուգում է ավտոբուսը թեստային հաղորդագրությունների համար և ցուցադրում մշակման կարգավիճակը:
• Ասինխրոն հաղորդակցության համար. ելքային հաղորդագրություններ - վերջնակետը փորձնական հաղորդագրություններ է ուղարկում ավտոբուսին:

Ինչպես սովորաբար լինում է. մենք ունենք ծառայություն, որը տվյալներ է նետում ավտոբուսի մեջ: Մենք գալիս ենք այս ծառայությանը և խնդրում ենք պատմել մեզ դրա ինտեգրման առողջության մասին: Եվ եթե ծառայությունը պետք է հաղորդագրություն թողարկի որևէ այլ տեղ (WebApp), ապա այն կստեղծի այս թեստային հաղորդագրությունը: Եվ եթե մենք գործարկենք ծառայությունը OrderProcessing կողմում, այն նախ տեղադրում է այն, ինչ կարող է տեղադրել անկախ, և եթե կան որոշ կախված բաներ, ապա նա կարդում է մի շարք թեստային հաղորդագրություններ ավտոբուսից, հասկանում է, որ կարող է մշակել դրանք, հաղորդել և հաղորդել: , եթե պետք է, տեղադրեք դրանք հետագա, և այս մասին նա ասում է՝ ամեն ինչ լավ է, ես ողջ եմ։

Շատ հաճախ մենք լսում ենք «ինչպե՞ս կարող ենք սա փորձարկել մարտական ​​տվյալների վրա» հարց: Օրինակ, խոսքը նույն պատվերի ծառայության մասին է։ Պատվերը հաղորդագրություններ է ուղարկում պահեստ, որտեղ ապրանքները դուրս են գրվում. մենք չենք կարող դա փորձարկել մարտական ​​տվյալների վրա, քանի որ «իմ ապրանքները դուրս կգան»: Լուծում. ի սկզբանե պլանավորեք այս ամբողջ թեստը: Դուք նաև ունեք միավոր թեստեր, որոնք ծաղրում են: Այսպիսով, արեք դա ավելի խորը մակարդակով, որտեղ դուք ունեք հաղորդակցման ալիք, որը չի վնասում բիզնեսի գործունեությանը:

Ենթակառուցվածքի մակարդակը

Ենթակառուցվածքների մոնիտորինգը մի բան է, որը վաղուց համարվում էր հենց մոնիտորինգ:

• Ենթակառուցվածքների մոնիտորինգը կարող է և պետք է գործարկվի որպես առանձին գործընթաց:
• Դուք չպետք է սկսեք ենթակառուցվածքի մոնիտորինգով ընթացիկ նախագծի վրա, նույնիսկ եթե իսկապես ցանկանում եք: Սա ցավ է բոլոր դավոցների համար։ «Սկզբում ես կհետևեմ կլաստերին, կհետևեմ ենթակառուցվածքին», այսինքն. Նախ, այն կվերահսկի այն, ինչ կա ստորև, բայց չի մտնի հավելվածի մեջ: Քանի որ հավելվածը devops-ի համար անհասկանալի բան է։ Այն արտահոսել է նրան, և նա չի հասկանում, թե ինչպես է դա աշխատում: Եվ նա հասկանում է ենթակառուցվածքն ու սկսում դրանից։ Բայց ոչ, դուք միշտ պետք է վերահսկեք դիմումը:
• Մի չափազանցեք զգուշացումների քանակով: Հաշվի առնելով ժամանակակից համակարգերի բարդությունը, ահազանգերը անընդհատ թռչում են, և դուք պետք է ինչ-որ կերպ ապրեք ահազանգերի այս փունջով: Եվ հերթապահը, նայելով հաջորդ հարյուրավոր ահազանգերին, կորոշի «Ես չեմ ուզում մտածել այդ մասին»: Զգուշացումները պետք է տեղեկացնեն միայն կարևոր բաների մասին:

Կիրառման մակարդակը որպես բիզնես միավոր

Հիմնական կետերը.

• ԵԼՔ. Սա արդյունաբերության ստանդարտն է: Եթե ​​ինչ-ինչ պատճառներով չեք հավաքում տեղեկամատյանները, անմիջապես սկսեք դա անել:
• APM. Արտաքին APM-ները որպես հավելվածների մոնիտորինգն արագ փակելու միջոց (NewRelic, BlackFire, Datadog): Դուք կարող եք ժամանակավորապես տեղադրել այս բանը, որպեսզի գոնե ինչ-որ կերպ հասկանաք, թե ինչ է կատարվում ձեզ հետ:
• Հետագծում. Տասնյակ միկրոսերվիսներում դուք պետք է հետևեք ամեն ինչին, քանի որ հարցումն այլևս ինքնուրույն չի ապրում: Ավելի ուշ ավելացնելը շատ դժվար է, ուստի ավելի լավ է անմիջապես պլանավորել հետագծումը զարգացման մեջ. սա մշակողների աշխատանքն ու օգտակարությունն է: Եթե ​​դեռ չեք իրականացրել, կիրառե՛ք այն։ Տես Jaeger/Zipkin

Զգուշացնող

• Ծանուցումների համակարգի կազմակերպում. մի շարք բաների մոնիտորինգի պայմաններում պետք է լինի ծանուցումներ ուղարկելու միասնական համակարգ։ Դուք կարող եք Grafana-ում: Արևմուտքում բոլորն օգտագործում են PagerDuty: Զգուշացումները պետք է հստակ լինեն (օր.՝ որտեղից են եկել...): Եվ նպատակահարմար է վերահսկել, որ ծանուցումներ ընդհանրապես ստացվեն
• Հերթապահության կազմակերպում. ահազանգեր չպետք է ուղարկվեն բոլորին (կամ բոլորը արձագանքելու են ամբոխի մեջ, կամ ոչ ոք չի արձագանքի): Մշակողները պետք է նաև պատրաստ լինեն. համոզվեք, որ սահմանեք պատասխանատվության ոլորտները, հստակ հրահանգներ կատարեք և գրեք, թե կոնկրետ ում զանգահարեն երկուշաբթի և չորեքշաբթի, և ում զանգահարեն երեքշաբթի և ուրբաթ օրերին (հակառակ դեպքում նրանք ոչ ոքի չեն զանգի նույնիսկ մեծ խնդրի իրադարձություն. նրանք կվախենան ձեզ արթնացնել կամ անհանգստացնել. մարդիկ հիմնականում չեն սիրում զանգահարել և արթնացնել այլ մարդկանց, հատկապես գիշերը): Եվ բացատրեք, որ օգնություն խնդրելը ոչ կոմպետենտության ցուցիչ չէ («Ես օգնություն եմ խնդրում, դա նշանակում է, որ ես վատ աշխատող եմ»), խրախուսեք օգնության խնդրանքները:
• Միջադեպի մշակման համար «գիտելիքների բազայի» և աշխատանքային հոսքի կազմակերպում. յուրաքանչյուր լուրջ միջադեպի համար պետք է նախատեսվի հետմահու, և որպես ժամանակավոր միջոց՝ արձանագրվեն միջադեպը կարգավորող գործողությունները: Եվ դարձրեք սովորություն, որ կրկնվող ահազանգերը մեղք են. դրանք պետք է ամրագրվեն կոդի կամ ենթակառուցվածքի աշխատանքներում:

Տեխնոլոգիաների բուրգ

Եկեք պատկերացնենք, որ մեր ստեկը հետևյալն է.

• տվյալների հավաքագրում - Պրոմեթևս + Գրաֆանա;
• տեղեկամատյանների վերլուծություն - ELK;
• APM-ի կամ Tracing-ի համար - Jaeger (Zipkin):

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

Մի քանի տեխնիկական կետեր, որոնք ես տեսնում եմ ամենուր վերջերս.

Պրոմեթևսը մղվում է Կուբերնետեսի ներսում. ո՞վ է դա մտածել: Եթե ​​ձեր կլաստերը խափանվի, ի՞նչ եք անելու: Եթե ​​ներսում ունեք բարդ կլաստեր, ապա պետք է լինի կլաստերի ներսում ինչ-որ մոնիտորինգի համակարգ, իսկ դրսում մի քանիսը, որը տվյալներ կհավաքի կլաստերի ներսից:

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

Արդյունքները

• Մոնիտորինգի մշակումը ոչ թե կոմունալ ծառայությունների տեղադրումն է, այլ ծրագրային արտադրանքի մշակումը: Այսօրվա մոնիտորինգի 98%-ը կոդավորումն է: Ծառայություններում կոդավորում, արտաքին ստուգումների կոդավորում, արտաքին ծառայությունների ստուգում, և այս ամենը:
• Մի վատնեք ձեր ծրագրավորողների ժամանակը մոնիտորինգի վրա. դա կարող է խլել նրանց աշխատանքի մինչև 30%-ը, բայց արժե այն:
• Դևոփս, մի ​​անհանգստացեք, որ չեք կարող որևէ բան վերահսկել, քանի որ որոշ բաներ բոլորովին այլ մտածելակերպ են: Դուք ծրագրավորող չեք եղել, և մոնիտորինգի աշխատանքը հենց նրանց գործն է։
• Եթե ​​նախագիծն արդեն գործում է և չի վերահսկվում (և դուք մենեջեր եք), հատկացրեք ռեսուրսներ մոնիտորինգի համար:
• Եթե ​​ապրանքն արդեն արտադրվում է, և դուք դևոպ եք, ում ասվել է «մոնիտորինգ կարգավորել», փորձեք ղեկավարությանը բացատրել, թե ինչի մասին եմ գրել այս ամենը:

Սա Saint Highload++ կոնֆերանսի զեկույցի ընդլայնված տարբերակն է:

Եթե ​​ձեզ հետաքրքրում են իմ գաղափարներն ու մտքերը դրա և հարակից թեմաների վերաբերյալ, ապա այստեղ կարող եք կարդալ ալիքը 🙂

Source: www.habr.com