Ընտրում ենք Prometheus-ի տվյալների պահոցը՝ Thanos ընդդեմ VictoriaMetrics

Բարև բոլորին։ Ստորև ներկայացված է Big Monitoring Meetup 4-ի զեկույցի վերծանումը.

KDB – տարբեր համակարգերի և ծառայությունների մոնիթորինգի համակարգ, որի միջոցով համակարգային ադմինիստրատորները կարող են հավաքագրել տեղեկատվություն համակարգերի ներկայիս պարամետրերի մասին և կարգավորել ծանուցումները համակարգերի աշխատանքում ակնհայտ շեղումներ ստանալու համար։

Զեկույցում լինելու է համեմատություն Thanos և VictoriaMetrics ՝ Prometheus մետրանոցների երկարաժամկետ պահելու նախագծեր։

Սկզբում կներկայացնեմ Prometheus-ը։ Սա մոնիթորինգի համակարգ է, որը հավաքագրում է մետրիկները բերված target-ներից և պահում դրանք տեղական պահեստում։ Prometheus-ը կարող է մետրիկները գրել հեռավոր պահեստում, կարող է ստեղծել ծանուցումներ և գրանցման կանոններ։

Prometheus-ի սահմանափակումները՝

• Այն չունի համաշխարհային հարցումների տեսք։ Սա այն դեպքում, երբ դուք ունեք մի քանի անկախ Prometheus օրինակներ։ Նրանք հավաքագրում են մետրիկները։ Եվ դուք ցանկանում եք հարցում անել բոլոր այդ մետրիկների վրա, որոնք հավաքագրվել են տարբեր Prometheus օրինակներից։ Prometheus-ը դա թույլ չի տալիս։
• Prometheus-ի կատարողականությունը սահմանափակված է միայն մեկ սերվերով։ Prometheus-ը ավտոմատ կերպով չի կարող ընդլայնվել մի քանի սերվերների վրա։ Դուք միայն կարող եք ձեռքով բաժանել ձեր target-ները մի քանի Prometheus-ների միջև։
• Prometheus-ի մետրիկների ծավալը սահմանափակված է միայն մեկ սերվերով՝ նույն պատճառով, թե ինչու այն ավտոմատ կերպով չի կարող ընդլայնվել մի քանի սերվերների վրա։
• Prometheus-ում տվյալների պահպանման հարցը այնքան էլ պարզ չէ։

Այս խնդիրների/փոխանցումների լուծումները՝

Լուծումները հետևյալն են՝

• Thanos
• VictoriaMetrics
• Uber M3
• Cortex

Այս բոլոր լուծումները նախատեսված են Prometheus-ի կողմից հավաքագրված տվյալների հեռավոր պահպանման համար։ Նրանք տարբեր կերպ լուծում են նախորդ ս Slide-ի հեռավոր պահեստի խնդիրները։ Այս պրեզենտացիայում ես միայն կներկայացնեմ առաջին երկու լուծումները։ Thanos և VictoriaMetrics.

Առաջին անգամ տեղեկություն Thanos ներկայացավ այս հղմամբ։Այտեղ նկարագրված է վերակառուցումը Thanos Եվ ինչպես է այն գործում։

Thanos-ը վերցնում է տվյալները, որոնք պահել է Prometheus-ը տեղական սկավառում, և նրանց պատճենում S3, GCS կամ մի այլ օբյեկտային պահեստում։

Այսպիսով, Thanos-ը ապահովում է համաշխարհային հարցում։ Դուք կարող եք հարցում կատարել տվյալների վրա, որոնք պահվում են օբյեկտային պահեստում մի քանի Prometheus օրինակներից։

Thanos-ը աջակցում է PromQL-ին և Prometheus հարցումների API-ին.

Thanos-ը օգտագործում է Prometheus-ի կոդը տվյալների պահելու համար։

Thanos-ը մշակված է նույն ծրագրավորողների կողմից, ովքեր մշակում են Prometheus-ը։

Դու մասին VictoriaMetrics։ Սա հղումը՝ որտեղ մենք առաջին անգամ խոսեցինք VictoriaMetrics.

VictoriaMetrics-ը տվյալներ է հավաքում մի քանի Prometheus-ներից հեռավոր գրառման API-ով Prometheus-ի կողմից աջակցվող գործընթացով։

VictoriaMetrics-ը ապահովում է համաշխարհային հարցում, քանի որ մի քանի Prometheus օրինակներ կարող են տվյալներ գրանցել մեկ VictoriaMetrics-ում։ Հետևաբար, դուք կարող եք հարցումներ անել այս բոլոր տվյալները։

