Сайн уу! Түүний дотор Сүүлийн нийтлэл Би бичил үйлчилгээний архитектурт модульчлагдсан хяналтын системийг зохион байгуулах талаар бичсэн. Юу ч зогсохгүй, манай төсөл байнга өссөөр байгаа бөгөөд хадгалагдсан хэмжүүрүүдийн тоо ч мөн адил. Ачааллын өндөр нөхцөлд Graphite+Whisper-ээс Graphite+ClickHouse руу шилжих ажлыг бид хэрхэн зохион байгуулсан, үүнээс хүлээгдэж буй хүлээлт болон зүсэлтийн дагуу шилжилтийн үр дүнг уншина уу.

Бид Graphite+Whisper-д хэмжигдэхүүнүүдийг хадгалахаас Graphite+ClickHouse руу шилжих ажлыг хэрхэн зохион байгуулсан талаар ярихаас өмнө ийм шийдвэр гаргах болсон шалтгаан болон бидний удаан хугацаанд хамт амьдарч байсан Whisper-ийн сул талуудын талаар мэдээлэл өгөхийг хүсч байна.

Графит+Шивээний асуудлууд

1. Дискний дэд системийн ачаалал ихтэй

Шилжилтийн үед минут тутамд ойролцоогоор 1.5 сая хэмжүүр бидэнд ирж байсан. Ийм урсгалаар сервер дээрх дискний ашиглалт ~30% байсан. Ерөнхийдөө энэ нь нэлээд зөвшөөрөгдөхүйц байсан - бүх зүйл тогтвортой ажиллаж, хурдан бичигдсэн, хурдан уншсан ... Хөгжлийн багуудын нэг нь шинэ функцийг гаргаж, минут тутамд 10 сая хэмжигдэхүүнийг бидэнд илгээж эхлэх хүртэл. Тэр үед дискний дэд систем чангарч, бид 100% ашиглалтыг харсан. Асуудал хурдан шийдэгдсэн боловч үлдэгдэл үлдсэн.

2. Хуулбарлах, тууштай байх дутагдал

Graphite+Whisper ашигладаг/хэрэглэдэг бүх хүмүүсийн нэгэн адил бид алдааг тэсвэрлэх чадварыг бий болгохын тулд хэд хэдэн Graphite серверүүд дээр нэгэн зэрэг хэмжүүрийн урсгалыг асгасан байх магадлалтай. Ямар нэг шалтгаанаар серверүүдийн аль нэг нь эвдрэх хүртэл үүнтэй холбоотой ямар ч онцгой асуудал гараагүй. Заримдаа бид унасан серверийг хангалттай хурдан авч чадсан бөгөөд карбон-с-релей нь кэшээс хэмжигдэхүүнийг ачаалж чадсан ч заримдаа үгүй. Дараа нь хэмжигдэхүүнүүдэд нүх гарсан бөгөөд бид үүнийг rsync-ээр дүүргэсэн. Уг процедур нь нэлээд урт байсан. Цорын ганц авралын ач ивээл бол энэ нь маш ховор тохиолддог явдал байв. Мөн бид үе үе санамсаргүй хэмжигдэхүүнийг авч, кластерын зэргэлдээх зангилаанууд дээрх ижил төрлийн бусадтай харьцуулсан. Тохиолдлын 5% орчимд хэд хэдэн утгууд өөр байсан бөгөөд үүнд бид тийм ч таатай байгаагүй.

3. Том талбай

Бид Графит дээр зөвхөн дэд бүтцийг төдийгүй бизнесийн хэмжүүрүүдийг (мөн одоо Кубернетесээс авсан хэмжүүрүүдийг) бичдэг тул хэмжүүр нь хэдхэн утгыг агуулсан байх нөхцөлийг олж авдаг бөгөөд .wsp файл нь бүх хадгалалтыг харгалзан үүсгэгддэг. хугацаатай бөгөөд урьдчилан хуваарилсан зай эзэлдэг бөгөөд энэ нь бидний хувьд ~2MB байв. Цаг хугацаа өнгөрөх тусам олон ижил төстэй файлууд гарч ирдэг бөгөөд тэдгээр дээр тайлан гаргахдаа хоосон цэгүүдийг уншихад маш их цаг хугацаа, нөөц шаардагддаг тул асуудлыг улам хүндрүүлж байна.

Дээр дурдсан асуудлуудыг янз бүрийн аргаар, янз бүрийн үр дүнтэйгээр шийдвэрлэх боломжтой боловч та илүү их мэдээлэл хүлээн авч эхлэх тусам улам дорддог гэдгийг би нэн даруй тэмдэглэхийг хүсч байна.

