Թանոս - ընդլայնելի Պրոմեթևս

Հոդվածի թարգմանությունը պատրաստվել է հատուկ դասընթացի ուսանողների համար «DevOps պրակտիկա և գործիքներ».

Ֆաբիան Ռեյնարց ծրագրավորող է, Go fanatic և խնդիրներ լուծող: Նա նաև Պրոմեթևսի սպասարկող է և Kubernetes SIG գործիքավորման համահիմնադիր: Նախկինում նա արտադրության ինժեներ էր SoundCloud-ում և ղեկավարում էր CoreOS-ի մոնիտորինգի թիմը: Ներկայումս աշխատում է Google-ում։

Բարտեկ Պլոտկա - Ենթակառուցվածքի ինժեներ անհավանականում: Նա հետաքրքրված է նոր տեխնոլոգիաներով և բաշխված համակարգերի խնդիրներով։ Նա ցածր մակարդակի ծրագրավորման փորձ ունի Intel-ում, ներդրումային փորձ Mesos-ում և համաշխարհային կարգի SRE արտադրության փորձ Improbable-ում: Նվիրված է միկրոծառայությունների աշխարհի բարելավմանը: Նրա երեք սերերը՝ Գոլանգ, բաց կոդով և վոլեյբոլ։

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

Պրոմեթևսի պարզությունն ու հուսալիությունը նրա հիմնական առավելություններից մեկն է: Այնուամենայնիվ, երբ մենք անցանք որոշակի սանդղակի, մենք հանդիպեցինք մի քանի թերությունների: Այս խնդիրները լուծելու համար մենք մշակել ենք Թանոսը բաց կոդով նախագիծ է, որը ստեղծվել է Improbable-ի կողմից՝ գոյություն ունեցող Պրոմեթևսի կլաստերներն անխափան կերպով վերափոխելու մեկ մոնիտորինգի համակարգի՝ անսահմանափակ պատմական տվյալների պահպանմամբ: Thanos-ը հասանելի է Github-ում այստեղ.

Եղեք տեղեկացված Improbable-ի վերջին նորություններին:

Մեր նպատակները Թանոսի հետ

Որոշակի մասշտաբով խնդիրներ են առաջանում, որոնք դուրս են վանիլային Պրոմեթևսի հնարավորություններից։ Ինչպե՞ս հուսալի և տնտեսապես պահպանել պատմական տվյալներ petabytes: Կարո՞ղ է դա անել առանց արձագանքման ժամանակի զիջման: Հնարավո՞ր է արդյոք մեկ API հարցումով մուտք գործել Prometheus-ի տարբեր սերվերների վրա տեղակայված բոլոր չափումները: Արդյո՞ք Prometheus HA-ի միջոցով հավաքագրված կրկնօրինակված տվյալները միավորելու որևէ միջոց կա:

Այս խնդիրները լուծելու համար մենք ստեղծեցինք Thanos-ը: Հետևյալ բաժինները նկարագրում են, թե ինչպես ենք մենք մոտեցել այս խնդիրներին և բացատրում ենք մեր նպատակները:

Տվյալների հարցում Պրոմեթևսի բազմաթիվ օրինակներից (գլոբալ հարցում)

Պրոմեթևսն առաջարկում է ֆունկցիոնալ մոտեցում շարդինգին: Նույնիսկ մեկ Prometheus սերվերն ապահովում է բավականաչափ մասշտաբայնություն՝ օգտատերերին գրեթե բոլոր օգտագործման դեպքերում ազատելու հորիզոնական բեկորների բարդություններից:

Թեև սա տեղակայման հիանալի մոդել է, հաճախ անհրաժեշտ է մուտք գործել տարբեր Prometheus սերվերների տվյալները մեկ API-ի կամ UI-ի միջոցով՝ գլոբալ տեսքի: Իհարկե, հնարավոր է մի քանի հարցումներ ցուցադրել մեկ Grafana վահանակում, սակայն յուրաքանչյուր հարցում կարող է իրականացվել միայն մեկ Prometheus սերվերի վրա: Մյուս կողմից, Thanos-ի հետ դուք կարող եք հարցումներ կատարել և համախմբել տվյալներ բազմաթիվ Prometheus սերվերներից, քանի որ դրանք բոլորը հասանելի են մեկ վերջնական կետից:

Նախկինում «Անհավանական» տարբերակում գլոբալ տեսակետ ստանալու համար մենք մեր Պրոմեթևսի օրինակները կազմակերպեցինք բազմամակարդակ Հիերարխիկ ֆեդերացիա. Սա նշանակում էր ստեղծել մեկ Prometheus մետա-սերվեր, որը հավաքում է որոշ չափումներ յուրաքանչյուր թերթիկի սերվերից:

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

Սրա հետ սերտորեն կապված է բարձր հասանելիության (HA) Prometheus սերվերների վրա հավաքված տվյալների միասնական տեսակետը: Պրոմեթևսի HA մոդելը երկու անգամ ինքնուրույն հավաքում է տվյալներ, ինչը այնքան պարզ է, որ ավելի պարզ չի կարող լինել: Այնուամենայնիվ, երկու հոսքերի համակցված և կրկնօրինակված տեսքի օգտագործումը շատ ավելի հարմար կլինի:

Իհարկե, Պրոմեթևսի բարձր հասանելի սերվերների կարիք կա: Improbable-ում մենք իսկապես լուրջ ենք վերաբերվում րոպե առ րոպե տվյալների մոնիտորինգին, բայց Պրոմեթևսի մեկ օրինակ ունենալը մեկ կլաստերի համար միայն ձախողման կետ է: Կազմաձևման ցանկացած սխալ կամ ապարատային ձախողում կարող է հանգեցնել կարևոր տվյալների կորստի: Նույնիսկ պարզ տեղակայումը կարող է չնչին խանգարումներ առաջացնել չափումների հավաքագրման մեջ, քանի որ վերագործարկումը կարող է զգալիորեն ավելի երկար լինել, քան քերման միջակայքը:

Պատմական տվյալների հուսալի պահպանում

Էժան, արագ, երկարաժամկետ չափումների պահպանումը մեր երազանքն է (այն կիսում են Պրոմեթևսի օգտատերերի մեծ մասը): Անհավանականում մենք ստիպված եղանք կարգավորել չափումների պահպանման ժամկետը մինչև ինը օր (Պրոմեթևս 1.8-ի համար): Սա ակնհայտ սահմաններ է ավելացնում, թե որքան հեռու կարող ենք նայել:

Պրոմեթևս 2.0-ն այս առումով բարելավվել է, քանի որ ժամանակային շարքերի քանակն այլևս չի ազդում սերվերի ընդհանուր աշխատանքի վրա (տես. KubeCon-ի հիմնական ելույթը Պրոմեթևս 2-ի մասին) Այնուամենայնիվ, Պրոմեթևսը տվյալները պահում է տեղական սկավառակի վրա: Թեև տվյալների բարձր արդյունավետության սեղմումը կարող է զգալիորեն նվազեցնել SSD-ի տեղական օգտագործումը, այնուամենայնիվ, ի վերջո, դեռևս կա սահմանափակում պատմական տվյալների քանակի համար, որոնք կարող են պահպանվել:

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

Նվազեցում

Երբ մենք սկսեցինք աշխատել պատմական տվյալների հետ, մենք հասկացանք, որ big-O-ի հետ կապված հիմնարար դժվարություններ կան, որոնք հարցումներն ավելի ու ավելի դանդաղ են դարձնում, քանի որ մենք աշխատում ենք շաբաթների, ամիսների և տարիների տվյալների հետ:

Այս խնդրի ստանդարտ լուծումը կլինի նվազեցման նմուշառում (նմուշառում) - ազդանշանի նմուշառման հաճախականության նվազում: Նվազեցման դեպքում մենք կարող ենք «նվազեցնել» մինչև ավելի մեծ ժամանակային տիրույթ և պահպանել նույն թվով նմուշներ՝ հարցումները արձագանքելով:

Հին տվյալների կրճատումը երկարաժամկետ պահպանման ցանկացած լուծման անխուսափելի պահանջ է և դուրս է վանիլային Պրոմեթևսի շրջանակներից:

Լրացուցիչ նպատակներ

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

Թանոսի ճարտարապետությունը