VictoriaMetrics-ը, ինչպես Thanos-ը, աջակցում է PromQL-ին և Prometheus հարցումների API-ին։

Thanos-ից տարբերվող, VictoriaMetrics-ի աղբյուրի կոդը գրվել է զրոյից և օպտիմիզացված է արագության և պաշարների սպառման համար։

VictoriaMetrics-ը, անկասկած, Thanos-ի համեմատությամբ, ընդլայնվում է ինչպես ուղղահայաց, այնպես էլ հորիզոնական։ Ի՞նչ Single-node տարբերակը, որը սարքավորում է ուղղահայաց ընդգրկում: Դուք կարող եք սկսել մեկ պրոցեսորով և 1 ԳԲ հիշողությամբ և աստիճանաբար աճել մինչև հարյուր պրոցեսոր և 1ԹԲ հիշողություն: VictoriaMetrics-ը կարող է օգտագործել բոլոր այս ռեսուրսները: Նրա կատարողականությունը կհասնի մոտ 100 անգամ ավելի բարձր ցուցանիշի, քան 1-ն վրայային համակարգը:

Thanos-ի պատմությունը սկսվում է 2017 թվականի նոյեմբերից, երբ հայտնվեց առաջին հրապարակային կոմիտը: Վստահ եմ, որ մինչ այդ Thanos-ը մշակել էր ընկերության ներսում: improbable.io.

2019 թվականի հունիսին տեղի ունեցավ նշանավոր 0.5.0 թողարկումը, որի ընթացքում հանեցին գոսիպ պրոտոկոլը: Այն հանվեց Thanos-ից, որովհետև իր գործնականությունը լավ չէր: Oftentimes Thanos կլաստերը սխալ էր գործում, սխալ կապվում էին հանգույցները gossip պրոտոկոլի պատճառով: Այդ իսկ պատճառով որոշվեց, որ այն պետք է հանվի: Ես կարծում եմ, որ սա ճիշտ որոշում է:

2019 թվականի հունիսին նրանք ներկայացրեցին հայտ թիվ 256 մեջ Cloud Native Computing Foundation.

Եվ մի քանի ամիս անց Thanos-ը ընդունվեց Cloud Native Computing Foundation, որը ընդգրկում է Prometheus-ը, Kubernetes-ը և այլ հայտնի նախագծեր:

2018 թվականի հունվարին սկսվեց VictoriaMetrics-ի մշակումը:

2018 թվականի սեպտեմբերին առաջին անգամ հրապարակավ հիշեցի VictoriaMetrics-ի մասին:

2018 թվականի դեկտեմբերին հրապարակվեց Single-node տարբերակը:

2019 թվականի մայիսին հրապարակվեցին քանոնական և կավելյան տարբերակի ծրագրային կոդերը:

2019 թվականի հունիսին, ինչպես Thanos, մենք ներկայացրեցինք հայտ CNCF հիմնադրամին թիվ 255. Մենք դնելով հայտը մեկ օր առաջ, քան Thanos-ը:

Բայց, ցավոք, մեզ դեռևս չեն ընդունել այնտեղ: Օգնություն է պահանջվում համայնքից:

Նայենք ամենակարևոր սլայդերը, որոնք ցույց են տալիս Thanos-ի և VictoriaMetrics-ի ճարտարապետությունը:

Սկզբում Thanos-ի մասին: Ոսկեգույն բաղադրիչները՝ Prometheus-ի բաղադրիչներն են: Մնացածը՝ Thanos-ի բաղադրիչներն են: Սկսենք ամենակարևոր բաղադրիչից: Thanos Sidecar-ը՝ այն բաղադրիչը, որը տեղադրվում է յուրաքանչյուր Prometheus-ի կողքին: Այն գործում է այն բանից, որ բեռնում է Prometheus տվյալները տեղական պահպանմումից S3 կամ այլ Object Storage:

Կա նաև Thanos Store Gateway բաղադրիչը, որը կարող է կարդալ այդ տվյալները Object Storage-ից Thanos Query-ի մուտքային հարցումների ժամանակ: Thanos Query-ն իրականացնում է PromQL և Prometheus API: Այսպիսով, այն արտաքինից երևում է ինչպես Prometheus: Այն ընդունում է PromQL հարցումներ, ուղարկում է դրանք Thanos Store Gateway-ին, Thanos Store Gateway-ն տրամադրում է անհրաժեշտ տվյալները Object Storage-ից, ուղարկում է դրանք հետ:

