Բարեւ բոլորին! Իր վերջին հոդվածը Ես գրել եմ միկրոսերվիսային ճարտարապետության մոդուլային մոնիտորինգի համակարգ կազմակերպելու մասին: Ոչինչ կանգ չի առնում, մեր նախագիծն անընդհատ աճում է, ինչպես նաև պահպանված ցուցանիշների թիվը: Ինչպես բարձր ծանրաբեռնվածության պայմաններում կազմակերպեցինք Graphite+Whisper-ից Graphite+ClickHouse-ի անցումը, կարդացեք դրանից ակնկալիքների և կրճատման տակ գտնվող միգրացիայի արդյունքների մասին։

Նախքան ձեզ պատմելը, թե ինչպես ենք կազմակերպել անցումը Graphite+Whisper-ում մետրերի պահպանումից դեպի Graphite+ClickHouse, ես կցանկանայի տեղեկատվություն տալ նման որոշման կայացման պատճառների և Whisper-ի թերությունների մասին, որոնց հետ մենք երկար ժամանակ ապրել ենք։

Գրաֆիտ+շշուկի խնդիրներ

1. Բարձր ծանրաբեռնվածություն սկավառակի ենթահամակարգի վրա

Անցման պահին մեզ մոտ րոպեում հասնում էր մոտավորապես 1.5 միլիոն չափումներ: Նման հոսքի դեպքում սերվերների վրա սկավառակի օգտագործումը կազմում էր ~30%: Ընդհանուր առմամբ, սա միանգամայն ընդունելի էր. ամեն ինչ կայուն էր աշխատում, արագ գրվում էր, արագ կարդացվում... Մինչև ծրագրավորող թիմերից մեկը նոր գործառույթ բացեց և սկսեց մեզ ուղարկել րոպեում 10 միլիոն չափումներ: Դա այն ժամանակ էր, երբ սկավառակի ենթահամակարգը խստացավ, և մենք տեսանք 100% օգտագործում: Խնդիրն արագ լուծվեց, բայց մնացորդ մնաց։

2. Կրկնօրինակման և հետևողականության բացակայություն

Ամենայն հավանականությամբ, ինչպես բոլոր նրանք, ովքեր օգտագործում/օգտագործում են Graphite+Whisper-ը, մենք նույն չափումների հոսքը թափեցինք միանգամից մի քանի Graphite սերվերների վրա՝ սխալների հանդուրժողականություն ստեղծելու համար: Եվ դրա հետ կապված առանձնահատուկ խնդիրներ չկային՝ մինչև այն պահը, երբ սերվերներից մեկը ինչ-ինչ պատճառներով խափանվեց: Երբեմն մեզ հաջողվում էր բավական արագ վերցնել ընկած սերվերը, և carbon-c-relay-ը կարողանում էր ներբեռնել չափումները իր քեշից դրա մեջ, բայց երբեմն ոչ: Եվ հետո չափումների մեջ անցք կար, որը մենք լրացրինք rsync-ով: Պրոցեդուրան բավականին երկար էր։ Միակ փրկող շնորհն այն էր, որ դա շատ հազվադեպ էր պատահում: Մենք նաև պարբերաբար վերցնում էինք չափումների պատահական հավաքածու և դրանք համեմատում նույն տեսակի մյուսների հետ կլաստերի հարևան հանգույցների վրա: Մոտ 5% դեպքերում մի քանի արժեքներ տարբեր էին, ինչը մեզ այնքան էլ ուրախ չէր։

3. Մեծ հետք

Քանի որ Graphite-ում գրում ենք ոչ միայն ենթակառուցվածքը, այլև բիզնեսի չափումները (և այժմ նաև չափումներ Kubernetes-ից), մենք հաճախ ստանում ենք մի իրավիճակ, երբ չափումը պարունակում է ընդամենը մի քանի արժեք, և .wsp ֆայլը ստեղծվում է հաշվի առնելով բոլոր պահպանումները: ժամանակահատվածում և զբաղեցնում է նախապես հատկացված տարածք, որը մեզ համար կազմում էր ~2MB: Խնդիրն ավելի է խորանում նրանով, որ ժամանակի ընթացքում բազմաթիվ նմանատիպ ֆայլեր են հայտնվում, և դրանց վրա հաշվետվություններ կազմելիս դատարկ կետեր կարդալը շատ ժամանակ և ռեսուրսներ է պահանջում:

Անմիջապես կուզենայի նշել, որ վերը նկարագրված խնդիրները կարելի է լուծել՝ օգտագործելով տարբեր մեթոդներ և արդյունավետության տարբեր աստիճաններ, բայց որքան շատ տվյալներ եք սկսում ստանալ, այնքան դրանք ավելի են վատանում:

Ունենալով վերը նշված բոլորը (հաշվի առնելով նախորդը Հոդված), ինչպես նաև ստացված չափումների քանակի անընդհատ աճ, բոլոր չափորոշիչները 30 վայրկյան պահեստավորման միջակայքում փոխանցելու ցանկություն: (անհրաժեշտության դեպքում մինչև 10 վայրկյան), մենք որոշեցինք փորձել Graphite+ClickHouse-ը՝ որպես Whisper-ի խոստումնալից այլընտրանք:

Գրաֆիտ+ClickHouse. Ակնկալիքներ

Այցելելով Yandex-ի տղաների մի քանի հանդիպումներ՝ կարդալով մի քանի հոդված Հաբրեի մասին, անցնելով փաստաթղթերի միջով և գտնելով խելամիտ բաղադրիչներ՝ ClickHouse-ը Graphite-ի տակ կապելու համար, մենք որոշեցինք քայլեր ձեռնարկել:

Ես կցանկանայի ստանալ հետևյալը.

• նվազեցնել սկավառակի ենթահամակարգի օգտագործումը 30% -ից մինչև 5%;
• նվազեցնել զբաղեցրած տարածքի քանակը 1TB-ից մինչև 100GB;
• կարողանալ րոպեում 100 միլիոն չափումներ ստանալ սերվերում.
• տվյալների կրկնօրինակում և սխալների հանդուրժողականություն տուփից դուրս;
• Մի նստեք այս նախագծի վրա մեկ տարի և անցում կատարեք ողջամիտ ժամկետում.
• միացնել առանց պարապուրդի:

Բավականին հավակնոտ, չէ՞:

Գրաֆիտ+ClickHouse. Բաղադրիչներ

Graphite արձանագրության միջոցով տվյալներ ստանալու և այնուհետև այն ClickHouse-ում գրանցելու համար ես ընտրել եմ carbon-clickhouse (գոլանգ):

ClickHouse-ի վերջին թողարկումը, կայուն տարբերակը 1.1.54253, ընտրվել է որպես ժամանակային շարքերը պահելու տվյալների բազա: Դրա հետ աշխատելիս խնդիրներ կային. սխալների սարը լցվեց գերանների մեջ, և ամբողջովին պարզ չէր, թե ինչ անել դրանց հետ: հետ քննարկման ժամանակ Ռոման Լոմոնոսով (carbon-clickhouse-ի, graphite-clickhouse-ի և շատ ու շատ այլ աշխատանքների հեղինակ) ընտրվել է ավելի հինը թողարկում 1.1.54236. Սխալները անհետացան. ամեն ինչ սկսեց աշխատել արագորեն:

Ընտրվել է ClickHouse-ից տվյալները կարդալու համար graphite-сlickhouse (գոլանգ): Որպես API գրաֆիտի համար − կարբոնապի (գոլանգ): ClickHouse-ն օգտագործվել է աղյուսակների միջև կրկնօրինակումը կազմակերպելու համար Zookeeper. Երթուղային չափումների համար մենք թողեցինք մեր սիրելիին carbon-c-ռելե (ՀԵՏ) (տես նախորդ հոդվածը).

Գրաֆիտ+ClickHouse. Սեղանի կառուցվածքը

«Գրաֆիտը» տվյալների բազա է, որը մենք ստեղծել ենք մոնիտորինգի աղյուսակների համար:

«graphite.metrics» - աղյուսակ ReplicatedReplacingMergeTree շարժիչով (կրկնօրինակված MergeTree-ի փոխարինում) Այս աղյուսակը պահպանում է չափումների անունները և դրանց տանող ուղիները:

CREATE TABLE graphite.metrics ( Date Date, Level UInt32, Path String, Deleted UInt8, Version UInt32 ) ENGINE = ReplicatedReplacingMergeTree('/clickhouse/tables/replicator/graphite.metrics', ‘r1’, Date, (Level, Path), 8192, Version);

