Бәріңе сәлем! Оның ішінде соңғы мақала Мен микросервис архитектурасы үшін модульдік бақылау жүйесін ұйымдастыру туралы жаздым. Еш нәрсе орнында тұрмайды, біздің жобамыз үнемі өсіп келеді, сонымен қатар сақталған көрсеткіштердің саны да өсуде. Жоғары жүктеме жағдайында Graphite+Whisper-тен Graphite+ClickHouse-қа өтуді қалай ұйымдастырдық, одан күтулер және кесу астында көшу нәтижелері туралы оқыңыз.

Graphite+Whisper-де метрикаларды сақтаудан Graphite+ClickHouse-қа көшуді қалай ұйымдастырғанымызды айтпас бұрын, мен мұндай шешім қабылдаудың себептері және біз ұзақ уақыт бірге өмір сүрген Whisper-тің кемшіліктері туралы ақпарат бергім келеді.

Графит+Сыбыр мәселелері

1. Дискінің ішкі жүйесіндегі жоғары жүктеме

Өтпелі уақытта бізге минутына шамамен 1.5 миллион метрика келіп тұрды. Мұндай ағынмен серверлерде дискіні пайдалану ~ 30% құрады. Жалпы алғанда, бұл өте қолайлы болды - бәрі тұрақты жұмыс істеді, тез жазылды, тез оқылды... Әзірлеуші топтардың бірі жаңа мүмкіндікті шығарып, бізге минутына 10 миллион метрика жібере бастағанға дейін. Дәл сол кезде дискінің ішкі жүйесі күшейтіліп, біз 100% пайдалануды көрдік. Мәселе тез шешілді, бірақ қалдық қалды.

2. Репликация мен жүйеліліктің болмауы

Сірә, Graphite+Whisper қолданбасын пайдаланатын/пайдаланатындардың барлығы сияқты, ақауларға төзімділікті жасау үшін біз бірдей көрсеткіштер ағынын бірден бірнеше Graphite серверлеріне құйғанбыз. Бұған қатысты ерекше проблемалар болған жоқ - серверлердің бірі қандай да бір себептермен бұзылған сәтке дейін. Кейде біз құлаған серверді тез жинап алдық, ал carbon-c-relay оның кэшінен көрсеткіштерді жүктей алды, бірақ кейде олай емес. Содан кейін метрикада тесік пайда болды, біз оны rsync арқылы толтырдық. Процедура өте ұзақ болды. Жалғыз құтқарушы рақым - бұл өте сирек болатын. Біз сондай-ақ мерзімді түрде кездейсоқ көрсеткіштер жинағын алып, оларды кластердің көрші түйіндеріндегі сол түрдегі басқалармен салыстырдық. Шамамен 5% жағдайда бірнеше мәндер әртүрлі болды, бұл біз өте риза болмады.

3. Үлкен із

Біз Graphite-де тек инфрақұрылымды ғана емес, сонымен қатар іскери көрсеткіштерді де (және қазір де Kubernetes метрикасын) жазғандықтан, метрикада тек бірнеше мәндер бар және .wsp файлы барлық сақтауды ескере отырып жасалған жағдайды жиі аламыз. кезеңі және біз үшін ~2МБ болатын алдын ала бөлінген кеңістік көлемін алады. Уақыт өте келе көптеген ұқсас файлдардың пайда болуы және олар бойынша есептерді құру кезінде бос нүктелерді оқу көп уақыт пен ресурстарды қажет ететіндігі проблеманы одан әрі қиындатады.

Бірден атап өткім келеді, жоғарыда сипатталған проблемаларды әртүрлі әдістермен және әртүрлі тиімділік дәрежесімен шешуге болады, бірақ сіз неғұрлым көп деректер ала бастасаңыз, соғұрлым олар нашарлайды.

Жоғарыда айтылғандардың барлығына ие болу (алдыңғыны ескере отырып мақалалар), сондай-ақ алынған көрсеткіштер санының тұрақты өсуі, барлық көрсеткіштерді 30 секундтық сақтау аралығына тасымалдау тілегі. (қажет болған жағдайда 10 секундқа дейін) біз Whisper бағдарламасына перспективалы балама ретінде Graphite+ClickHouse қолданбасын қолданып көруді шештік.

Graphite+ClickHouse. Күтулер

Яндекс жігіттерінің бірнеше кездесулеріне барып, оқып шықтым Хабре туралы бірнеше мақала, құжаттаманы қарап шығып, ClickHouse қолданбасын Graphite астында байланыстыруға арналған ақылға қонымды компоненттерді тауып, біз әрекет етуді шештік!

Мен келесіні алғым келеді:

дискінің ішкі жүйесін пайдалануды 30%-дан 5%-ға дейін төмендету;
1 ТБ-дан 100 ГБ-қа дейін алып жатқан кеңістіктің көлемін азайту;
серверге минутына 100 миллион метриканы қабылдау мүмкіндігі;
қораптан тыс деректердің қайталануы және ақауларға төзімділігі;
бұл жобада бір жыл отырмаңыз және ақылға қонымды мерзімде көшуді жасаңыз;
тоқтаусыз ауысу.

Өте амбициялы, иә?

Graphite+ClickHouse. Құрамдас бөліктер

Деректерді Graphite протоколы арқылы алу және кейін оны ClickHouse жүйесінде жазу үшін мен таңдадым көміртек үйі (голанг).