Дээр дурдсан бүх зүйлтэй байх (өмнөхийг харгалзан үзэх). нийтлэл), түүнчлэн хүлээн авсан хэмжүүрүүдийн тоо тогтмол нэмэгдэж, бүх хэмжигдэхүүнийг 30 секундын хадгалалтын интервал руу шилжүүлэх хүсэл. (шаардлагатай бол 10 секунд хүртэл) бид Whisper-ийн ирээдүйтэй хувилбар болох Graphite+ClickHouse-г туршиж үзэхээр шийдсэн.

Graphite+ClickHouse. Хүлээлт

Yandex-ийн залуусын хэд хэдэн уулзалтад зочилж, уншсан Хабрегийн талаархи хэд хэдэн нийтлэл, баримт бичгийг судалж үзээд, ClickHouse-г Graphite дор холбох эрүүл саруул бүрэлдэхүүн хэсгүүдийг олж авсны дараа бид арга хэмжээ авахаар шийдсэн!

Би дараахь зүйлийг хүлээн авахыг хүсч байна.

дискний дэд системийн ашиглалтыг 30% -иас 5% хүртэл бууруулах;
эзэлсэн зайны хэмжээг 1 TB-ээс 100 ГБ хүртэл багасгах;
минут тутамд 100 сая хэмжигдэхүүнийг серверт хүлээн авах боломжтой байх;
өгөгдлийн хуулбар ба алдааг тэсвэрлэх чадвар;
энэ төсөл дээр нэг жил суухгүй, шилжилтийг боломжийн хугацаанд хийх;
зогсолтгүйгээр солих.

Их амбицтай, тийм үү?

Graphite+ClickHouse. Бүрэлдэхүүн хэсгүүд

Графит протоколоор өгөгдөл хүлээн авч, дараа нь ClickHouse-д бичихийн тулд би сонгосон нүүрстөрөгчийн даралтын байшин (голанг).

ClickHouse-ийн хамгийн сүүлийн хувилбар болох 1.1.54253 тогтвортой хувилбарыг цагийн цувааг хадгалах мэдээллийн сан болгон сонгосон. Түүнтэй ажиллахад бэрхшээлтэй тулгарсан: олон тооны алдаа лог руу цутгаж, тэдэнтэй юу хийх нь тодорхойгүй байв. -тай ярилцаж байна Роман Ломоносов (carbon-clickhouse, graphite-clickhouse болон бусад олон бүтээлийн зохиогч) ахмадыг сонгосон 1.1.54236 хувилбар. Алдаанууд алга болсон - бүх зүйл тэсрэлттэй ажиллаж эхлэв.

ClickHouse-аас өгөгдлийг уншихаар сонгосон графит-сlickhouse (голанг). Графитийн API болгон − карбонапи (голанг). ClickHouse-ийг хүснэгтүүдийн хооронд хуулбарлах ажлыг зохион байгуулахад ашигласан амьтны хүрээлэн. Чиглүүлэлтийн хэмжүүрийн хувьд бид хайртай хүнээ орхисон нүүрстөрөгч-с-реле (C) (өмнөх нийтлэлийг үзнэ үү).

Graphite+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 хөдөлгүүртэй (хуулбарласан) нөхцөлийн дагуу дүүргэсэн хүснэгт Нэгтгэх мод). Энэ хүснэгтэд ирж буй хэмжигдэхүүнүүдийн тоог 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

Graphite+ClickHouse. Бүрэлдэхүүн хэсгүүдийн харилцан үйлчлэлийн диаграм

Graphite+ClickHouse. Өгөгдлийн шилжилт

Энэхүү төслийн хүлээлтээс бидний санаж байгаагаар ClickHouse руу шилжих нь зогсолтгүй байх ёстой; үүний дагуу бид ямар нэгэн байдлаар хяналтын системийг бүхэлд нь шинэ хадгалах сан руу шилжүүлэх шаардлагатай болсон.
Бид үүнийг ингэж хийсэн.

ClickHouse хүснэгтүүдийг хуулбарлахад оролцож буй серверүүдийн аль нэгнийх нь нүүрстөрөгчийн кликхаус руу хэмжүүрийн нэмэлт урсгалыг илгээхийн тулд нүүрстөрөгч-c-relay-д дүрмийг нэмсэн.
Бид python хэл дээр жижиг скрипт бичсэн бөгөөд энэ нь whisper-dump номын санг ашиглан манай сангаас бүх .wsp файлуудыг уншиж, дээрх өгөгдлийг 24 хэлхээнд дээр дурдсан карбон-кликхаус руу илгээсэн. Carbon-clickhouse дахь хүлээн зөвшөөрөгдсөн хэмжигдэхүүнүүдийн тоо 125 сая / мин-д хүрсэн бөгөөд ClickHouse хөлсөө ч гаргаагүй.
Бид одоо байгаа хяналтын самбарт ашигласан функцуудыг дибаг хийх зорилгоор Графана-д тусдаа DataSource үүсгэсэн. Бид ашигласан функцүүдийн жагсаалтыг тодорхойлсон боловч тэдгээрийг карбонапид хэрэгжүүлээгүй. Бид эдгээр функцийг нэмж, карбонапи зохиогчдод PR илгээсэн (тэдэнд онцгой талархал илэрхийлье).
Тэнцвэржүүлэгчийн тохиргоонд унших ачааллыг солихын тулд бид төгсгөлийн цэгүүдийг графит-апи (Graphite+Whisper-д зориулсан API интерфейс)-ээс карбонапи болгон өөрчилсөн.