«graphite.data» - աղյուսակ ReplicatedGraphiteMergeTree շարժիչով (կրկնօրինակված GraphiteMergeTree) Այս աղյուսակը պահպանում է մետրային արժեքները:

CREATE TABLE graphite.data ( Path String, Value Float64, Time UInt32, Date Date, Timestamp UInt32 ) ENGINE = ReplicatedGraphiteMergeTree('/clickhouse/tables/replicator/graphite.data', 'r1', Date, (Path, Time), 8192, 'graphite_rollup')

«graphite.date_metrics»-ը պայմանականորեն լրացված աղյուսակ է ReplicatedReplacingMergeTree շարժիչով: Այս աղյուսակը գրանցում է բոլոր ցուցանիշների անունները, որոնք հանդիպել են օրվա ընթացքում: Դրա ստեղծման պատճառները նկարագրված են բաժնում "Խնդիրներ" այս հոդվածի վերջում:

CREATE MATERIALIZED VIEW graphite.date_metrics ( Path String,  Level UInt32,  Date Date) ENGINE = ReplicatedReplacingMergeTree('/clickhouse/tables/replicator/graphite.date_metrics', 'r1', Date, (Level, Path, Date), 8192) AS SELECT toUInt32(length(splitByChar('.', Path))) AS Level, Date, Path FROM graphite.data

«graphite.data_stat» - ըստ պայմանի լրացված աղյուսակ՝ ReplicatedAggregatingMergeTree շարժիչով (կրկնօրինակված AggregatingMergeTree) Այս աղյուսակը գրանցում է մուտքային ցուցանիշների քանակը՝ բաժանված 4 բույնի մակարդակի:

CREATE MATERIALIZED VIEW graphite.data_stat ( Date Date,  Prefix String,  Timestamp UInt32,  Count AggregateFunction(count)) ENGINE = ReplicatedAggregatingMergeTree('/clickhouse/tables/replicator/graphite.data_stat', 'r1', Date, (Timestamp, Prefix), 8192) AS SELECT toStartOfMonth(now()) AS Date, replaceRegexpOne(Path, '^([^.]+.[^.]+.[^.]+).*$', '1') AS Prefix, toUInt32(toStartOfMinute(toDateTime(Timestamp))) AS Timestamp, countState() AS Count FROM graphite.data  GROUP BY Timestamp, Prefix

Գրաֆիտ+ClickHouse. Բաղադրիչների փոխազդեցության դիագրամ

Գրաֆիտ+ClickHouse. Տվյալների միգրացիա

Ինչպես հիշում ենք այս նախագծի ակնկալիքներից, ClickHouse-ին անցումը պետք է լինի առանց խափանումների, համապատասխանաբար, մենք պետք է ինչ-որ կերպ մեր օգտատերերի համար հնարավորինս թափանցիկ տեղափոխեինք մեր մոնիտորինգի ամբողջ համակարգը նոր պահեստին:
Ահա թե ինչպես մենք դա արեցինք.

• Carbon-c-relay-ին ավելացվել է կանոն՝ չափումների լրացուցիչ հոսք ուղարկելու ClickHouse աղյուսակների կրկնօրինակմանը մասնակցող սերվերներից մեկի carbon-clickhouse:

• Մենք գրեցինք մի փոքրիկ սցենար python-ում, որը, օգտագործելով whisper-dump գրադարանը, կարդում էր բոլոր .wsp ֆայլերը մեր պահեստից և ուղարկում այս տվյալները վերը նկարագրված carbon-clickhouse-ին 24 շղթաներով: Carbon-clickhouse-ում ընդունված մետրային արժեքների թիվը հասել է 125 միլիոն/րոպե, և ClickHouse-ը նույնիսկ չի քրտնել:

• Մենք Grafana-ում ստեղծեցինք առանձին DataSource՝ գոյություն ունեցող վահանակներում օգտագործվող գործառույթները վրիպազերծելու համար: Մենք բացահայտեցինք գործառույթների ցանկը, որոնք մենք օգտագործում էինք, բայց դրանք չեն իրականացվել կարբոնապիում: Մենք ավելացրեցինք այս գործառույթները և PR ուղարկեցինք կարբոնապիի հեղինակներին (հատուկ շնորհակալություն նրանց):