Բայց մեր Object Storage-ում տվյալներ ենք պահում վերջին երկու ժամի համար, քանի որ Thanos Sidecar-ի իրականացման առանձնահատկությունը չի կարողանա բեռնել վերջին երկու ժամն Object Storage S3-ում, քանի որ այդ ընթացքում Prometheus-ը դեռ չի ստեղծել ֆայլերը տեղական պահպանման մեջ:

Ինչպե՞ս լուծել այս խնդիրը: Thanos Query-ն, բացի Thanos Store Gateway-ի հարցումներից, զուգահեռ տանում է հարցումներ նաև դեպի յուրաքանչյուր Thanos Sidecar, որոնք գտնվում են Prometheus-ի կողքին:

Եվ Thanos Sidecar-ը, իր հերթին, հարցումները շուրջն է մարդկանցորդվում Prometheus-ին և տրամադրում տվյալները վերջին երկու ժամվա համար:

Այս բաղադրիչներից բացի, կա նաև ընտրովի բաղադրիչ, առանց որի Thanos-ին դժվար կլինի աշխատել։ Դա Thanos Compact-ն է, որը զբաղվում է փոքր ֆայլերի միավորմամբ Object Storage-ում ավելի մեծ ֆայլերի, որոնք այստեղ բեռնում են Thanos Sidecar-ները։ Thanos Sidecar-ները բեռնում են տվյալների ֆայլերը երկու ժամվա ընթացքում։ Այս ֆայլերը, եթե չեն միացվել ավելի մեծ ֆայլերի, կարող են շատ ավելանալ։ Пhopos, որքան ավելի շատ ֆայլեր, այնքան ավելի շատ հիշողություն է անհրաժեշտ Thanos Store Gateway-ի համար, այնքան ավելի շատ ռեսուրսներ են_needed՝ տվյալների փոխանցման և մետատվյալների համար։ Thanos Store Gateway-ի աշխատանքը կդառնա անկարևոր։ Ուստի պարտադիր պետք է գործարկել Thanos Compact-ը, որը միաձուլում է փոքր ֆայլերը ավելի մեծերի մեջ, որպեսզի այդպիսի ֆայլերի քանակը նվազեցվի և նվազեցվի Thanos Store Gateway-ի վրա նաեւ։

Կա նաև Thanos Ruler անվանումով բաղադրիչ։ Այն իրականացնում է Prometheus ավտոմատացման կանոնները և կարող է հաշվարկել Prometheus գրառվող կանոնները՝ տվյալները նորից գրանցելու համար Object Storage-ում։ Բայց այս բաղադրիչը չի խորհուրդ տրվում օգտագործել, քանի որ այն տ tendency է վերադարձնելու լրիվ տվյալներ.

Ահա Thanos-ի պարզ սխեման։

Այժմ համեմատենք VictoriaMetrics-ի սխեմայի հետ։

VictoriaMetrics-ում կա 2 տարբերակ. Single-node և կլասթերյան տարբերակ։ Single-node-ն աշխատում է մեկ կոմպիուտերում։ Single-node-ում այս բաղադրիչները չկան, պարզապես մեկ երկուական ծածկագիր։ Այս երկուականը սահքում տեսնում եք այս քառակուսու մեջ։ Քառակուսու ներսում ամեն ինչ այն է, ինչի մեջ է Single-node տարբերակի երկուական ֆայլը։ Դուք պարտադիր չեք պետք է նրա մասին իմանաք։ Պարզապես գործարկեք այն — և ամեն ինչ աշխատում է։

Կլասթերյան տարբերակը ավելի բարդ է։ Այն ներառում է երեք տարբեր բաղադրիչներ. vmselect, vminsert և vmstorage։ Նրանց անվանումներից应 evident է, թե ինչ է անում յուրաքանչյուրը։ Insert բաղադրիչը ընդունում է տվյալները տարբեր ձևաչափերով՝ Prometheus remote write API-ից, Influx line էլեկտրոնային պրոտոկոլից, Graphite պրոտոկոլից և OpenTSDB պրոտոկոլից։ Insert բաղադրիչը ընդունում է դրանք, վերլուծում և բաժանում է արդեն հաճախորդ ապրանքի գոյություն ունեցող storage բաղադրիչներին, որտեղ տվյալները արդեն պահվում են։ Select բաղադրիչը, իր հերթին, ընդունում է PromQL հարցումներ։ Այն իրականացնում է PromQL, ինչպես նաև Prometheus հարցման API, և կարող է օգտագործվել որպես Prometheus-ի փոխարինում Grafana-ում կամ այլ Prometheus API հաճախորդներում։ Select-ը ընդունում է promql հարցումը, վերլուծում է այն, կարդում է անհրաժեշտ թվայնությունը տվյալների իրականացնելու համար տվյալ՝ storage կետից, գործարկում դրանք և 반환ություններիր պատասխան։

