Здравейте на всички! В моя в предишната статия писах за организацията на модулна система за мониторинг на микросервисна архитектура. Нищо не стои на място, нашият проект постоянно расте, и броят на съхраняваните метрики също. Как организирахме прехода от 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Мб. Проблемът се усложнява и от факта, че с течение на времето появата на подобни файлове става много, а при изграждането на отчети за тях извличането на празни точки отнема много време и ресурси.

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

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

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

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

Искахме да постигнем следното:

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

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

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

За получаване на данни по протокола Graphite и последващото им записване в ClickHouse, беше избран carbon-clickhouse (golang).

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

За прочит на данни от ClickHouse беше избран graphite-slickhouse (golang). Като API интерфейс за Graphite — carbonapi (golang). За организиране на репликацията между таблиците ClickHouse беше използван zookeeper. За маршрутизация на метриките оставихме нашето обичано carbon-c-relay (C) (вж. предишната статия).

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

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

“graphite.metrics” — таблица с механизъм ReplicatedReplacingMergeTree (реплициран ReplacingMergeTree). В тази таблица се съхраняват имената на метриките и пътищата до тях.

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-server.
2. Не минавахме през големи заявки към ClickHouse, затова нашата връзка в graphite-clickhouse към ClickHouse изглежда така:

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

3. В ClickHouse доста често излизат нови версии на стабилни релизи, в тях могат да се срещнат изненади: бъдете внимателни.
4. Динамично създадените контейнери в Kubernetes изпращат голямо количество метрики с кратък и произволен живот. Точките по тези метрики не са много и проблеми с мястото нямаме. Но при изграждането на заявки, ClickHouse извлича огромно количество от същите тези метрики от таблица ‘metrics’. В 90% от случаите данните за тях отсъстват за периода (24 часа). А времето за търсене на тези данни в таблица ‘data’ е значително и в крайна сметка води до таймаут. За да решим този проблем, започнахме да поддържаме отделна изгледка с информация по метрики, които са се появили в рамките на един ден. Така при изграждането на отчети (графики) за динамично създадените контейнери, запитваме само тези метрики, които са били налични в зададения период, а не за цялото време, което значително ускори изграждането на отчети по тях. За посоченото решение беше събран graphite-clickhouse (форк), включващ реализация на работа с таблица date_metrics.

Graphite+ClickHouse. Тагове

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

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

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

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

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