Здраво свима! У његовој последњи чланак Писао сам о организовању модуларног система за праћење микросервисне архитектуре. Ништа не мирује, наш пројекат стално расте, као и број сачуваних метрика. Како смо организовали прелазак са Грапхите+Вхиспер на Грапхите+ЦлицкХоусе под условима високог оптерећења, прочитајте о очекивањима од њега и резултатима миграције испод реза.

Складиштење метрика: како смо прешли са Грапхите+Вхиспер на Грапхите+ЦлицкХоусе

Пре него што вам кажем како смо организовали прелазак са чувања метрике у Грапхите+Вхиспер на Грапхите+ЦлицкХоусе, желео бих да дам информације о разлозима за доношење такве одлуке и о недостацима Вхиспера са којима смо дуго живели.

Грапхите+Вхиспер проблеми

1. Високо оптерећење подсистема диска

У време транзиције, отприлике 1.5 милиона метрика нам је стизало у минути. Са таквим током, искоришћеност диска на серверима је била ~30%. Генерално, ово је било сасвим прихватљиво – све је функционисало стабилно, брзо се писало, брзо читало... Све док један од развојних тимова није избацио нову функцију и почео да нам шаље 10 милиона метрика у минути. Тада се подсистем диска пооштрио и видели смо 100% искоришћеност. Проблем је брзо решен, али је остао талог.

2. Недостатак репликације и доследности

Највероватније, као и сви који користе/користе Грапхите+Вхиспер, прелили смо исти ток метрика на неколико Грапхите сервера одједном како бисмо створили толеранцију грешака. И није било посебних проблема са овим - све до тренутка када се један од сервера из неког разлога срушио. Понекад смо успели да покупимо пали сервер довољно брзо, а царбон-ц-релаи је успео да учита метрике из свог кеша у њега, али понекад не. А онда је настала рупа у метрици, коју смо попунили рсинц-ом. Процедура је била прилично дуга. Једина спасоносна милост је била што се то дешавало веома ретко. Такође смо повремено узимали насумични скуп метрика и упоређивали их са другима истог типа на суседним чворовима кластера. У око 5% случајева неколико вредности је било другачије, што нас није баш радовало.

3. Велики отисак

Пошто у Грапхите-у пишемо не само инфраструктуру, већ и пословну метрику (а сада и метрику из Кубернетеса), често долазимо до ситуације у којој метрика садржи само неколико вредности, а .всп датотека се креира узимајући у обзир све задржавање периода и заузима унапред додељену количину простора, што је за нас било ~2МБ. Проблем је додатно отежан чињеницом да се током времена појављује много сличних фајлова, а при изради извештаја о њима, читање празних тачака одузима много времена и ресурса.

Желео бих одмах да приметим да се горе описани проблеми могу решити различитим методама и са различитим степеном ефикасности, али што више података почнете да примате, то се више погоршавају.

Имајући све наведено (узимајући у обзир претходно Чланак), као и стално повећање броја примљених метрика, жеља да се све метрике пренесу у интервал складиштења од 30 секунди. (до 10 секунди ако је потребно), одлучили смо да испробамо Грапхите+ЦлицкХоусе као обећавајућу алтернативу Вхисперу.

Грапхите+ЦлицкХоусе. Очекивања

Посетивши неколико сусрета момака из Јандекса, прочитавши пар чланака о Хабреу, након што смо прошли кроз документацију и пронашли здраве компоненте за везивање ЦлицкХоусе под Грапхите, одлучили смо да предузмемо акцију!

Желим да добијем следеће:

смањити искоришћеност подсистема диска са 30% на 5%;
смањити количину заузетог простора са 1ТБ на 100ГБ;
бити у могућности да прими 100 милиона метрика у минути на сервер;
репликација података и толеранција грешака из кутије;
не седите на овом пројекту годину дана и извршите транзицију у разумном временском оквиру;
прекидач без застоја.

Прилично амбициозно, зар не?

Грапхите+ЦлицкХоусе. Компоненте

Одабрао сам да примам податке преко Грапхите протокола и накнадно их снимам у ЦлицкХоусе царбон-цлицкхоусе (голанг).

Најновија верзија ЦлицкХоусе-а, стабилна верзија 1.1.54253, изабрана је као база података за чување временских серија. Било је проблема при раду са њим: брдо грешака се слило у дневнике и није било сасвим јасно шта да се ради са њима. У дискусији са Роман Ломоносов (аутор царбон-цлицкхоусе-а, грапхите-цлицкхоусе-а и много, много других) изабран је старији издање 1.1.54236. Грешке су нестале - све је почело да ради са праском.

Изабрано за читање података из ЦлицкХоусе-а грапхите-слицкхоусе (голанг). Као АПИ за Грапхите − царбонапи (голанг). ЦлицкХоусе је коришћен за организовање репликације између табела чувар зоолошког врта. За метрику рутирања, оставили смо нашу вољену угљеник-ц-релеј (Ц) (погледајте претходни чланак).

Грапхите+ЦлицкХоусе. Структура табеле

„графит“ је база података коју смо креирали за праћење табела.