Նախորդ բաժնում մեր նպատակները թվարկելուց հետո, եկեք աշխատենք դրանց միջոցով և տեսնենք, թե Թանոսը ինչպես է լուծում այս խնդիրները:

Համաշխարհային տեսակետ

Պրոմեթևսի գոյություն ունեցող օրինակների վրա գլոբալ տեսք ստանալու համար մենք պետք է կապենք մեկ հարցման մուտքի կետ բոլոր սերվերներին: Սա հենց այն է, ինչ անում է Thanos բաղադրիչը: Սիդեկար. Այն տեղակայված է յուրաքանչյուր Պրոմեթևսի սերվերի կողքին և հանդես է գալիս որպես վստահված անձ՝ սպասարկելով տեղական Prometheus տվյալները gRPC Store API-ի միջոցով՝ թույլ տալով ժամանակային շարքերի տվյալները առբերել ըստ պիտակների և ժամանակային միջակայքի:

Մյուս կողմում մասշտաբային, քաղաքացիություն չունեցող Querier բաղադրիչն է, որն ավելին է անում, քան պարզապես պատասխանում է PromQL հարցումներին ստանդարտ Prometheus HTTP API-ի միջոցով: Querier-ը, Sidecar-ը և Thanos-ի այլ բաղադրիչները հաղորդակցվում են միջոցով բամբասանքի արձանագրություն.

1. Querier-ը հարցում ստանալուց հետո միանում է համապատասխան Store API սերվերին, այսինքն՝ մեր Sidecars-ին և ստանում ժամանակային շարքի տվյալներ համապատասխան Prometheus սերվերներից։
2. Դրանից հետո այն միավորում է պատասխանները և դրանց վրա կատարում PromQL հարցում: Querier-ը կարող է միաձուլել ինչպես տարանջատված տվյալները, այնպես էլ կրկնօրինակ տվյալները Prometheus HA սերվերներից:

Սա լուծում է մեր գլուխկոտրուկի հիմնական մասը՝ միավորելով Prometheus-ի մեկուսացված սերվերների տվյալները մեկ դիտման մեջ: Փաստորեն, Thanos-ը կարող է օգտագործվել միայն այս ֆունկցիայի համար: Պրոմեթևսի գոյություն ունեցող սերվերներում փոփոխություններ պետք չէ կատարել:

Անսահմանափակ պահպանման ժամկետ:

Այնուամենայնիվ, վաղ թե ուշ մենք կցանկանանք պահպանել տվյալներ Պրոմեթևսի պահպանման սովորական ժամանակից դուրս: Մենք ընտրեցինք օբյեկտների պահեստավորում՝ պատմական տվյալները պահելու համար: Այն լայնորեն հասանելի է ցանկացած ամպի, ինչպես նաև ներկառուցված տվյալների կենտրոններում և շատ ծախսարդյունավետ է: Բացի այդ, գրեթե ցանկացած օբյեկտի պահեստավորում հասանելի է հայտնի S3 API-ի միջոցով:

Պրոմեթևսը տվյալների RAM-ից սկավառակ է գրում մոտավորապես երկու ժամը մեկ: Պահված տվյալների բլոկը պարունակում է բոլոր տվյալները ֆիքսված ժամանակահատվածի համար և անփոփոխ է: Սա շատ հարմար է, քանի որ Thanos Sidecar-ը կարող է պարզապես նայել Prometheus տվյալների գրացուցակը և, երբ նոր բլոկները հասանելի են դառնում, դրանք բեռնում է օբյեկտների պահեստավորման դույլերում:

Սկավառակի վրա գրելուց անմիջապես հետո օբյեկտների պահեստում բեռնելը նաև թույլ է տալիս պահպանել քերիչի պարզությունը (Prometheus և Thanos Sidecar): Ինչը հեշտացնում է աջակցությունը, ծախսերը և համակարգի ձևավորումը:

Ինչպես տեսնում եք, տվյալների կրկնօրինակումը շատ պարզ է: Բայց ի՞նչ կասեք օբյեկտների պահեստում տվյալների հարցումների մասին:

Thanos Store բաղադրիչը գործում է որպես պրոքսի` օբյեկտների պահեստից տվյալներ ստանալու համար: Ինչպես Thanos Sidecar-ը, այն մասնակցում է բամբասանքների կլաստերին և իրականացնում Store API-ը: Այսպիսով, գոյություն ունեցող Querier-ը կարող է այն վերաբերվել ինչպես Sidecar-ի, որպես ժամանակային շարքերի տվյալների մեկ այլ աղբյուր. հատուկ կոնֆիգուրացիա չի պահանջվում:

Ժամանակային շարքի տվյալների բլոկները բաղկացած են մի քանի խոշոր ֆայլերից: Դրանք ըստ պահանջի բեռնելը բավականին անարդյունավետ կլինի, իսկ տեղային քեշավորումը կպահանջի հսկայական հիշողություն և սկավառակի տարածություն:

Փոխարենը, Store Gateway-ը գիտի, թե ինչպես վարվել Prometheus պահեստավորման ձևաչափի հետ: Հարցումների խելացի ժամանակացույցի և բլոկների միայն անհրաժեշտ ինդեքսային մասերի քեշավորման շնորհիվ հնարավոր է կրճատել բարդ հարցումները մինչև HTTP հարցումների նվազագույն քանակ՝ պահեստավորման ֆայլերը առարկելու համար: Այսպիսով, դուք կարող եք կրճատել հարցումների քանակը չորսից վեց կարգով և հասնել պատասխանի ժամանակների, որոնք ընդհանուր առմամբ դժվար է տարբերակել տեղական SSD-ի հարցումներից մինչև տվյալներ:

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

Սեղմում և կրճատում

Երբ ժամանակային շարքի տվյալների նոր բլոկը հաջողությամբ բեռնվում է օբյեկտների պահեստում, մենք այն վերաբերվում ենք որպես «պատմական» տվյալների, որոնք անմիջապես հասանելի են Store Gateway-ի միջոցով:

Այնուամենայնիվ, որոշ ժամանակ անց բլոկները մեկ աղբյուրից (Prometheus with Sidecar) կուտակվում են և այլևս չեն օգտագործում ինդեքսավորման ամբողջ ներուժը: Այս խնդիրը լուծելու համար մենք ներկայացրեցինք մեկ այլ բաղադրիչ, որը կոչվում է Compactor: Այն պարզապես կիրառում է Պրոմեթևսի տեղական սեղմման շարժիչը օբյեկտների պահպանման պատմական տվյալների վրա և կարող է գործարկվել որպես պարզ պարբերական խմբաքանակի աշխատանք:

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

Տվյալների նմուշառման համար Compactor-ը շարունակաբար համախմբում է տվյալները հինգ րոպե և մեկ ժամ լուծաչափով: TSDB XOR սեղմման միջոցով կոդավորված յուրաքանչյուր չմշակված կտորի համար պահվում են տարբեր տեսակի համախառն տվյալներ, ինչպիսիք են նվազագույնը, առավելագույնը կամ գումարը մեկ բլոկի համար: Սա Querier-ին թույլ է տալիս ավտոմատ կերպով ընտրել ագրեգատ, որը համապատասխանում է տվյալ PromQL հարցմանը:

Ոչ մի հատուկ կոնֆիգուրացիա չի պահանջվում, որպեսզի օգտագործողը օգտագործի կրճատված ճշգրիտ տվյալներ: Querier-ը ավտոմատ կերպով անցնում է տարբեր լուծաչափերի և չմշակված տվյալների միջև, երբ օգտվողը մեծացնում և փոքրացնում է: Ցանկության դեպքում օգտվողը կարող է վերահսկել դա ուղղակիորեն հարցումի «քայլ» պարամետրի միջոցով:

Քանի որ մեկ ԳԲ-ի պահպանման արժեքը ցածր է, Thanos-ը լռելյայն պահպանում է չմշակված տվյալները, հինգ րոպեանոց և մեկ ժամ լուծաչափի տվյալները: Բնօրինակ տվյալները ջնջելու կարիք չկա։

Ձայնագրման կանոններ

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

• Համաշխարհային ծանուցում և կանոն (օրինակ՝ ահազանգ, երբ ծառայությունը չի աշխատում երեք կլաստերներից ավելի երկուսի վրա):
• Տեղական պահեստից դուրս տվյալների կանոն:
• Բոլոր կանոններն ու զգուշացումները մեկ տեղում պահելու ցանկություն:

Այս բոլոր դեպքերի համար Thanos-ը ներառում է առանձին բաղադրիչ, որը կոչվում է Ruler, որը հաշվարկում է կանոնն ու զգուշացումը Thanos Queries-ի միջոցով: Տրամադրելով հայտնի StoreAPI՝ Query հանգույցը կարող է մուտք գործել նոր հաշվարկված չափումներ: Հետագայում դրանք նույնպես պահվում են օբյեկտների պահեստում և հասանելի են դառնում Store Gateway-ի միջոցով:

Թանոսի ուժը

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

1. Ավելացրեք Thanos Sidecar-ը ձեր Prometheus սերվերներին, օրինակ՝ կողային բեռնարկղը Kubernetes-ի պատիճում:
2. Տեղադրեք Thanos Querier-ի բազմաթիվ կրկնօրինակներ, որպեսզի կարողանաք դիտել տվյալները: Այս փուլում հեշտ է բամբասանք ստեղծել Scraper-ի և Querier-ի միջև: Բաղադրիչների փոխազդեցությունը ստուգելու համար օգտագործեք «thanos_cluster_members» չափանիշը:

Միայն այս երկու քայլերը բավական են՝ ապահովելու գլոբալ դիտում և տվյալների անխափան հեռացում պոտենցիալ Պրոմեթևսի HA կրկնօրինակներից: Պարզապես միացրեք ձեր վահանակները Querier HTTP վերջնակետին կամ ուղղակիորեն օգտագործեք Thanos UI-ը:

Այնուամենայնիվ, եթե Ձեզ անհրաժեշտ է չափումների կրկնօրինակում և երկարաժամկետ պահեստավորում, դուք պետք է կատարեք ևս երեք քայլ.

1. Ստեղծեք AWS S3 կամ GCS դույլ: Կարգավորեք Sidecar-ը, որպեսզի պատճենի տվյալները այս դույլերում: Տեղական տվյալների պահպանումն այժմ կարելի է նվազագույնի հասցնել:
2. Տեղադրեք Store Gateway-ը և միացրեք այն ձեր գոյություն ունեցող բամբասանքների կլաստերին: Այժմ կարող եք հարցումներ կատարել պահուստավորված տվյալների վրա:
3. Տեղադրեք Compactor-ը՝ երկար ժամանակով բարելավելու հարցումների արդյունավետությունը՝ օգտագործելով սեղմման և կրճատման նմուշառումը:

Եթե ​​ցանկանում եք ավելին իմանալ, մի հապաղեք դիտել մեր կայքը kubernetes մանիֆեստի օրինակներ и սկսել!

Ընդամենը հինգ քայլով մենք Պրոմեթևսը վերածեցինք հուսալի մոնիտորինգի համակարգի՝ գլոբալ տեսարանով, պահեստավորման անսահմանափակ ժամանակով և չափումների հնարավոր բարձր հասանելիությամբ:

Քաշեք հարցումը. մենք ձեր կարիքն ունենք:

Թանոսը հենց սկզբից եղել է բաց կոդով նախագիծ: Prometheus-ի հետ անխափան ինտեգրումը և Thanos-ի միայն մի մասը օգտագործելու հնարավորությունը այն դարձնում է հիանալի ընտրություն ձեր մոնիտորինգի համակարգը առանց ջանքերի չափելու համար:

Մենք միշտ ողջունում ենք GitHub Pull հարցումները և խնդիրները: Միևնույն ժամանակ, ազատ զգալ կապվեք մեզ հետ Github Issues-ի կամ Slack-ի միջոցով Անհավանական-eng #thanosեթե ունեք հարցեր կամ կարծիքներ, կամ ցանկանում եք կիսվել ձեր փորձով այն օգտագործելու համար: Եթե ​​ձեզ դուր է գալիս այն, ինչ մենք անում ենք Improbable-ում, մի հապաղեք կապվել մեզ հետ. մենք միշտ ունենք թափուր աշխատատեղեր!

Իմացեք ավելին դասընթացի մասին:

Source: www.habr.com