Баарына салам! Анын акыркы макала Мен микросервис архитектурасы үчүн модулдук мониторинг системасын уюштуруу жөнүндө жаздым. Эч нерсе токтобойт, биздин долбоор тынымсыз өсүүдө, ошондой эле сакталган метрикалардын саны да өсүүдө. Кантип биз Graphite+Whisperден Graphite+ClickHouseга өтүүнү жогорку жүктөө шарттарында уюштурганбыз, андан күтүүлөр жана кыскартылган миграциянын натыйжалары жөнүндө окуңуз.

Graphite+Whisperде метрикаларды сактоодон Graphite+ClickHouseга өтүүнү кантип уюштурганыбызды айтуудан мурун, мен мындай чечимди кабыл алуунун себептери жана биз көптөн бери жашап келген Whisperдин кемчиликтери жөнүндө маалымат бергим келет.

Graphite+Whisper көйгөйлөрү

1. Диск подсистемасына жогорку жүк

Өткөөл маалда болжол менен 1.5 миллион метрика бизге келип жатты. Мындай агым менен серверлерде дискти колдонуу ~30% түздү. Жалпысынан алганда, бул абдан алгылыктуу болду - баары туруктуу иштеди, тез жазылып, тез окулду... Өнүктүрүү топторунун бири жаңы функцияны чыгарып, бизге мүнөтүнө 10 миллион метрика жөнөтө баштаганга чейин. Мына ошондо дисктин подсистемасы күчөп, биз 100% колдонууну көрдүк. Көйгөй тез эле чечилди, бирок калдыктары калды.

2. Репликациянын жана ырааттуулуктун жоктугу

Кыязы, Graphite+Whisper колдонгон/колдонгон ар бир адамдай эле, катага чыдамдуулукту түзүү үчүн биз бир эле метрика агымын бир эле учурда бир нече Graphite серверине төктүк. Бул менен эч кандай өзгөчө көйгөйлөр болгон эмес - серверлердин бири кандайдыр бир себептерден улам бузулган учурга чейин. Кээде биз кулап калган серверди тез арада алып, карбон-с-релей анын кэшинен метрикаларды жүктөй алдык, бирок кээде андай эмес. Анан метрикада тешик бар эле, биз аны rsync менен толтурдук. Процедура бир топ узун болду. Жалгыз үнөмдөөчү ырайым - бул өтө сейрек болгон. Биз ошондой эле мезгил-мезгили менен метрикалардын туш келди топтомун алып, кластердин кошуна түйүндөрүндөгү ошол эле типтеги башкалар менен салыштырып турчубуз. Болжол менен 5% учурларда, бир нече баалуулуктар ар кандай болгон, бул биз абдан ыраазы болгон жок.

3. Чоң изи

Биз Graphite'де инфраструктураны гана эмес, бизнес метрикасын да жазгандыктан (жана азыр да Kubernetes метрикасынан), биз көбүнчө метрика бир нече маанини камтыган жана .wsp файлы бардык сактоону эске алуу менен түзүлгөн кырдаалды алабыз. жана алдын ала бөлүнгөн мейкиндикти ээлейт, бул биз үчүн ~2МБ болгон. Убакыттын өтүшү менен көптөгөн окшош файлдар пайда болуп, алар боюнча отчетторду түзүүдө бош пункттарды окуу көп убакытты жана ресурстарды талап кылганы менен көйгөй ого бетер курчуйт.

Мен дароо белгилеп кетким келет, жогоруда сүрөттөлгөн көйгөйлөр ар кандай ыкмаларды колдонуу менен жана натыйжалуулугун ар кандай даражада менен күрөшүүгө болот, бирок сиз канчалык көп маалымат ала баштасаңыз, алар ошончолук начарлайт.

Жогоруда айтылгандардын бардыгына ээ болуу (мурункуларды эске алуу менен макалалар), ошондой эле алынган көрсөткүчтөрдүн санынын тынымсыз өсүшү, бардык көрсөткүчтөрдү 30 секунд сактоо аралыгына өткөрүп берүү каалоосу. (зарыл болсо 10 секундага чейин), биз Whisperге келечектүү альтернатива катары Graphite+ClickHouse сынап көрүүнү чечтик.

Graphite+ClickHouse. Күтүүлөр

Яндекстин жигиттеринин бир нече жолугушууларына барып, окуп чыгышкан Habré боюнча бир нече макалалар, документтерди карап чыгып, ClickHouse'ду Graphite астында бириктирүү үчүн акылга сыярлык компоненттерди таап, биз чара көрүүнү чечтик!

Мен төмөнкүлөрдү алгым келет:

дисктин подсистемасынын колдонулушун 30%дан 5%ке чейин кыскартуу;
1 ТБдан 100 ГБ чейин ээлеген мейкиндиктин көлөмүн азайтуу;
серверге мүнөтүнө 100 миллион метрика кабыл алуу;
маалыматтарды репликациялоо жана катага чыдамдуулук кутудан тышкары;
бир жыл бою бул долбоор боюнча отура бербейт жана акылга сыярлык мөөнөттүн ичинде өтүү;
токтоосуз которуштуруу.

Абдан амбициялуу, туурабы?

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

Graphite протоколу аркылуу маалыматтарды алуу жана андан кийин аны ClickHouseга жаздыруу үчүн мен тандадым carbon-clickhouse (голанг).

ClickHouse акыркы релизи, туруктуу версия 1.1.54253, убакыт катар сактоо үчүн маалымат базасы катары тандалган. Аны менен иштөөдө көйгөйлөр бар болчу: журналдарга бир топ каталар төгүлүп, алар менен эмне кылуу керектиги так эмес. менен талкуулоодо Роман Ломоносов (carbon-clickhouse, graphite-clickhouse жана башка көптөгөн нерселердин автору) улуусу тандалды чыгаруу 1.1.54236. Каталар жок болду - баары бир жарылуу менен иштей баштады.

ClickHouse дайындарын окуу үчүн тандалган graphite-сlickhouse (голанг). Graphite үчүн API катары - карбонапи (голанг). ClickHouse таблицалардын ортосундагы репликацияны уюштуруу үчүн колдонулган зоотехник. Маршруттук метрика үчүн биз сүйүктүүбүздү таштап кеттик көмүртек-с-реле (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 кыймылдаткычы (репликацияланган) 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ке өтүү үзгүлтүксүз болушу керек; Демек, биз кандайдыр бир жол менен биздин бардык мониторинг тутумубузду колдонуучуларыбыз үчүн мүмкүн болушунча ачык-айкын жаңы сактагычка которууга туура келди.
Биз муну ушундай кылдык.

ClickHouse таблицаларынын репликациясына катышкан серверлердин биринин карбон-кликхаузуна метрикалардын кошумча агымын жөнөтүү үчүн carbon-c-relay эрежеси кошулду.
Биз питондо кичинекей скрипт жаздык, ал 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-сервери кайра жүктөлмөйүнчө колдонулган эмес.
Чоң 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 стекинде колдоо үчүн эмне жана кантип кылуу керектиги жөнүндө активдүү ойлонуп жатабыз.

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

Жогоруда сүрөттөлгөн инфраструктуранын негизинде биз аномалия детекторунун прототибин ишке ашырдык жана ал иштейт! Бирок ал жөнүндө кийинки макалада.

Жазылыңыз, өйдө жебени басыңыз жана бактылуу болуңуз!

Source: www.habr.com

Метрикаларды сактоо: биз Graphite+Whisperден Graphite+ClickHouseга кантип которулдук