Graphite+ClickHouse. үр дүн

дискний дэд системийн ашиглалтыг 30% -иас 1% хүртэл бууруулсан;
эзэлсэн зайны хэмжээг 1 TB-ээс 300 ГБ хүртэл бууруулсан;
Бид сервер рүү минут тутамд 125 сая хэмжигдэхүүнийг хүлээн авах чадвартай (шилжилтийн үеийн оргил үе);
бүх хэмжигдэхүүнийг гучин секундын хадгалах интервал руу шилжүүлсэн;
хүлээн авсан өгөгдлийн хуулбар ба алдааг тэсвэрлэх чадвар;
сул зогсолтгүйгээр солигдсон;
Бүх зүйлийг дуусгахад 7 долоо хоног зарцуулсан.

Graphite+ClickHouse. Асуудлууд

Манай тохиолдолд зарим нэг алдаа дутагдал байсан. Шилжилтийн дараа бид ийм зүйлтэй тулгарсан.

ClickHouse үргэлж тохиргоог шууд уншдаггүй; заримдаа үүнийг дахин ачаалах шаардлагатай болдог. Жишээлбэл, ClickHouse тохиргоонд амьтны хүрээлэнгийн кластерын тайлбарын хувьд clickhouse-серверийг дахин ачаалах хүртэл ашиглаагүй.
Том хэмжээний ClickHouse хүсэлтүүд биелээгүй тул graphite-clickhouse-д манай ClickHouse холболтын мөр дараах байдалтай байна:
```
url = "http://localhost:8123/?max_query_size=268435456&max_ast_elements=1000000"
```
ClickHouse нь тогтвортой хувилбаруудын шинэ хувилбаруудыг ихэвчлэн гаргадаг; тэдгээр нь гэнэтийн зүйл агуулж болзошгүй: болгоомжтой байгаарай.
Kubernetes дахь динамикаар үүсгэгдсэн савнууд нь богино бөгөөд санамсаргүй ашиглалтын хугацаатай олон тооны хэмжүүрүүдийг илгээдэг. Ийм хэмжүүрүүдэд олон оноо байдаггүй бөгөөд орон зайд ямар ч асуудал гардаггүй. Гэхдээ асуулга үүсгэх үед ClickHouse нь "хэмжих" хүснэгтээс асар олон тооны ижил хэмжүүрүүдийг авдаг. Тохиолдлын 90% -д нь цонхны цаана (24 цаг) тэдгээрийн талаар мэдээлэл байдаггүй. Гэвч 'өгөгдлийн' хүснэгтээс энэ өгөгдлийг хайхад цаг хугацаа зарцуулагдаж, эцэст нь хугацаа дуусдаг. Энэ асуудлыг шийдэхийн тулд бид өдрийн турш тааралдсан хэмжүүрүүдийн талаархи мэдээллийг тусад нь авч эхэлсэн. Тиймээс динамикаар үүсгэгдсэн контейнеруудын тайланг (график) бүтээхдээ бид зөвхөн тухайн цонхонд тааралдсан хэмжигдэхүүнүүдийг асуудаг бөгөөд энэ нь тэдгээрт тайланг бүтээх ажлыг ихээхэн хурдасгадаг. Дээр дурдсан шийдлийн хувьд би цуглуулсан бал чулуу-клик байшин (салаа), үүнд date_metrics хүснэгттэй ажиллах хэрэгжилт орно.

Graphite+ClickHouse. Шошго

1.1.0 хувилбартай бол Graphite албан ёсны болсон дэмжих шошго. Мөн бид графит+кликхаус стек дэх энэхүү санаачлагыг дэмжихийн тулд юу, хэрхэн хийх талаар идэвхтэй бодож байна.

Graphite+ClickHouse. Аномали илрүүлэгч

Дээр дурдсан дэд бүтцэд үндэслэн бид аномали илрүүлэгчийн прототипийг хэрэгжүүлсэн бөгөөд энэ нь ажиллаж байна! Гэхдээ дараагийн нийтлэлд түүний тухай дэлгэрэнгүй.

Бүртгүүлж, дээш сумыг дарж, аз жаргалтай байгаарай!

Эх сурвалж: www.habr.com

Хэмжилтийн хадгалалт: бид хэрхэн Graphite+Whisper-ээс Graphite+ClickHouse руу шилжсэн