Здравейте всички! В неговия последната статия Писах за организиране на модулна система за наблюдение за архитектура на микросервизи. Нищо не стои неподвижно, нашият проект непрекъснато расте, както и броят на съхраняваните показатели. Как организирахме прехода от Graphite + Whisper към Graphite + ClickHouse при условия на високо натоварване, прочетете за очакванията от него и резултатите от миграцията под разреза.

Преди да ви разкажа как организирахме прехода от съхранение на метрики в Graphite + Whisper към Graphite + ClickHouse, бих искал да дам информация за причините за вземането на такова решение и за недостатъците на Whisper, с които живеехме дълго време.

Проблеми с Graphite+Whisper

1. Високо натоварване на дисковата подсистема

По време на прехода към нас летяха приблизително 1.5 милиона метрики на минута. С този поток използването на диска на сървърите беше ~30%. Като цяло беше доста приемливо - всичко работеше стабилно, пишеше се бързо, четеше се бързо ... Докато един от екипите за разработка не пусна нова функция и започна да ни изпраща 10 милиона метрики на минута. Тогава дисковата подсистема се стегна и видяхме 100% използване. Проблемът бързо се реши, но утайката остана.

2. Липса на репликация и последователност

Най-вероятно, както всеки, който използва / използва Graphite + Whisper, ние изляхме един и същ поток от показатели към няколко сървъра на Graphite наведнъж, за да създадем толерантност към грешки. И нямаше специални проблеми с това - до момента, в който един от сървърите не падна по някаква причина. Понякога успявахме да изведем повредения сървър достатъчно бързо и carbon-c-relay успяваше да го напълни с метрики от своя кеш, а понякога не. И тогава имаше дупка в показателите, която покрихме с rsync. Процедурата беше доста дълга. Спасява само фактът, че това се случва много рядко. Също така периодично вземахме произволен набор от показатели и ги сравнявахме с други подобни на съседни възли на клъстера. В около 5% от случаите няколко стойности се различаваха, което не ни направи много щастливи.

3. Голямо количество заето място

Тъй като ние пишем в Graphite не само инфраструктура, но и бизнес показатели (а сега и показатели от Kubernetes), доста често получаваме ситуация, в която има само няколко стойности в показателя, а .wsp файлът се създава, като отчита целия период на съхранение и заема предварително разпределено пространство, което имахме ~ 2 MB. Проблемът се утежнява от факта, че има много такива файлове с течение на времето и при изграждане на отчети върху тях четенето на празни точки отнема много време и ресурси.

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

Като имате всичко по-горе (като вземете предвид предишното статии), както и постоянно увеличаване на броя на получените метрики, желанието за прехвърляне на всички метрики към интервал на съхранение от 30 секунди. (до 10 секунди, ако е необходимо), решихме да изпробваме Graphite+ClickHouse като обещаваща алтернатива на Whisper.

Graphite+ClickHouse. очаквания

След като посетих няколко срещи на момчетата от Yandex, след като прочетох няколко статии на Хабре, след като прегледахме документацията и намерихме разумни компоненти за обвързване на ClickHouse под Graphite, решихме да действаме!

Бих искал да получи следното:

• намаляване на използването на дисковата подсистема от 30% на 5%;
• намаляване на заеманото пространство от 1TB на 100GB;
• да можете да получавате 100 милиона метрики на минута към сървъра;
• репликация на данни и толерантност към грешки извън кутията;
• не седите на този проект за една година и направете прехода за някакъв разумен период;
• превключване без престой.

Доста амбициозно, нали?

Graphite+ClickHouse. Компоненти

Избрах да получавам данни през протокола Graphite и след това да ги записвам в ClickHouse карбон-кликхаус (голанг).

Последното издание на ClickHouse на стабилната версия 1.1.54253 беше избрано като база данни за съхраняване на времеви редове. При работа с него имаше проблеми: планина от грешки се изсипа в регистрационните файлове и не беше съвсем ясно какво да се прави с тях. В дискусия с Роман Ломоносов (автор на carbon-clickhouse, graphite-clickhouse и много други) беше избран по-старият версия 1.1.54236. Грешките изчезнаха - всичко започна да работи с гръм и трясък.

За четене на данни от ClickHouse е избрано графит-кликхаус (голанг). Като API за Graphite − карбонапи (голанг). За организиране на репликация между таблици беше използван ClickHouse зоопарк. За показателите за маршрутизиране оставихме нашия любим въглеродно-с-реле (C) (виж предишната статия).

Graphite+ClickHouse. Структура на таблицата

“graphite” е база данни, която създадохме за мониторинг на таблици.

„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

Graphite+ClickHouse. Схема на взаимодействие на компонентите

Graphite+ClickHouse. Миграция на данни

Както си спомняме от очакванията от този проект, преходът към ClickHouse трябваше да бъде без престой, съответно трябваше по някакъв начин да превключим цялата си система за наблюдение към новото хранилище възможно най-прозрачно за нашите потребители.
Направихме го по този начин.

• Към carbon-c-relay беше добавено правило за изпращане на допълнителен поток от показатели към carbon-clickhouse на един от сървърите, участващи в репликацията на таблиците на ClickHouse.

• Написахме малък скрипт на Python, който, използвайки библиотеката whisper-dump, прочете всички .wsp файлове от нашето хранилище и изпрати тези данни до carbon-clickhouse, описан по-горе в 24 нишки. Броят на приетите метрични стойности в carbon-clickhouse достигна 125 милиона / мин., а ClickHouse дори не се поти.

• Създадохме отделен DataSource в Grafana, за да коригираме функциите, използвани в съществуващите табла за управление. Разкрихме списък с функции, които използвахме, но те не бяха внедрени в carbonapi. Завършихме тези функции и изпратихме PR до авторите на carbonapi (специални благодарности към тях).

• За да превключим натоварването при четене в настройките на балансира, променихме крайните точки от graphite-api (API интерфейс за Graphite+Whisper) на carbonapi.

Graphite+ClickHouse. резултати

• намалено използване на дисковата подсистема от 30% на 1%;

  

• намалено количеството заемано пространство от 1 TB на 300 GB;
• имаме способността да получаваме 125 милиона метрики на минута на сървър (пикове по време на миграция);
• прехвърли всички показатели на интервал от тридесет секунди за съхранение;
• репликация на получени данни и устойчивост на грешки;
• превключен без престой;
• Отне около 7 седмици за всичко.

Graphite+ClickHouse. проблеми

В нашия случай имаше някои клопки. Ето с какво се сблъскахме след прехода.

1. ClickHouse не винаги препрочита конфигурациите в движение, понякога трябва да се презареди. Например, в случая с описанието на клъстера zookeeper в конфигурацията на ClickHouse, то не беше приложено, докато сървърът на 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.

Graphite+ClickHouse. етикети

От версия 1.1.0 Graphite стана официална поддържащи етикети. И ние активно мислим какво и как да направим, за да подкрепим тази инициатива в стека graphite+clickhouse.

Graphite+ClickHouse. Детектор за аномалии

Въз основа на инфраструктурата, описана по-горе, внедрихме прототип на детектор на аномалии и той работи! Но за него - в следващата статия.

Абонирайте се, натиснете стрелката нагоре и бъдете щастливи!

Източник: www.habr.com