Մենք համեմատենք Thanos-ի և VictoriaMetrics-ի տեղադրման բարդությունը։

Սկ comenzar լինենք Thanos-ից։ Նախքան Thanos-ի հետ աշխատել սկսելը, պետք է ստեղծել bucket Object Storage-ում, ինչպես S3 կամ GCS, որպեսզի Thanos Sidecar-ը կարողանա այնտեղ գրել տվյալներ։

Այնուհետև յուրաքանչյուր Prometheus-ի համար պետք է տեղադրել Thanos Sidecar-ը։ Մինչ այդ պետք չէ մոռանալ անջատել data compaction-ը Prometheus-ում։ Data compaction-ը ժամանակ առ ժամանակ վարում է տվյալների սեղմումը Prometheus-ում, որպեսզի նվազեցնի ռեսուրսների սպառումը։

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

Հետևաբար, Thanos-ը խորհուրդ է տալիս նվազեցնել տվյալների պահպանումը տեղայնացված storage-ում 6–8 ժամ, որպեսզի կրճատվի այս փոքր փուլի մեծ քանակի overhead-ը։

Դուք պետք է Thanos Sidecar-ը տեղադրելուց հետո յուրաքանչյուր Object Storage Bucket-ի համար տեղադրեք երկու բաղադրիչներ։ Դրանք են Thanos Compactor-ը և Thanos Store Gateway-ը։

Այդուհետև պետք է տեղադրել Thanos Query և կարգավորել այն այնպես, որպեսզի կարողանա միանալ բոլոր Thanos Store Gateway-ներին, որոնք ունեք, ինչպես նաև կարողանա միանալ բոլոր Thanos Sidecar-ներին։

Այստեղ կարող է լինել փոքր-ինչ խնդիր։

Դուք պետք է կարգավորեք հուսալի և պաշտպանված միացում Thanos Query-ից այս բաղադրիչներին։ Եթե ձեր Prometheus-ները գտնվում են տարբեր տվյալների կենտրոններում կամ տարբեր VPC-ներում, ապա արտաքին łączenia արգելվում է։ Սակայն Thanos Query-ի աշխատանքի համար պետք է somehow կազմակերպել միացումը, և դուք պետք է մտածեք լուծման մասին։

Եթե դուք այդպիսի տվյալների կենտրոններ շատ ունեք, ապա, համապատասխանաբար, ամբողջ համակարգի հուսալիությունը նվազում է։ Քանի որ Thanos Query-ը պետք է շարունակաբար պահպանի միացումները բոլոր Thanos Sidecar-ներին, որոնք գտնվում են տարբեր հայկական կենտրոնների։ Յուրաքանչյուր incoming request-ով այն ուղղում է requests բոլոր Thanos Sidecar-ներին։ Եթե միացումը ընդհատվի, դուք կստանաք կամ ոչ ամբողջական տվյալների համալիր, կամ «кластер не работает» պատասխան։

VictoriaMetrics-ում ամեն բան մի քիչ ավելի հեշտ է։ Single-node տարբերակի համար բավական է պարզապես գործարկել մեկ բինար և ամեն ինչ աշխատում է։

Կլաստերային տարբերակում բավական է գործարկել բոլոր վերոհիշյալ երեք բաղադրիչները անհրաժեշտ քանակությամբ, կամ օգտագործել helm chart ոգեբանի ավտոմատացման համար Kubernetes-ում բաղադրիչների գործարկումը։ Մենք դեռ մեզ կառավարիչ ենք ծրագրավորում Kubernetes-ում։ Helm chart-ն իրականացնում է որոշ դեպքեր, և թույլ է տալիս ձեզ ինքնակնքել ձեր հիմունքը։ Օրինակ, այն թույլ է տալիս կրճատել storage node-ների քանակը, ինչը կարող է հանգեցնել տվյալների կորուստների։