• Հավասարակշռիչի կարգավորումներում ընթերցման բեռը փոխելու համար մենք փոխեցինք վերջնակետերը graphite-api-ից (API ինտերֆեյս Graphite+Whisper-ի համար) կարբոնապիի:

Գրաֆիտ+ClickHouse. արդյունքները

• կրճատվել է սկավառակի ենթահամակարգի օգտագործումը 30% -ից մինչև 1%;

  

• նվազեցրեց զբաղեցրած տարածքի քանակը 1 ՏԲ-ից մինչև 300 ԳԲ;
• մենք հնարավորություն ունենք րոպեում 125 միլիոն չափումներ ստանալու սերվերում (միգրացիայի պահին գագաթնակետը);
• բոլոր չափումները փոխանցել է երեսուն վայրկյան պահպանման միջակայքին.
• ստացված տվյալների կրկնօրինակում և սխալների հանդուրժողականություն;
• միացված առանց պարապուրդի;
• Մոտ 7 շաբաթ պահանջվեց ամեն ինչ ավարտելու համար:

Գրաֆիտ+ClickHouse. Խնդիրներ

Մեր դեպքում որոշ թակարդներ կային. Սա այն է, ինչի հետ մենք հանդիպեցինք անցումից հետո։

1. ClickHouse-ը միշտ չէ, որ անմիջապես վերընթերցում է կազմաձևերը, երբեմն այն պետք է վերագործարկվի: Օրինակ, ClickHouse կոնֆիգուրայում zookeeper կլաստերի նկարագրության դեպքում այն ​​չի օգտագործվել մինչև clickhouse-սերվերի վերագործարկումը:
2. ClickHouse-ի մեծ հարցումները չեն անցել, ուստի graphite-clickhouse-ում մեր ClickHouse կապի տողը հետևյալն է.

   url = "http://localhost:8123/?max_query_size=268435456&max_ast_elements=1000000"

3. ClickHouse-ը բավականին հաճախ թողարկում է կայուն թողարկումների նոր տարբերակներ, դրանք կարող են անակնկալներ պարունակել. զգույշ եղեք:
4. Kubernetes-ում դինամիկ կերպով ստեղծված կոնտեյներները ուղարկում են մեծ թվով չափումներ՝ կարճ և պատահական կյանքով: Նման չափումների համար շատ միավորներ չկան, և տարածքի հետ կապված խնդիրներ չկան: Սակայն հարցումներ կառուցելիս ClickHouse-ը «չափանիշների» աղյուսակից վերցնում է այս նույն չափորոշիչների հսկայական քանակությունը: Դեպքերի 90%-ում պատուհանից այն կողմ (24 ժամ) դրանց մասին տվյալներ չկան։ Սակայն ժամանակը ծախսվում է «տվյալների» աղյուսակում այս տվյալները փնտրելու համար և, ի վերջո, սպառվում է ժամանակի ավարտին: Այս խնդիրը լուծելու համար մենք սկսեցինք առանձին դիտում ունենալ օրվա ընթացքում հանդիպող չափումների վերաբերյալ տեղեկություններով: Այսպիսով, դինամիկորեն ստեղծված բեռնարկղերի համար հաշվետվություններ (գրաֆիկներ) կառուցելիս մենք հարցում ենք անում միայն այն չափորոշիչներին, որոնք հանդիպել են տվյալ պատուհանում, և ոչ ամբողջ ժամանակի ընթացքում, ինչը զգալիորեն արագացրել է դրանց վերաբերյալ հաշվետվությունների կառուցումը: Վերը նկարագրված լուծման համար ես հավաքեցի graphite-clickhouse (պատառաքաղ), որը ներառում է date_metrics աղյուսակի հետ աշխատանքի իրականացում։

Գրաֆիտ+ClickHouse. Պիտակներ

1.1.0 տարբերակով Graphite-ը դարձավ պաշտոնական աջակցության պիտակներ. Եվ մենք ակտիվորեն մտածում ենք այն մասին, թե ինչ և ինչպես անել այս նախաձեռնությանը graphite+clickhouse stack-ում աջակցելու համար:

Գրաֆիտ+ClickHouse. Անոմալիայի դետեկտոր

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

Բաժանորդագրվեք, սեղմեք վերև սլաքը և ուրախացեք:

Source: www.habr.com