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

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

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

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

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

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

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

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

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

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

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

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

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 Тб до 300 Гб;
• имаме възможност да приемаме по 125 млн метрики в минута на сървъра (пикове по време на миграцията);
• прехвърлихме всички метрики на тридесетсекунден интервал на съхранение;
• получихме репликация на данни и отказоустойчивост;
• преминахме без време на спиране;
• за всичко похарчихме около 7 седмици.

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

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

1. ClickHouse не винаги пречита конфигурациите на момента, понякога трябва да се перезареди. Например, в случай с описанието на клъстера zookeeper в конфигурацията на ClickHouse — той не се прилага до перезареждане на clickhouse-server.
2. Не преминаваха големи заявки в ClickHouse, така че нашата връзка в graphite-clickhouse изглежда ето така:

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

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

Graphite+ClickHouse. Тагове

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

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

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

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

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