Բարեւ բոլորին. Ստորև ներկայացնում ենք սղագրությունը .
– տարբեր համակարգերի և ծառայությունների մոնիտորինգի համակարգ, որի օգնությամբ համակարգի ադմինիստրատորները կարող են տեղեկություններ հավաքել համակարգերի ընթացիկ պարամետրերի մասին և կարգավորել ազդանշաններ՝ համակարգերի շահագործման ընթացքում շեղումների մասին ծանուցումներ ստանալու համար:
Զեկույցը կներառի համեմատություն и — Պրոմեթևսի չափումների երկարաժամկետ պահպանման նախագծեր:
Նախ, ես ձեզ կպատմեմ Պրոմեթևսի մասին: Սա մոնիտորինգի համակարգ է, որը հավաքում է չափումներ նշված թիրախներից և պահում դրանք տեղական պահեստում: Պրոմեթևսը կարող է չափումներ գրանցել հեռավոր պահեստում և կարող է առաջացնել ազդանշաններ և ձայնագրման կանոններ:
Պրոմեթևսի սահմանափակումները.
- Այն չունի գլոբալ հարցման տեսք: Սա այն դեպքում, երբ դուք ունեք Պրոմեթևսի բազմաթիվ անկախ դեպքեր: Նրանք հավաքում են չափումներ: Եվ դուք ցանկանում եք հարցում կատարել այս բոլոր ցուցանիշների վերևում, որոնք հավաքվել են Պրոմեթևսի տարբեր օրինակներից: Պրոմեթևսը դա թույլ չի տալիս։
- Պրոմեթևսի հետ աշխատանքը սահմանափակվում է միայն մեկ սերվերով: Պրոմեթևսը ինքնաբերաբար չի տարածվում բազմաթիվ սերվերների վրա: Դուք կարող եք միայն ձեռքով բաժանել ձեր թիրախները մի քանի Պրոմեթևսի միջև:
- Պրոմեթևսի չափումների շրջանակը սահմանափակվում է ընդամենը մեկ սերվերով նույն պատճառով, որ այն չի կարող ավտոմատ կերպով մասշտաբավորվել մի քանի սերվերների վրա:
- Պրոմեթևսում տվյալների անվտանգությունը կազմակերպելն այնքան էլ հեշտ չէ։
Այս խնդիրների/մարտահրավերների լուծումները:
Լուծումներն են.
Այս բոլոր լուծումները նախատեսված են Պրոմեթևսի կողմից հավաքագրված տվյալների հեռավոր պահպանման համար: Նրանք տարբեր կերպ են լուծում նախորդ սլայդից հեռավոր պահեստավորման խնդիրը: Այս շնորհանդեսում ես կխոսեմ միայն առաջին երկու լուծումների մասին. и .
Առաջին անգամ տեղեկություններ հայտնվել է . Այնտեղ նկարագրված է ճարտարապետությունը և ինչպես է այն աշխատում:
Թանոսը վերցնում է Պրոմեթևսի պահած տվյալները տեղական սկավառակի վրա և պատճենում S3-ում, որպեսզի կամ մեկ այլ օբյեկտի պահեստ:
Այսպիսով, Thanos-ը տրամադրում է հարցումների գլոբալ տեսք: Դուք կարող եք հարցումներ կատարել օբյեկտների պահեստում պահվող տվյալներին Պրոմեթևսի բազմաթիվ օրինակներից:
Thanos-ն աջակցում է PromQL-ին և .
Thanos-ն օգտագործում է Պրոմեթևսի կոդը տվյալների պահպանման համար:
Thanos-ը մշակվել է նույն մշակողների կողմից, ինչ Պրոմեթևսը:
Մոտ : Այստեղ , որտեղ առաջին անգամ խոսեցինք .
VictoriaMetrics-ը տվյալներ է ստանում մի քանի պրոմեթևից Պրոմեթևսի կողմից աջակցվող արձանագրություն:
VictoriaMetrics-ը տրամադրում է հարցումների գլոբալ տեսք, քանի որ Prometheus-ի մի քանի օրինակներ կարող են տվյալներ գրել VictoriaMetrics-ում: Համապատասխանաբար, դուք կարող եք հարցումներ կատարել այս բոլոր տվյալների վերաբերյալ:
VictoriaMetrics-ն աջակցում է նաև Thanos-ի, PromQL-ի և Prometheus-ի հարցումների API-ին:
Ի տարբերություն Thanos-ի, VictoriaMetrics-ի սկզբնական կոդը գրված է զրոյից և օպտիմիզացված է արագության և ռեսուրսների սպառման համար:
VictoriaMetrics-ը, ի տարբերություն Thanos-ի, մասշտաբում է ինչպես ուղղահայաց, այնպես էլ հորիզոնական: Ուտել , որը մասշտաբով ուղղահայաց է: Դուք կարող եք սկսել մեկ պրոցեսորով և 1 ԳԲ հիշողությամբ և աստիճանաբար աճել մինչև հարյուրավոր պրոցեսորներ և 1 ՏԲ հիշողություն: VictoriaMetrics-ը կարող է օգտագործել այս բոլոր ռեսուրսները: Դրա կատարումը կավելանա մոտ 100 անգամ՝ համեմատած 1 միջուկային համակարգի հետ:
Thanos-ի պատմությունը սկսվել է 2017 թվականի նոյեմբերին, երբ հայտնվեց առաջին հանրային պարտավորությունը։ Մինչ այս Thanos-ը մշակվել էր ներքին կարգով .
2019 թվականի հունիսին եղավ 0.5.0-ի կարևոր թողարկում, որում արձանագրություն։ Նրան հեռացրել են Թանոսից, քանի որ լավ հանդես չի եկել։ Հաճախ Thanos կլաստերը ճիշտ չէր աշխատում, բամբասանքների արձանագրության պատճառով նրան սխալ միացված հանգույցները։ Ուստի որոշեցինք նրան հեռացնել այնտեղից։ Կարծում եմ՝ սա ճիշտ որոշում է։
Նույն 2019 թվականի հունիսին ուղարկել են դիմումի համարը в .
Եվ մի երկու ամիս հետո Թանոսին ընդունեցին , որը ներառում է Prometheus, Kubernetes և այլ հայտնի նախագծեր։
2018 թվականի հունվարին սկսվեց VictoriaMetrics-ի զարգացումը։
2018 թվականի սեպտեմբերին ես առաջին անգամ հրապարակայնորեն հիշատակեցի VictoriaMetrics-ը։
2018 թվականի դեկտեմբերին հրապարակվել է մեկ հանգույցի տարբերակը։
Մայիսին, 2019- ը ինչպես մեկ հանգույցի, այնպես էլ կլաստերային տարբերակների աղբյուրները:
2019 թվականի հունիսին, ինչպես Թանոսը, մենք դիմում ենք ներկայացրել CNCF հիմնադրամին համարով . Մենք դիմել ենք Թանոսի դիմումից մեկ օր առաջ։
Բայց, ցավոք, մեզ դեռ այնտեղ չեն ընդունել։ Անհրաժեշտ է համայնքի օգնություն:
Եկեք նայենք Thanos-ի և VictoriaMetrics-ի ճարտարապետությունը ցուցադրող ամենակարևոր սլայդներին:
Սկսենք Թանոսից։ Դեղին բաղադրիչները Պրոմեթևսի բաղադրիչներն են: Մնացած ամեն ինչ Thanos-ի բաղադրիչներն են: Սկսենք ամենակարևոր բաղադրիչից. Thanos Sidecar-ը բաղադրիչ է, որը տեղադրված է յուրաքանչյուր Պրոմեթևսի կողքին: Այն բեռնում է Prometheus-ի տվյալները տեղական պահեստից S3 կամ այլ օբյեկտների պահեստում:
Կա նաև Thanos Store Gateway կոչվող բաղադրիչ, որը կարող է կարդալ այս տվյալները Object Storage-ից Thanos Query-ի մուտքային հարցումների դեպքում: Thanos Query-ն իրականացնում է PromQL և Prometheus API: Այսինքն՝ արտաքինից այն նման է Պրոմեթևսին։ Ստանում է PromQL հարցումներ, ուղարկում դրանք Thanos Store Gateway-ին, Thanos Store Gateway-ը առբերում է անհրաժեշտ տվյալները Object Storage-ից և հետ է ուղարկում:
Բայց մենք տվյալները Object Storage-ում պահում ենք առանց վերջին երկու ժամի՝ Thanos Sidecar-ի ներդրման առանձնահատկությունների պատճառով, որը չի կարող վերջին երկու ժամը վերբեռնել Object Storage S3-ում, քանի որ Պրոմեթևսը դեռ չի ստեղծել ֆայլեր այս երկու ժամվա համար տեղական պահեստում:
Ինչպե՞ս որոշեցիք շրջանցել սա: Thanos Query-ը, բացի Thanos Store Gateway-ին ուղղված հարցումներից, զուգահեռ հարցումներ է ուղարկում յուրաքանչյուր Thanos Sidecar-ին, որը գտնվում է Պրոմեթևսի կողքին:
Իսկ Thanos Sidecar-ն, իր հերթին, վստահված անձ է պահանջում Պրոմեթևսին և առբերում է վերջին երկու ժամվա տվյալները:
Բացի այս բաղադրիչներից, կա նաև ընտրովի բաղադրիչ, առանց որի Thanos-ը լավ չի աշխատի: Սա Thanos Compact-ն է, որը պատասխանատու է Object Storage-ի փոքր ֆայլերի միաձուլման համար ավելի մեծ ֆայլերի մեջ, որոնք վերբեռնվել են այստեղ Thanos Sidecars-ի կողմից: Thanos Sidecar-ը տվյալների ֆայլեր է վերբեռնում այնտեղ երկու ժամում: Այս ֆայլերը, եթե դրանք չմիավորվեն ավելի մեծ ֆայլերի մեջ, ապա դրանց թիվը կարող է զգալիորեն աճել։ Որքան շատ նման ֆայլեր, այնքան ավելի շատ հիշողություն է պահանջվում Thanos Store Gateway-ի համար, այնքան ավելի շատ ռեսուրսներ են անհրաժեշտ ցանցով և մետատվյալներ փոխանցելու համար: Thanos Store Gateway-ը դառնում է անարդյունավետ: Հետևաբար, անհրաժեշտ է գործարկել Thanos Compact-ը, որը փոքր ֆայլերը միաձուլում է ավելի մեծերի, որպեսզի նման ֆայլերը քիչ լինեն և Thanos Store Gateway-ի ծախսերը կրճատվեն:
Կա նաև այնպիսի բաղադրիչ, ինչպիսին է Thanos Ruler-ը: Այն իրականացնում է Prometheus-ի ահազանգման կանոնները և կարող է գնահատել Prometheus-ի ձայնագրման կանոնները, որպեսզի ետ գրի տվյալները Object Storage-ում: Բայց այս բաղադրիչը խորհուրդ չի տրվում օգտագործել, քանի որ... Նա .
Սա Thanos-ի պարզ սխեման է։
Հիմա եկեք այն համեմատենք VictoriaMetrics սխեմայի հետ:
VictoriaMetrics-ն ունի 2 տարբերակ՝ մեկ հանգույց և կլաստեր: Single-node-ն աշխատում է մեկ համակարգչի վրա: Single-node-ը չունի այս բաղադրիչները, ընդամենը մեկ երկուական: Այս երկուականը սլայդի վրա կարծես այս քառակուսին է: Այն ամենը, ինչ գտնվում է քառակուսու ներսում, երկուական ֆայլի բովանդակությունն է Single-node տարբերակի համար: Նրա մասին պետք չէ իմանալ: Դուք պարզապես գործարկում եք երկուական տարբերակը, և ամեն ինչ աշխատում է մեզ մոտ:
Կլաստերային տարբերակն ավելի բարդ է։ Դրա ներսում կան երեք տարբեր բաղադրիչներ՝ vmselect, vminsert և vmstorage: Նրանց անունից պետք է պարզ լինի, թե ինչ է անում նրանցից յուրաքանչյուրը։ Ներդիր բաղադրիչն ընդունում է տվյալներ տարբեր ձևաչափերով՝ Prometheus հեռակառավարման գրելու API-ից, Influx line protocol-ից, Graphite արձանագրությունից և OpenTSDB արձանագրությունից: Ներդիր բաղադրիչն ընդունում է դրանք, վերլուծում և բաշխում առկա պահեստային բաղադրիչների միջև, որտեղ տվյալներն արդեն պահված են։ Select բաղադրիչն իր հերթին ընդունում է PromQL հարցումները։ Նա իրականացնում է , ինչպես նաև Prometheus հարցումների API-ն, և այն կարող է օգտագործվել որպես Prometheus-ի փոխարինում Grafana-ում կամ Prometheus API-ի այլ հաճախորդների համար: Ընտրելն ընդունում է promql հարցումը, վերլուծում է այն, կարդում է այս հարցումը կատարելու համար անհրաժեշտ տվյալները պահեստային հանգույցներից, մշակում է այս տվյալները և վերադարձնում պատասխան:
Եկեք համեմատենք Thanos-ի և VictoriaMetrics-ի տեղադրման բարդությունը:
Սկսենք Թանոսից։ Thanos-ի հետ աշխատելուց առաջ պետք է Object Storage-ում ստեղծել մի դույլ, օրինակ՝ S3 կամ GCS, որպեսզի Thanos Sidecar-ը կարողանա տվյալներ գրել դրան:
Այնուհետև յուրաքանչյուր Պրոմեթևսի համար անհրաժեշտ է տեղադրել Thanos Sidecar-ը: Մինչ այս, դուք պետք է հիշեք անջատել տվյալների խտացումը Պրոմեթևսում: Տվյալների խտացումը պարբերաբար սեղմում է տվյալները տեղական Prometheus պահեստում՝ ռեսուրսների սպառումը նվազեցնելու համար:
Երբ Thanos Sidecar-ը տեղադրում եք ձեր Prometheus-ի վրա, դուք պետք է անջատեք այս տվյալների խտացումը, քանի որ Thanos Sidecar-ը ճիշտ չի աշխատում, եթե տվյալների խտացումը միացված է: Սա նշանակում է, որ ձեր Prometheus-ը սկսում է տվյալները պահել երկու ժամանոց բլոկներով և դադարեցնում է այդ բլոկների միաձուլումը ավելի մեծերի: Համապատասխանաբար, եթե հարցումներ կատարեք, որոնք գերազանցում են վերջին երկու ժամվա տևողությունը, ապա դրանք այնքան արդյունավետ չեն աշխատի, որքան կարող էին աշխատել, եթե տվյալների խտացումը միացված լիներ:
Հետևաբար, Thanos-ը խորհուրդ է տալիս նվազեցնել տվյալների պահպանման ժամանակը տեղական պահեստում մինչև 6-8 ժամ՝ մեծ թվով փոքր բլոկների ծախսերը նվազեցնելու համար:
Thanos Sidecar-ը տեղադրելուց հետո դուք պետք է տեղադրեք երկու բաղադրիչ յուրաքանչյուր օբյեկտի պահեստավորման դույլի համար: Սրանք Thanos Compactor-ն ու Thanos Store Gateway-ն են:
Դրանից հետո դուք պետք է տեղադրեք Thanos Query-ը և կարգավորեք այն, որպեսզի այն կարողանա միանալ ձեր ունեցած Thanos Store-ի բոլոր դարպասներին, ինչպես նաև կարող է միանալ Thanos Sidecar-ներին:
Այստեղ կարող է մի փոքր խնդիր լինել։
Դուք պետք է կարգավորեք հուսալի և անվտանգ կապ Thanos Query-ից այս բաղադրիչներին: Իսկ եթե ձեր Prometheus-ը գտնվում է տվյալների տարբեր կենտրոններում, կամ տարբեր VPC-ներում, ապա դրսից նրանց հետ կապերն արգելված են։ Բայց որպեսզի Thanos Query-ն աշխատի, դուք պետք է ինչ-որ կերպ կարգավորեք կապն այնտեղ, և դուք պետք է ճանապարհ գտնեք:
Եթե դուք ունեք բազմաթիվ նման տվյալների կենտրոններ, ապա, համապատասխանաբար, ամբողջ համակարգի հուսալիությունը նվազում է: Քանի որ Thanos Query-ը պետք է մշտապես կապեր պահպանի բոլոր Thanos Sidecars-ի հետ, որոնք տեղակայված են տվյալների տարբեր կենտրոններում: Յուրաքանչյուր մուտքային հարցման համար այն կուղարկի հարցումները բոլոր Thanos Sidecars-ին: Եթե կապն ընդհատվի, դուք կա՛մ կստանաք տվյալների թերի փաթեթ, կա՛մ «կլաստերը դադարեցված է» պատասխանը:
VictoriaMetrics-ում ամեն ինչ մի փոքր ավելի պարզ է: Single-node տարբերակի համար պարզապես անհրաժեշտ է գործարկել մեկ երկուական տարբերակ և ամեն ինչ աշխատում է:
Կլաստերային տարբերակում բավական է գործարկել վերը նշված բոլոր երեք տեսակի բաղադրիչները ձեզ անհրաժեշտ ցանկացած քանակությամբ կամ օգտագործել ավտոմատացնել բաղադրիչների գործարկումը Kubernetes-ում: Նախատեսում ենք նաև Kubernetes օպերատոր ստեղծել։ Helm աղյուսակը չի ներառում որոշ դեպքեր և թույլ է տալիս կրակել ինքներդ ձեզ ոտքին: Օրինակ, այն թույլ է տալիս նվազեցնել պահեստավորման հանգույցների քանակը, ինչը կհանգեցնի տվյալների կորստի։
Մեկ երկուական կամ կլաստերային տարբերակ գործարկելուց հետո դուք պարզապես պետք է ավելացնեք Պրոմեթևսը կազմաձևում այնպես, որ այն սկսի տվյալներ գրել տեղական պահեստին և հեռավոր պահպանմանը զուգահեռ: Ինչպես տեսնում եք, այս կոնֆիգուրացիան պետք է շատ ավելի հուսալի կատարի Thanos-ի կոնֆիգուրացիայի համեմատ: Մեզ պետք չէ կապ պահպանել VictoriaMetrics-ից բոլոր Պրոմեթևսին, քանի որ Պրոմեթևսն ինքը միանում է VictoriaMetrics-ին և փոխանցում տվյալներ:
Դիտարկենք Thanos-ի և VictoriaMetrics-ի աջակցությունը։
Thanos-ը պետք է վերահսկի Sidecar-ը, որպեսզի համոզվի, որ նրանք չեն դադարեցնի տվյալների բեռնումը Object Storage-ում: Նրանք կարող են դադարեցնել այս տվյալների ներբեռնումը ներբեռնման սխալների պատճառով, օրինակ՝ ձեր ցանցային կապը Object Storage-ին ժամանակավորապես ընդհատվել է, կամ Object Storage-ը ժամանակավորապես անհասանելի է: Thanos Sidecar-ը կնկատի դա այս պահին, կհայտնի սխալի մասին, կարող է վթարի ենթարկվել և հետո դադարեցնել աշխատանքը: Եթե դուք չեք վերահսկում այն, ապա կդադարեցնեք տվյալների փոխանցումը Object Storage-ին: Եթե պահպանման ժամկետն անցնի (առաջարկվում է 6-8 ժամ), ապա դուք կկորցնեք այն տվյալները, որոնք չեն հայտնվել Object Storage-ում:
Thanos կոմպակտորները կարող են դադարեցնել աշխատանքը՝ պայմանավորված . Կոմպակտորները վերցնում են տվյալները Object Storage-ից և միավորում դրանք ավելի մեծ տվյալների մեջ: Քանի որ կոմպակտորները համաժամանակացված չեն Sidecars-ի հետ, կարող է տեղի ունենալ հետևյալը. Sidecar-ը դեռ չի հասցրել ավարտին հասցնել բլոկը, Compactor-ը որոշում է, որ այս բլոկն ամբողջությամբ գրված է: Կոմպակտորը սկսում է կարդալ այն։ Այն ամբողջությամբ չի կարդում բլոկը և դադարում է աշխատել: Տես մանրամասները .
Store Gateway-ը կարող է վերադարձնել անհամապատասխան տվյալներ Compactor-ի և Sidecars-ի միջև մրցավազքի պատճառով: Նույնը տեղի է ունենում այստեղ, քանի որ Store Gateway-ը ոչ մի կերպ սինխրոնիզացված չէ Compactors-ի և Sidecars-ի հետ։ Համապատասխանաբար, մրցավազքի պայմանները կարող են առաջանալ, երբ Store Gateway-ը չի տեսնում տվյալների մի մասը կամ տեսնում է անհարկի տվյալներ:
Thanos-ում Query բաղադրիչը լռելյայնորեն վերադարձնում է մասնակի արդյունք, եթե որոշ Sidecars կամ Store Gateways այս պահին հասանելի չեն: Դուք կստանաք տվյալների մի մասը, և նույնիսկ չեք իմանա, որ չեք ստացել բոլոր տվյալները։ Այսպես է աշխատում լռելյայն։ Նմանատիպ իրավիճակում VictoriaMetrics-ը վերադարձնում է նշված տվյալները որպես մասնակի:
Ի տարբերություն Thanos-ի, VictoriaMetrics-ը հազվադեպ է տվյալներ կորցնում: Նույնիսկ եթե Պրոմեթևսից VictoriaMetrics-ի կապն ընդհատվի, դա խնդիր չէ, քանի որ Պրոմեթևսը շարունակում է մուտքային նոր տվյալներ գրանցել Write Ahead Log-ում, որի չափը 2 ժամ է: Եթե երկու ժամվա ընթացքում վերականգնեք ձեր կապը VictoriaMetrics-ին, ձեր տվյալները չեն կորչի: Պրոմեթևս .
Ի տարբերություն Thanos-ի, որը տվյալները գրում է օբյեկտների պահեստում միայն երկու ժամ հետո, Prometheus-ը ավտոմատ կերպով կրկնօրինակում է տվյալները՝ օգտագործելով հեռակա գրման արձանագրությունը հեռավոր պահեստում, ինչպիսին է VictoriaMetrics-ը: Դուք չեք վախենում Պրոմեթևսում տեղական պահեստը կորցնելուց: Եթե նա հանկարծ կորցրեց տեղական պահեստը, ապա վատագույն դեպքում դուք կկորցնեք տվյալների վերջին վայրկյանները, որոնք ժամանակ չունեին հեռավոր պահեստում գրանցելու համար:
Kubernetes-ը ավտոմատ կերպով կառավարում է կլաստերը՝ ի տարբերություն Thanos-ի։ Դժվար է Thanos-ի բոլոր բաղադրիչները տեղադրել մեկ Kubernetes կլաստերի մեջ, ի տարբերություն VictoriaMetrics կլաստերի բաղադրիչների:
VictoriaMetrics-ն ունի նոր տարբերակի շատ պարզ թարմացում: Պարզապես դադարեցրեք VictoriaMetrics-ը, թարմացրեք երկուականները և գործարկեք այն: Երբ դադարեցվում է SIGINT ազդանշանի միջոցով, VictoriaMetrics-ի բոլոր երկուականները կատարում են նրբագեղ անջատում: Նրանք ճիշտ են պահպանում անհրաժեշտ տվյալները, ճիշտ փակում մուտքային կապերը՝ ոչինչ չկորցնելու համար։ Այսպիսով, դուք ոչինչ չեք կորցնի արդիականացման ժամանակ:
VictoriaMetrics-ը շատ հեշտ է դարձնում կլաստերի ընդլայնումը: Պարզապես ավելացրեք անհրաժեշտ բաղադրիչները և շարունակեք աշխատել:
Thanos-ի և VictoriaMetrics-ի որոգայթների մասին:
Թանոսն ունի հետևյալ թակարդները. Պրոմեթևսը պետք է պահպանի տվյալները վերջին երկու ժամվա ընթացքում։ Եթե նրանք կորչեն, դուք դրանք ամբողջությամբ կկորցնեք, քանի որ դրանք դեռ չեն գրվել Object Storage-ում, ինչպես S3-ը:
Store Gateway բաղադրիչը և կոմպակտորի բաղադրիչը կարող են մեծ հիշողություն պահանջել՝ մեծ օբյեկտների պահեստավորման հետ աշխատելու համար, եթե այնտեղ շատ փոքր ֆայլեր կան: Որքան մեծ է ֆայլերի քանակը և չափը, այնքան ավելի շատ Store Gateway և compactor RAM է պահանջվում մետատեղեկատվությունը պահելու համար: Թանոսը շատ խնդիրներ ունի կապված այն փաստի հետ, որ .
Thanos-ը գովազդվում է անժամկետ մասշտաբով ձեր ունեցած Պրոմեթևսի քանակով: Սա իրականում ճիշտ չէ: Քանի որ բոլոր հարցումներն անցնում են Query բաղադրիչով, որը պետք է միաժամանակ հարցումներ կատարի Store Gateway-ի և Sidecar-ի բոլոր բաղադրիչների միջոցով, այնտեղից հանեք տվյալները և այնուհետև նախապես մշակեք դրանք: Ակնհայտ է, որ հարցման արագությունը սահմանափակվում է ամենադանդաղ թույլ կապով, ամենադանդաղ Store Gateway-ով կամ ամենադանդաղ Sidecar-ով:
Այս բաղադրիչները կարող են անհավասար բեռնված լինել: Օրինակ, դուք ունեք Պրոմեթևս, որը վայրկյանում հավաքում է միլիոնավոր չափումներ: Եվ կա Պրոմեթևս, որը վայրկյանում հազարավոր չափումներ է հավաքում: Պրոմեթևսը, որը վայրկյանում միլիոնավոր չափումներ է հավաքում, շատ ավելի մեծ բեռ է դնում այն սերվերի վրա, որի վրա աշխատում է: Համապատասխանաբար, Sidecar-ն այնտեղ ավելի դանդաղ է աշխատում։ Իսկ ընդհանրապես այնտեղ ամեն ինչ դանդաղ է աշխատում։ Եվ Query բաղադրիչն այնտեղից շատ դանդաղ կհանի տվյալներ: Համապատասխանաբար, ձեր ամբողջ կլաստերի կատարումը կսահմանափակվի այս դանդաղ Sidecar-ով:
Լռելյայնորեն, Thanos-ը մասնակի տվյալներ է տալիս, եթե որոշ Sidecars կամ Store Gateway-ն անհասանելի են: Օրինակ, եթե ձեր Sidecars-ը ցրված է աշխարհով մեկ՝ տվյալների տարբեր կենտրոններում, ապա կապի խափանման հավանականությունը և բաղադրիչի անհասանելիությունը մեծապես մեծանում է: Համապատասխանաբար, շատ դեպքերում դուք կստանաք մասնակի տվյալներ՝ առանց նույնիսկ դրա մասին իմանալու։
VictoriaMetrics-ը նույնպես որոգայթներ ունի: Առաջին որոգայթն այն տարբերակն է, որը սահմանափակում է VictoriaMetrics քեշի համար օգտագործվող RAM-ի քանակը: Լռելյայնորեն, այն հավասար է մեքենայի RAM-ի 60%-ին, որտեղ աշխատում է VictoriaMetrics-ը կամ VictoriaMetrics pod-ի RAM-ի 60%-ին Kubernetes-ում:
Եթե սխալ եք փոխում այս արժեքը, կարող եք փչացնել VictoriaMetrics-ի կատարումը: Օրինակ, եթե արժեքը չափազանց ցածր եք սահմանում, տվյալներն այլևս չեն տեղավորվում VictoriaMetrics քեշում: Դրա պատճառով նա ստիպված կլինի լրացուցիչ աշխատանք կատարել և բեռնել պրոցեսորն ու սկավառակը: Եթե այս տարբերակը չափազանց մեծացնեք, դա մեծացնում է, առաջին հերթին, հավանականությունը, որ VictoriaMetrics-ը խափանվի հիշողության պակասի պատճառով, և, երկրորդ, դա կհանգեցնի նրան, որ օպերացիոն համակարգի հիշողության մեջ շատ քիչ RAM կմնա: ֆայլի քեշ. Իսկ VictoriaMetrics-ը աշխատանքի համար հիմնվում է ֆայլերի քեշի վրա: Եթե դա բավարար չէ, ապա սկավառակի բեռը կարող է մեծապես աճել: Հետևաբար, խորհուրդ. մի փոխեք պարամետրը, եթե բացարձակապես անհրաժեշտ չէ:
Երկրորդ տարբերակ. Սա RetentionPeriod-ն է՝ ժամանակաշրջան, որը լռելյայնորեն սահմանված է 1 ամիս: Սա VictoriaMetrics-ի տվյալների պահպանման տևողությունն է: Այս ժամանակահատվածից հետո VictoriaMetrics-ը ջնջում է տվյալները։
Շատ մարդիկ աշխատում են VictoriaMetrics-ն առանց այս պարամետրի և գրանցում են տվյալներ մեկ ամսվա ընթացքում: Իսկ հետո հարցնում են՝ ինչո՞ւ են անհետացել նախորդ ամսվա տվյալները։ Քանի որ կանխադրված պահպանման ժամկետը 1 ամիս է: Հետևաբար, դուք պետք է իմանաք և սահմանեք ճիշտ պահպանման ժամկետը:
Եկեք նայենք եզակի հատկանիշներին:
Thanos-ն ունի մի առանձնահատկություն, որը կոչվում է կրճատումներ՝ 5 րոպեանոց և ժամային ընդմիջումներով, ինչը հաճախ . Եթե դուք google-ում եք և դիտում եք նրանց խնդիրը github-ում, ապա կան բազմաթիվ խնդիրներ՝ կապված այս կրճատման հետ, որոնք երբեմն ճիշտ չեն աշխատում կամ չեն աշխատում այնպես, ինչպես ակնկալում են օգտատերերը:
Թանոսն ունի տվյալների կրկնօրինակում Prometheus HA զույգերի համար: Երբ երկու Պրոմեթևս հավաքում են նույն ցուցանիշները նույն թիրախներից, իսկ Թանոսը դրանք պահում է Object Storage-ում: Thanos-ը կարող է պատշաճ կերպով կրկնօրինակել այս տվյալները՝ ի տարբերություն VictoriaMetrics-ի:
Thanos-ն ունի ազդանշանային բաղադրիչ, որը եղել է Thanos-ի սխեմայում: Բայց նա .
Թանոսն ունի այն առավելությունը, որ Թանոսը և Պրոմեթևսը կիսում են նույն ծածկագիրը։ Thanos-ը և Prometheus-ը մշակվել են նույն մշակողների կողմից: Թանոսի կամ Պրոմեթևսի բարելավումներով մյուս կողմը հաղթում է:
VictoriaMetrics-ի հիմնական առանձնահատկությունը MetricsQL-ն է: Սրանք VictoriaMetrics ընդլայնումներ են PromQL-ի համար, որոնց մասին ես խոսեցի նախորդ մեծ մոնիտորինգի հանդիպման ժամանակ:
VictoriaMetrics-ն աջակցում է տվյալների բեռնումը՝ օգտագործելով բազմաթիվ տարբեր արձանագրություններ: VictoriaMetrics-ը ոչ միայն կարող է ընդունել տվյալներ Պրոմեթևսից, այլև Influx, OpenTSDB և Graphite արձանագրությունների միջոցով:
VictoriaMetrics-ի տվյալները շատ ավելի քիչ տեղ են զբաղեցնում Thanos-ի և Prometheus-ի համեմատ:
Եթե իրական տվյալներ եք գրանցում, օգտվողները խոսում են սկավառակի վրա տվյալների չափի 2-5 անգամ կրճատման մասին՝ համեմատած Պրոմեթևսի և Թանոսի հետ։
VictoriaMetrics-ի մեկ այլ առավելությունն այն է, որ այն օպտիմիզացված է արագության համար:
Դիտարկենք ենթակառուցվածքների արժեքը:
Thanos-ի առավելություններից մեկն այն է, որ այն տվյալները պահպանում է օբյեկտների պահեստում, ինչը համեմատաբար էժան է։
Տվյալները օբյեկտների պահեստում պահելու ժամանակ դուք պետք է վճարեք տվյալների գրման և ընթերցման գործողությունների համար ($10 մեկ միլիոն գործողությունների համար): Երբ դուք տվյալներ եք գրում օբյեկտների պահեստում, դուք վճարում եք ձեր հոսթինգի ծախսերը տվյալների Ինտերնետ վերբեռնելու համար, եթե ձեր կլաստերը AWS-ում չէ, այն այնտեղ անվճար է: Երբ դուք կարդում եք տվյալները, դուք վճարում եք $10-ից $230-ը 1TB-ի համար: Սա կարող է նշանակալից լինել, եթե հաճախակի հարցումներ եք անում Thanos կլաստերի պատմական տվյալների վրա:
Thanos կլաստերի համար դուք պետք է վճարեք սերվերների համար Compact-ի, Store Gateway-ի, Query բաղադրիչների համար, որոնք պահանջում են շատ հիշողություն, և CPU-ի համար մեծ քանակությամբ տվյալների համար:
VictoriaMetrics-ն ունի հետևյալ ծախսերը. Եթե դուք տվյալները պահում եք GCE HDD սկավառակների վրա, ապա 40 ՏԲ-ի համար այն կկազմի $1: VictoriaMetrics-ի համար սովորական HDD կրիչներ բավարար են, կարիք չկա SSD-ների, որոնց արժեքը հինգ անգամ ավելի է: VictoriaMetrics-ը օպտիմիզացված է HDD-ի համար:
VictoriaMetrics-ը պահանջում է սերվերներ բաղադրիչների համար՝ կա՛մ Single-nod, կա՛մ կլաստերային բաղադրիչներ, որոնք, ի տարբերություն Thanos-ի բաղադրիչների, պահանջում են շատ ավելի քիչ CPU և RAM, և համապատասխանաբար ավելի էժան կլինեն:
Իրականացման օրինակներ.
Thanos-ն ունի իրականացման օրինակ Gitlab-ում: Gitlab-ն ամբողջությամբ աշխատում է Thanos-ով: Բայց այնտեղ ամեն ինչ այնքան էլ հարթ չէ։ Եթե նայեք նրանց , ապա դուք կարող եք տեսնել, որ նրանք անընդհատ ունեն որոշ Չկա բավարար հիշողություն Store Gateway-ի կամ Query բաղադրիչների համար: Նրանք անընդհատ պետք է ավելացնեն հիշողության ծավալը։
Դրա պատճառով ավելանում են այդ խնդիրների լուծման ծախսերը։
Երկրորդ իրականացումը, որը կարող է ավելի հաջող լինել, Improbable ընկերությունն է, որը սկսեց զարգացնել Thanos-ը: Նրանք հրապարակել են Thanos-ի սկզբնական կոդը։ Improbable-ը խաղային շարժիչներ մշակող ընկերություն է:
VictoriaMetrics-ն ունի հանրային իրականացման օրինակներ.
- wix.com կայքի ստեղծող
- Adidas-ն իրականացնում է VictoriaMetrics-ը և նույնիսկ ներկայացրեց վերջին PromCon 2019-ին:
- TrafficStars - գովազդային ցանց
- Seznam.cz-ը հայտնի չեխական որոնողական համակարգ է:
Եվ հետո կային անանուն ընկերություններ, որոնց հիմա չեմ կարող անվանել: Նրանք չհամաձայնեցին։
- Մեկ խոշոր խաղերի մշակող. Ավելի մեծ, քան անհավանական է:
- Գրաֆիկական ծրագրերի հիմնական մշակող:
- Ռուսական խոշոր բանկ.
- Եվրոպական հողմային տուրբինների արտադրող, որը հաջողությամբ փորձարկել է VictoriaMetrics-ը: Այս արտադրողը ներդնում է VictoriaMetrics-ը հողմային տուրբիններից հավաքագրված տվյալների մոնիտորինգի համար՝ վայրկյանում 50 նմուշ մեկ սենսորի համար: Յուրաքանչյուր հողմատուրբին ունի մի քանի հարյուր սենսոր: Նրանք ունեն մի քանի հարյուր հողմային տուրբիններ։
- Ռուսական ավիաընկերությունները, որոնք ցանկանում են իրականացնել VictoriaMetrics-ը, բայց դեռ չեն կարողանում: Մենք նրանց հետ պայմանագրային փուլում ենք։
Եզրակացություններ:
VictoriaMetrics-ը և Thanos-ը լուծում են նմանատիպ խնդիրներ, բայց տարբեր ձևերով.
- Հարցման գլոբալ տեսք
- հորիզոնական մասշտաբավորում
- կամայական պահում
Շնորհակալություն:
Մենք սպասում ենք ձեզ մեր մոտ .
Հարցմանը կարող են մասնակցել միայն գրանցված օգտվողները։ , խնդրում եմ:
Ի՞նչ եք օգտագործում որպես երկարաժամկետ պահեստավորում Պրոմեթևսի համար:
-
35,3%Թանոս6
-
0,0%Կեղև 0
-
0,0%M3DB0
-
41,2%VictoriaMetrics 7
-
23,5%այլ 4
Քվեարկել է 17 օգտատեր։ 16 օգտատեր ձեռնպահ է մնացել։
Source: www.habr.com