Դուք պարզապես պետք է ձեր config-ում Prometheus-ի համար ավելացնել remote write url կարգավորումը, որպեսզի այն սկսի տվյալները գրանցել համաժամանակաբար տեղային storage-ին և remote storage-ին։ Как вы заметили, такая конфигурация должна работать намного надежнее по сравнению с конфигурацией Thanos. Нам не нужно держать подключение от VictoriaMetrics ко всем Prometheus'ам, потому что Prometheus’ы сами подключаются к VictoriaMetrics и передают данные։

Խոսենք Thanos-ի և VictoriaMetrics-ի սպասարկման մասին։

Thanos-ը պետք է հետևի Sidecar-ին, որպեսզի նրանք չդադարեցնեն տվյալների տեղադրումը Object Storage-ում: Նրանք կարող են կանգնեցնել տվյալների տեղադրումը загрузка սխալի հետևանքով, օրինակ, եթե դուք ժամանակավորապես կտրեք ցանցային միացյալությունը Object Storage-ի հետ, կամ Object Storage-ը ժամանակավորապես դառնա անհասանելի: Այս պահին Thanos Sidecar-ը կտեսնի դա, կներկայացնի սխալի մասին տեղեկություն, կարող է ընկնել և հետո դադարեցնել աշխատանքը: Եթե դուք չունեք այդ միջոցով, ապա ձեր տվյալները այլևս չեն իսկ լինելու Object Storage-ում: Եթե անցնի պահման ժամանակահատվածը ( rekomendovan 6-8 ժամ), ապա դուք կկորցնեք այն տվյալները, որոնք չեն հասել Object Storage:

Thanos-ի սompactor-ները կարող են դադարեցնել աշխատանքը ել պատճառներով Sidecar-ների հետ մրցակցային վիճակների պատճառով. Սompactor-ները վերցնում են տվյալները Object Storage-ից և միավորում են դրանք ավելի մեծ տվյալների բիթերի: Քանի որ սompactor-ները չեն համաժամեցված Sidecar-ների հետ, կարող է տեղի ունենալ հետևյալը: Sidecar-ը դեռ ավարտ نکردել է բլոկը, Compactor-ը որոշում է, որ այս բլոկը լիովին գրանցված է: Compactor-ը սկսում է կարդալ այն: Նա կարդում է բլոկը ամբողջական տեսքով, և դադարում է աշխատել: Աճել լրացուցիչ տեղեկությունների համար այստեղ.

Store Gateway-ը կարող է վերադարձնել հասկացող տվյալներ Compactor-ների և Sidecar-ների միջև մրցակցության պատճառով: Այստեղ նույնպես նման խնդիր է, քանի որ Store Gateway-ը չունի համաժամացում Compactor-ների և Sidecar-ների հետ: Այսպիսով, կարող են առաջանալ մրցակցային վիճակներ, երբ Store Gateway-ը չի տեսնում մաս տվյալների, կամ տեսնում է ավելորդ տվյալներ:

Query կոմպոնենտը Thanos-ում, ըստ հաստատման, վերադարձնում է մասնակի արդյունք, եթե որոշ Sidecar-ներ կամ Store Gateway-ը ժամանակավորապես անհասանելի են: Դուք կստանաք մաս տվյալների և նույնիսկ չեք իմանա, որ չեք ստացել բոլոր տվյալները: Սա աշխատանքային սկզբունքն է: Հարակից վիճակում VictoriaMetrics-ը վերադառնում է նշված տվյալները որպես մասնակի:

Thanos-ից տարբերվող, VictoriaMetrics-ը հազվադեպ է կորցնում տվյալները: MSRP-ի հետ VictoriaMetrics-ի միջև կապը ընդհատվելու դեպքում, խնդրի ոչ մի հարց չկա, քանի որ Prometheus-ը շարունակում է գրանցել նոր տվյալները Write Ahead Log-ում, որի չափը 2 ժամ է: Եթե դուք երկու ժամվա ընթացքում վերականգնել եք կապը VictoriaMetrics-ի հետ, ապա տվյալները չեն կորանա: Prometheus գիտ կարող է լրացնել տվյալները կապի վերահաստատումից հետո VictoriaMetrics-ի հետ:.

Thanos-ից տարբերվող, որը գրանցում է տվյալները օբյեկտային լրատվություն միայն երկու ժամվա ընթացքում, Prometheus-ը ավտոմատ կերպով կրկնակում է տվյալները remote write պրոտոկոլի միջոցով remote storage-ում, օրինակ VictoriaMetrics-ում: Դուք չեք ստիպված լինի կորցնել local storage-ը Prometheus-ում: Եթե անակնկալ կորցրեցիք local storage-ը, ամենավատ դեպքերում կկորցնեք վերջին վայրկյանների տվյալներ, որոնք չեն հասցրել գրանցվել remote storage-ում:

Kubernetes-ը ավտոմատ կերպով կառավարում է համակարգը՝ Thanos-ից տարբերվող: Thanos-ի բոլոր կոմպոնենտները դժվարությամբ են տեղավորվում մեկ Kubernetes համակարգի մեջ, համեմատած VictoriaMetrics-ի կլաստերային կոմպոնենտների հետ:

VictoriaMetrics-ն շատ հեշտ է կատարել նոր տարբերակի թարմացում։ Simple-պետք է ընդհատել VictoriaMetrics-ը, թարմացնել բինարները և նորից գործարկել։ SIGINT պրոցեսի միջոցով բացակայության դեպքում, բոլոր VictoriaMetrics բինարները կատարում են օրինական փակման գործընթաց։ Նրանք ճիշտ պահպանել են անհրաժեշտ տվյալները, ճիշտ փակել են մուտքային կապերը, որպեսզի ոչինչ չկորցնեն։ Ուստի, թարմացման ժամանակ դուք ոչինչ չեք կորստի։

VictoriaMetrics-ը շատ հեշտ է լայնացնել կլաստերները։ Просто добавляете необходимые компоненты и продолжаете работать.

Thanos-ի և VictoriaMetrics-ի մասին թաքնված վտանգները։

Thanos-ի հետ կապված որոշ թաքնված վտանգներ կան։ Prometheus-ը պետք է պահի տվյալները վերջին երկու ժամվա ընթացքում։ Եթե դրանք կորցվեն, դուք դրանք ամբողջովին կկորցնեք, քանի որ դրանք դեռ չպետք է հաշվառվեն Object Storage-ում, ինչպիսին է S3-ը։

Store Gateway կետը և նվազեցում կոմպոնենտը կարող են պահանջել շատ հիշողություն մեծ Object Storage-ով աշխատելու համար, եթե ուշագրավ շատ փոքր ֆայլեր պահվեն այնտեղ։ Ֆայլերի քանակը և ծավալը այնքան մեծ են, որքան Store Gateway-ի և նվազեցում կոմպոնենտի համար անհրաժեշտ оператив ճ mémoire-ն ՝ մետաինֆորմացիա պահպանելու համար։ Thanos-ը բազմաթիվ խնդիրներ ունի կապված այն հարցում, որ Store Gateway և նվազեցումը ընկնում են տվյալների միջին ծավալների դեպքում։.

Thanos-ը գովազդվում է, որ կարող է անհամեմատելիորեն առողջացնել ձեր Prometheus-ի քանակը։ Իրականում դա ճշմարտություն չէ։ Քանի որ բոլոր հարցումները անցնում են Query կոմպոնենթի միջոցով, որը պետք է մեկաժամյա հարցում կատարի բոլոր Store Gateway և բոլոր Sidecar կոմպոնենտների նկատմամբ, տվյալները դուրս քաշի և ապա պրեպրոցեսինգ անի։ Очевидно, что скорость запросов ограничена самым медленным слабым звеном, самым медленным Store Gateway либо самым медленным Sidecar։

Այս կոմպոնենտները կարող են անհավասարաչափ ծանրաբեռնվել։ Օրինակ, ունեք Prometheus, որը հավաքում է միլիոնավոր մետրիկաներ րոպեում։ Եվ կա Prometheus, որը հավաքում է հազարավոր մետրիկաներ րոպեում։ Prometheus, который собирает миллионы метрик в секунду, намного сильнее загружает сервер, на котором он работает։ Таким образом, Sidecar там работает медленнее. И вообще все там очень медленно работает. И Query компонент будет очень медленно оттуда данные вытягивать. Поэтому производительность вашего всего кластера будет ограничена этим медленным Sidecar-ом.

По умолчанию Thanos отдает частичные данные, если некоторые Sidecar’ы либо Store Gateway недоступны. Например, если у вас Sidecar’ы раскиданы по всему миру в разных дата-центрах, то вероятность разрыва соединения и недоступности компонентов сильно возрастает. Соответственно, в большинстве случаев вы будете получать частичные данные, даже не зная об этом.