Уақыт қатарын сақтауға арналған дерекқор ретінде ClickHouse соңғы шығарылымы, тұрақты нұсқасы 1.1.54253 таңдалды. Онымен жұмыс істеу кезінде қиындықтар туындады: бөренелерге көптеген қателер төгілді және олармен не істеу керектігі анық болмады. талқылауда Роман Ломоносов (carbon-clickhouse, graphite-clickhouse және көптеген басқалардың авторы) үлкені таңдалды. 1.1.54236 шығарылымы. Қателер жоғалып кетті - бәрі жарылыспен жұмыс істей бастады.

ClickHouse қолданбасынан деректерді оқу үшін таңдалған графит-сликхаус (голанг). Graphite үшін API ретінде − карбонапи (голанг). ClickHouse кестелер арасында репликацияны ұйымдастыру үшін пайдаланылды zookeeper. Маршрутизация көрсеткіштері үшін біз сүйіктімізді қалдырдық көміртек-с-релесі (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 кестелерінің репликациясына қатысатын серверлердің бірінің көміртегі кликханасына қосымша көрсеткіштер ағынын жіберу үшін carbon-c-relay ережесі қосылды.
Біз python тілінде шағын сценарий жаздық, ол whisper-dump кітапханасын пайдаланып, біздің қоймадағы барлық .wsp файлдарын оқиды және бұл деректерді 24 ағында жоғарыда сипатталған карбон-кликхаусқа жіберді. Carbon-clickhouse-да қабылданған метрикалық мәндердің саны 125 миллион/минутқа жетті, ал ClickHouse тіпті тер төкпеді.
Біз бұрыннан бар бақылау тақталарында қолданылатын функцияларды жөндеу үшін Grafana бағдарламасында бөлек DataSource жасадық. Біз пайдаланған функциялар тізімін анықтадық, бірақ олар карбонапиде орындалмады. Біз бұл функцияларды қосып, карбонапи авторларына PR жібердік (оларға ерекше рахмет).
Теңгерім параметрлеріндегі оқу жүктемесін ауыстыру үшін біз соңғы нүктелерді graphite-api-ден (Graphite+Whisper үшін API интерфейсі) карбонапиге ауыстырдық.

Graphite+ClickHouse. нәтижелер

дискінің ішкі жүйесін пайдалану 30%-дан 1%-ға дейін төмендеді;
1 ТБ-дан 300 ГБ-қа дейін алып жатқан кеңістік көлемін азайтты;
серверге минутына 125 миллион метрика алу мүмкіндігіміз бар (көшіру кезіндегі шыңдар);
барлық көрсеткіштерді отыз секундтық сақтау аралығына ауыстырды;
алынған деректердің қайталануы және ақауларға төзімділігі;
тоқтаусыз ауыстырылды;
Барлығын аяқтау үшін шамамен 7 апта қажет болды.

Graphite+ClickHouse. Мәселелер

Біздің жағдайда, кейбір тұзақтар болды. Бұл біз ауысқаннан кейін кездестірдік.

ClickHouse әрқашан конфигурацияларды жылдам қайта оқымайды; кейде оны қайта жүктеу қажет. Мысалы, ClickHouse конфигурациясындағы зоопарк кластерінің сипаттамасы жағдайында, ол кликхана сервері қайта жүктелмейінше пайдаланылмады.
Үлкен ClickHouse сұраулары орындалмады, сондықтан graphite-clickhouse жүйесінде ClickHouse қосылым жолы келесідей болады:
```
url = "http://localhost:8123/?max_query_size=268435456&max_ast_elements=1000000"
```
ClickHouse тұрақты шығарылымдардың жаңа нұсқаларын жиі шығарады; оларда тосынсыйлар болуы мүмкін: сақ болыңыз.
Кубернеттерде динамикалық түрде жасалған контейнерлер қысқа және кездейсоқ қызмет ету мерзімі бар көптеген көрсеткіштерді жібереді. Мұндай көрсеткіштер үшін көптеген нүктелер жоқ және кеңістікте проблемалар жоқ. Бірақ сұрауларды құру кезінде ClickHouse «метрикалар» кестесінен дәл осы көрсеткіштердің үлкен санын таңдайды. 90% жағдайда олар туралы терезеден тыс деректер жоқ (24 сағат). Бірақ бұл деректерді «деректер» кестесінде іздеуге уақыт жұмсалады және сайып келгенде күту уақыты аяқталады. Бұл мәселені шешу үшін біз күн ішінде кездесетін көрсеткіштер туралы ақпаратпен бөлек көріністі сақтай бастадық. Осылайша, динамикалық түрде жасалған контейнерлер үшін есептерді (графиктерді) құру кезінде біз олар бойынша есептерді құруды айтарлықтай жылдамдатқан бүкіл уақыт бойы емес, тек берілген терезеде кездесетін көрсеткіштерді ғана сұраймыз. Жоғарыда сипатталған шешім үшін мен жинадым графит-кликхаус (шанышқы), ол date_metrics кестесімен жұмыс істеуді қамтиды.

Graphite+ClickHouse. Тегтер

1.1.0 нұсқасымен Graphite ресми болды қолдау тегтері. Біз бұл бастаманы графит+кликхаус стекінде қолдау үшін не және қалай істеу керектігін белсенді түрде ойластырып жатырмыз.

Graphite+ClickHouse. Аномалия детекторы

Жоғарыда сипатталған инфрақұрылымның негізінде біз аномалия детекторының прототипін енгіздік және ол жұмыс істейді! Бірақ ол туралы толығырақ келесі мақалада.

Жазылыңыз, жоғары көрсеткіні басыңыз және бақытты болыңыз!

Ақпарат көзі: www.habr.com

Метрикаларды сақтау: біз Graphite+Whisper-тен Graphite+ClickHouse-ға қалай ауыстық