“грапхите.метрицс” - табела са РеплицатедРеплацингМергеТрее мотором (реплицирано РеплацеингМергеТрее). Ова табела чува називе метрика и путање до њих.

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);

“грапхите.дата” – табела са РеплицатедГрапхитеМергеТрее машином (реплицирано ГрапхитеМергеТрее). Ова табела чува метричке вредности.

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')

„грапхите.дате_метрицс“ је условно попуњена табела са РеплицатедРеплацингМергеТрее машином. Ова табела бележи називе свих метрика на које смо наишли током дана. Разлози за његово стварање описани су у одељку "Проблеми" на крају овог чланка.

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

“грапхите.дата_стат” - табела попуњена у складу са условом, са РеплицатедАггрегатингМергеТрее машином (реплицирано АггрегатингМергеТрее). Ова табела бележи број долазних метрика, подељених на 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

Грапхите+ЦлицкХоусе. Дијаграм интеракције компоненти

Складиштење метрика: како смо прешли са Грапхите+Вхиспер на Грапхите+ЦлицкХоусе

Грапхите+ЦлицкХоусе. Миграција података

Као што се сећамо из очекивања од овог пројекта, прелазак на ЦлицкХоусе би требало да буде без застоја, морали смо некако да пребацимо читав систем за праћење на ново складиште што је могуће транспарентније за наше кориснике.
Овако смо то урадили.

У царбон-ц-релаи је додато правило за слање додатног тока метрике у царбон-цлицкхоусе једног од сервера који учествују у репликацији ЦлицкХоусе табела.
Написали смо малу скрипту у Питхон-у, која је, користећи библиотеку шапат-думп, прочитала све .всп датотеке из нашег складишта и послала ове податке у горе описану царбон-цлицкхоусе у 24 нити. Број прихваћених метричких вредности у царбон-цлицкхоусе-у достигао је 125 милиона/мин, а ЦлицкХоусе се није ни ознојио.
Направили смо посебан извор података у Графани за отклањање грешака у функцијама које се користе у постојећим контролним таблама. Идентификовали смо листу функција које смо користили, али оне нису имплементиране у царбонапи. Додали смо ове функције и послали ПР ауторима царбонапија (посебно им хвала).
Да бисмо променили оптерећење читања у подешавањима балансера, променили смо крајње тачке са грапхите-апи (АПИ интерфејс за Грапхите+Вхиспер) у царбонапи.

Грапхите+ЦлицкХоусе. резултате

смањено коришћење дисковног подсистема са 30% на 1%;
смањио количину заузетог простора са 1 ТБ на 300 ГБ;
имамо могућност да примимо 125 милиона метрика у минути на сервер (врхунци у време миграције);
пренео све метрике у интервал складиштења од тридесет секунди;
репликација примљених података и толеранција грешака;
укључен без застоја;
Било је потребно око 7 недеља да се све заврши.

Грапхите+ЦлицкХоусе. Проблеми

У нашем случају, било је неких замки. То је оно са чим смо се сусрели након транзиције.

ЦлицкХоусе не чита увек конфигурације у ходу; На пример, у случају описа кластера зоокеепер у конфигурацији ЦлицкХоусе, није коришћен све док се кликхоусе-сервер није поново покренуо.
Велики ЦлицкХоусе захтеви нису прошли, тако да у грапхите-цлицкхоусеу наш ЦлицкХоусе низ везе изгледа овако:
```
url = "http://localhost:8123/?max_query_size=268435456&max_ast_elements=1000000"
```
ЦлицкХоусе прилично често објављује нове верзије стабилних издања, оне могу садржати изненађења: будите опрезни.
Динамички креирани контејнери у кубернетес-у шаљу велики број метрика са кратким и насумичним животним веком. Нема много поена за такве метрике, а нема проблема са простором. Али када правите упите, ЦлицкХоусе преузима огроман број ових истих метрика из табеле „метрика“. У 90% случајева нема података о њима изван прозора (24 сата). Али време се троши на тражење ових података у табели „подаци“ и на крају долази до истека времена. Да бисмо решили овај проблем, почели смо да одржавамо посебан приказ са информацијама о метрикама на које смо наишли током дана. Дакле, када правимо извештаје (графове) за динамички креиране контејнере, испитујемо само оне метрике на које смо наишли унутар датог прозора, а не за цело време, што је значајно убрзало израду извештаја о њима. За горе описано решење, сакупио сам графит-кликхоусе (виљушка), што укључује имплементацију рада са табелом дате_метрицс.

Грапхите+ЦлицкХоусе. Ознаке

Са верзијом 1.1.0 Грапхите је постао званичан ознаке подршке. И ми активно размишљамо о томе шта и како да урадимо да подржимо ову иницијативу у групи графит+кликхаус.

Грапхите+ЦлицкХоусе. Детектор аномалија

На основу горе описане инфраструктуре, имплементирали смо прототип детектора аномалија, и он ради! Али више о њему у следећем чланку.

Претплатите се, притисните стрелицу нагоре и будите срећни!

Извор: ввв.хабр.цом