VictoriaMetrics-ում նույնպես կան թաքնված վտանգներ։ Առաջին թաքնված վտանգն այն է, որ գոյություն ունի հնարավորություն, որը սահմանափակում է VictoriaMetrics-ի caches օգտագործվող оператив հիշողության քանակը։ По умолчанию она равна 60% оперативной памяти на машине, где VictoriaMetrics запущена либо 60% ОЗУ пода VictoriaMetrics в Kubernetes.

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

Երկրորդ ընտրանքը: Սա retentionPeriod է՝ ժամանակահատված, որն ըստ բաղադրիչի հետ կհամապատասխանի 1 ամսվա: Սա այն ժամանակահատվածն է, որի ընթացքում VictoriaMetrics-ը պահպանում է տվյալները: Այս ժամկետի ավարտին VictoriaMetrics-ը ջնջում է տվյալները:

Շատերը VictoriaMetrics-ը запускают առանց այս պարամետրերի, տվյալները գրանցում են մեկ ամսվա ընթացքում: Իսկ հետո հարցնում են՝ ինչու տվյալները բացակայում են նախորդ ամսվա համար: Որովհետև retentionPeriod-ի նախընտրությունը 1 ամիս է: Ուստի անհրաժեշտ է գիտակցել և սահմանել ճիշտ retentionPeriod:

Եկեք անցնենք յուրահատուկ հնարավորություններին:

Thanos-ն ունի такую фичу, как downsampling: 5-минутные և ժամական интервалы, որոնք հաճախ սխալ աշխատում են. Եթե փնտրեք և տեսնեք նրանց խնդիրը github-ում, այնտեղ շատ խնդիրներ կան, կապված այս downsampling-ի հետ, որը иногда սխալ աշխատում է, կամ աշխատում է այնպես, ինչպես սպասում են օգտվողները:

Thanos-ն ունի տվյալների դեդուպլիկաция для Prometheus HA pairs: Երբ երկու Prometheus-ները հավաքում են նույն մետրիկաները նույն տիրույթներից և Thanos-ը դրանք մանկանում է Object Storage- ում: Thanos-ը կարող է ճիշտ դեդուպլիկացնել այդ տվյալները, հակառակ դեպքում VictoriaMetrics-ի հետ:

Thanos-ում կա զգուշացումների բաղադրիչ, որը շետված էր Thanos-ի սխեմայում: Բայց դա չի խորհուրդվում օգտագործել production-ում.

Thanos-ի առավելությունն այն է, որ Thanos-ի և Prometheus-ի կոդը նույնական է: Thanos-ը և Prometheus-ը մշակվել են նույն մշակողների կողմից: Thanos-ի կամ Prometheus-ի բարելավումների դեպքում մյուս կողմը շահում է:

VictoriaMetrics-ի գլխավոր հատկանիշը MetricsQL-ն է: Սա VictoriaMetrics-ի ընդլայնումն է PromQL-ի համար, որի մասին ես խոսել եմ նախորդ մեծ մոնիտորինգի հանդիպմանը:

VictoriaMetrics-ն աջակցում է բազմաթիվ տարբեր պրոտոկոլներով տվյալների մուտքագրմանը: VictoriaMetrics-ը կարող է ընդունել տվյալներ ոչ միայն Prometheus-ից, այլև Influx, OpenTSDB և Graphite պրոտոկոլներով:

VictoriaMetrics-ի տվյալները սովորաբար շատ ավելի քիչ տարածք են զբաղեցնում Thanos-ի և Prometheus-ի համեմատ:

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

Մեկ այլ առավելություն VictoriaMetrics-ի ՝ այն արագության նկատմամբ օպտիմիզացնելն է:

Եկեք անցնենք ենթակառուցվածքի արժեքին:

Thanos-ի առավելություններից մեկն այն է, որ այն պահպանում է տվյալները object storage-ում, որը համեմատաբար էժան է:

Դիվիզաների պահպանումիս object storage-ում դուք պետք է վճարեք տվյալների գրելու և կարդալու գործողությունների համար (10 $ միլիոն գործողության համար): Երբ դուք գրանցում եք տվյալները object storage-ին, դուք վճարում եք Ձեր հոստինգի ծախսերը տվյալների ինտերնետ լիցքավորելու համար, եթե ձեր կլաստերը չի գտնվում AWS-ում՝ այնտեղ անվճար է: Երբ դուք կարդում եք տվյալները, դուք վճարում եք 10 $-ից 230 $-ի համար մեկ ՏԲ-ի: Սա կարող է էական լինել, եթե հաճախ հարցնում եք Thanos կլաստերներից պատմական տվյալները:

Thanos կլաստերի համար անհրաժեշտ է վճարել Compact, Store Gateway, Query բաղադրիչների համար, որոնք պահանջում են շատ հիշողություն, CPU մեծ ծավալների համար:

VictoriaMetrics-ում ծախսերը հետևյալն են: Եթե տվյալները պահվեն GCE HDD սկավառակներում, ապա դա կազմում է 40 $ մեկ ՏԲ-ի համար: VictoriaMetrics-ի համար բավական են սովորական HDD սկավառակները, չեն պահանջվում որևէ SSD, որոնք ավելի հինգ անգամ ավելի թանկ են: VictoriaMetrics-ը օպտիմիզացված է HDD-ների համար:

VictoriaMetrics-ի համար անհրաժեշտ են սերվերներ բաղադրիչների համար՝ կամ Single-node կամ կլաստերային բաղադրիչների համար, որոնք, ի տարբերություն Thanos բաղադրիչների, պահանջում են շատ ավելի քիչ CPU, RAM՝ հետևաբար, ավելի մատչելի կլինի:

Ինձ համար ներդրումային օրինակներ:

Thanos-ի ներդրման օրինակ է Gitlab: Gitlab-ը ամբողջությամբ աշխատում է Thanos-ի վրա: Բայց ամեն ինչ այնքան հարթ չէ։ Եթե նայենք նրանց issues, ապա կարելի է տեսնել, որ նրանց հետ մշտապես առաջանում են ինչ-որ օպերատիվ խնդիրներ Thanos-ի հետ: Store Gateway կամ Query բաղադրիչների համար հիշողությունը չի բավարարում: Նրանք մշտապես ստիպված են մեծացնել հիշողության չափը:

Դրա պատճառով բարձրանում են այս խնդիրների լուծման ծախսերը:

Մեկ այլ ներդրում, որը կարող է ավելի հաջող լինել, դա Improbable ընկերությունն է, որը սկսել է Thanos-ի մշակումը: Նրանք հրապարակել են Thanos-ի աղբյուրները: Improbable-ը ընկերություն է, որը զբաղվում է խաղային շարժիչների մշակմամբ:

VictoriaMetrics-ի հասարակական ներդրման օրինակներն են.

• wix.com, կայքերի պահեստարան
• Adidas-ը ներդնում է VictoriaMetrics և նույնիսկ զեկույց է ներկայացրել վերջին PromCon 2019-ում:
• TrafficStars՝ գովազդային ցանց
• Seznam.cz՝ հայտնի չեխական որոնողական համակարգ:

Թողյալ հոսքում անանուն ընկերություններ, որոնք ներկայումս չեմ կարող նշել: Նրանք համաձայնություն չեն տվել:

• Մեկ крупный խաղային մշակող: Այլևս, քան Improbable:
• Մեծ գրաֆիկական ծրագրային ապահովման մշակող:
• Մեծ ռուսական բանկ:
• Գերմանական քամու հաուեններ, որոնք հաջողությամբ փորձարկել են VictoriaMetrics: Այս արտադրողը ներդնում է VictoriaMetrics երկաթուղային տվյալների մոնիտորինգի համար, որոնք ստանում են 50 նմուշ՝ վարկանիշի համար յուրաքանչյուր միացված սենսորի համար: Յուրաքանչյուր քամու հաունում մի քանի հարյուր սենսորներ կան: Նրանք ունեն մի քանի հարյուր քամու հաուն:
• Ռուսական ավիաընկերություններ, որոնք ցանկանում են ներդնել VictoriaMetrics, բայց դեռ չեն կարողանում: Մենք նրանց հետ պայմանագրային փուլում ենք:

Ավելացման եզրակացություններ։

VictoriaMetrics և Thanos լուծում են նման խնդիրներ՝ տարբեր եղանակներով:

• Գլոբալ հարցման դիտում
• հորիզոնական ընդլայնում
• քանոնական պահպանություն

Շնորհակալություն։

Մեզ սպասում ենք մեր telegram ալիքում.

Պատասխանելու համար պետք է գրանցված օգտվող լինել։ Մուտք, խնդրում եմ։

Եթե Prometheus-ի երկարաժամկետ պահեստավորման համար ինչ եք օգտագործում:

• 35,3%Thanos6

• 0,0%Cortex0

• 0,0%M3DB0

• 41,2%VictoriaMetrics7

• 23,5%այլ4

17 օգտվող վարկ է տվել։ 16 օգտվող անմասն են մնացել։

Ընտանիք: habr.com