Salaam wote! Kwake makala ya mwisho Niliandika juu ya kuandaa mfumo wa ufuatiliaji wa kawaida wa usanifu wa huduma ndogo. Hakuna kinachosimama tuli, mradi wetu unakua kila wakati, na vile vile idadi ya vipimo vilivyohifadhiwa. Jinsi tulivyopanga mabadiliko kutoka kwa Graphite+Whisper hadi Graphite+ClickHouse chini ya hali ya juu ya mzigo, soma kuhusu matarajio kutoka kwayo na matokeo ya uhamiaji chini ya kukata.

Kabla sijakuambia jinsi tulivyopanga mageuzi kutoka kwa kuhifadhi vipimo katika Graphite+Whisper hadi Graphite+ClickHouse, ningependa kutoa maelezo kuhusu sababu za kufanya uamuzi kama huo na kuhusu hasara za Whisper ambazo tuliishi nazo kwa muda mrefu.

Matatizo ya Graphite+Whisper

1. Mzigo wa juu kwenye mfumo mdogo wa disk

Wakati wa mabadiliko, takriban metriki milioni 1.5 zilikuwa zikiwasili kwetu kwa dakika. Kwa mtiririko kama huo, utumiaji wa diski kwenye seva ulikuwa ~ 30%. Kwa ujumla, hii ilikubalika kabisa - kila kitu kilifanya kazi kwa utulivu, kiliandikwa haraka, kusoma haraka ... Hadi moja ya timu za maendeleo ilizindua kipengele kipya na kuanza kututumia metrics milioni 10 kwa dakika. Hapo ndipo mfumo mdogo wa diski uliimarishwa, na tuliona matumizi ya 100%. Tatizo lilitatuliwa haraka, lakini mabaki yalibaki.

2. Ukosefu wa kurudia na uthabiti

Uwezekano mkubwa zaidi, kama kila mtu anayetumia/kutumia Graphite+Whisper, tulimimina mtiririko sawa wa vipimo kwenye seva kadhaa za Graphite mara moja ili kuunda uvumilivu wa hitilafu. Na hakukuwa na shida maalum na hii - hadi wakati ambapo moja ya seva ilianguka kwa sababu fulani. Wakati mwingine tuliweza kuchukua seva iliyoanguka haraka vya kutosha, na kaboni-c-relay iliweza kupakia metriki kutoka kwa akiba yake ndani yake, lakini wakati mwingine sivyo. Na kisha kulikuwa na shimo kwenye metriki, ambayo tuliijaza na rsync. Utaratibu ulikuwa mrefu sana. Neema pekee ya kuokoa ilikuwa kwamba hii ilitokea mara chache sana. Pia mara kwa mara tulichukua seti nasibu ya vipimo na tukalinganisha na vingine vya aina sawa kwenye nodi za karibu za nguzo. Katika karibu 5% ya kesi, maadili kadhaa yalikuwa tofauti, ambayo hatukufurahiya sana.

3. Alama kubwa

Kwa kuwa tunaandika katika Graphite sio tu miundombinu, lakini pia metriki za biashara (na sasa pia metriki kutoka Kubernetes), mara nyingi tunapata hali ambayo kipimo kina maadili machache tu, na faili ya .wsp huundwa kwa kuzingatia uhifadhi wote. kipindi, na huchukua kiasi kilichotengwa awali cha nafasi, ambayo kwetu ilikuwa ~2MB. Tatizo linazidishwa zaidi na ukweli kwamba faili nyingi zinazofanana zinaonekana kwa muda, na wakati wa kujenga ripoti juu yao, kusoma pointi tupu huchukua muda mwingi na rasilimali.

Ningependa kutambua mara moja kwamba matatizo yaliyoelezwa hapo juu yanaweza kushughulikiwa kwa kutumia mbinu mbalimbali na kwa viwango tofauti vya ufanisi, lakini data zaidi unapoanza kupokea, ndivyo inavyozidi kuwa mbaya zaidi.

Kuwa na yote hapo juu (kwa kuzingatia yaliyotangulia nakala), pamoja na ongezeko la mara kwa mara la idadi ya vipimo vilivyopokelewa, hamu ya kuhamisha metrics zote kwa muda wa uhifadhi wa sekunde 30. (hadi sekunde 10 ikihitajika), tuliamua kujaribu Graphite+ClickHouse kama njia mbadala ya Whisper.

Graphite+ClickHouse. Matarajio

Baada ya kutembelea mikutano kadhaa ya wavulana kutoka Yandex, baada ya kusoma makala kadhaa kuhusu Habre, baada ya kupitia nyaraka na kupata vipengele vyema vya kumfunga ClickHouse chini ya Graphite, tuliamua kuchukua hatua!

Ningependa kupokea yafuatayo:

kupunguza matumizi ya mfumo mdogo wa disk kutoka 30% hadi 5%;
kupunguza kiasi cha nafasi iliyochukuliwa kutoka 1TB hadi 100GB;
kuwa na uwezo wa kupokea vipimo milioni 100 kwa dakika kwenye seva;
urudiaji wa data na uvumilivu wa makosa nje ya boksi;
usiketi kwenye mradi huu kwa mwaka na kufanya mabadiliko ndani ya muda unaofaa;
kubadili bila downtime.

Kutamani sana, sawa?

Graphite+ClickHouse. Vipengele

Ili kupokea data kupitia itifaki ya Graphite na baadaye kuirekodi kwenye ClickHouse, nilichagua kaboni-clickhouse (gonga).

Toleo la hivi punde la ClickHouse, toleo thabiti la 1.1.54253, lilichaguliwa kama hifadhidata ya kuhifadhi mfululizo wa saa. Kulikuwa na matatizo wakati wa kufanya kazi nayo: mlima wa makosa hutiwa ndani ya magogo, na haikuwa wazi kabisa nini cha kufanya nao. Katika majadiliano na Roman Lomonosov (mwandishi wa carbon-clickhouse, graphite-clickhouse na wengi, wengi zaidi) yule mzee alichaguliwa kutolewa 1.1.54236. Makosa yalipotea - kila kitu kilianza kufanya kazi na bang.

Imechaguliwa kusoma data kutoka kwa ClickHouse graphite-сlickhouse (gonga). Kama API ya Graphite - carbonapi (gonga). ClickHouse ilitumika kupanga urudufishaji kati ya jedwali mtunza zoo. Kwa vipimo vya uelekezaji, tulimwacha mpendwa wetu kaboni-c-relay (C) (tazama makala iliyotangulia).

Graphite+ClickHouse. Muundo wa meza

"graphite" ni hifadhidata tuliyounda kwa majedwali ya ufuatiliaji.

"graphite.metrics" - jedwali lililo na injini ya ReplicatedReplacingMergeTree (iliyoigwa KubadilishaMergeTree) Jedwali hili huhifadhi majina ya vipimo na njia kwao.

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" - jedwali lililo na injini ya ReplicatedGraphiteMergeTree (iliyoigwa GraphiteMergeTree) Jedwali hili huhifadhi thamani za kipimo.

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" ni jedwali lililojazwa kwa masharti na injini ya ReplicatedReplacingMergeTree. Jedwali hili hurekodi majina ya vipimo vyote vilivyopatikana wakati wa mchana. Sababu za kuundwa kwake zimeelezwa katika sehemu "Matatizo" mwishoni mwa makala hii.

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" - jedwali lililojazwa kulingana na hali, na injini ya ReplicatedAggregatingMergeTree (inakiliwa AggregatingMergeTree) Jedwali hili hurekodi idadi ya vipimo vinavyoingia, vilivyogawanywa hadi viwango 4 vya kuweka viota.

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. Mchoro wa mwingiliano wa sehemu

Graphite+ClickHouse. Uhamiaji wa data

Kama tunavyokumbuka kutokana na matarajio kutoka kwa mradi huu, mabadiliko ya kwenda kwa ClickHouse yanapaswa kuwa bila wakati wa kupungua; kwa hivyo, ilitubidi kwa njia fulani kubadili mfumo wetu wote wa ufuatiliaji hadi hifadhi mpya kwa uwazi iwezekanavyo kwa watumiaji wetu.
Hivi ndivyo tulivyofanya.

Sheria imeongezwa kwa kaboni-c-relay ili kutuma mtiririko wa ziada wa vipimo kwenye kibonyezo cha kaboni cha seva moja inayoshiriki katika urudufishaji wa jedwali la ClickHouse.
Tuliandika hati ndogo katika python, ambayo, kwa kutumia maktaba ya whisper-dump, ilisoma faili zote za .wsp kutoka kwenye hifadhi yetu na tukatuma data hii kwenye kibofyo cha kaboni kilichoelezwa hapo juu katika nyuzi 24. Idadi ya viwango vinavyokubalika vya metriki katika kaboni-clickhouse ilifikia milioni 125 kwa dakika, na ClickHouse haikutokwa na jasho.
Tumeunda Chanzo tofauti cha Data huko Grafana ili kutatua hitilafu zinazotumika katika dashibodi zilizopo. Tulitambua orodha ya chaguo za kukokotoa ambazo tulitumia, lakini hazikutekelezwa katika carbonapi. Tuliongeza kazi hizi na kutuma PRs kwa waandishi wa carbonapi (shukrani maalum kwao).
Ili kubadilisha mzigo wa kusoma katika mipangilio ya kusawazisha, tulibadilisha sehemu za mwisho kutoka kwa grafiti-api (kiolesura cha API cha Graphite+Whisper) hadi carbonapi.

Graphite+ClickHouse. matokeo

kupunguza matumizi ya mfumo mdogo wa disk kutoka 30% hadi 1%;
kupunguza kiasi cha nafasi iliyochukuliwa kutoka 1 TB hadi GB 300;
tuna uwezo wa kupokea metriki milioni 125 kwa dakika kwenye seva (kilele wakati wa kuhama);
ilihamisha vipimo vyote kwa muda wa uhifadhi wa thelathini na mbili;
kupokea replication ya data na uvumilivu wa makosa;
switched bila downtime;
Ilichukua kama wiki 7 kukamilisha kila kitu.

Graphite+ClickHouse. Matatizo

Kwa upande wetu, kulikuwa na mapungufu. Haya ndiyo tuliyokutana nayo baada ya mpito.

ClickHouse haisome tena usanidi kila wakati; wakati mwingine inahitaji kuwashwa upya. Kwa mfano, katika kesi ya maelezo ya kundi la watunza bustani katika usanidi wa ClickHouse, haikutumika hadi seva ya kubofya ilipowashwa upya.
Maombi makubwa ya ClickHouse hayakupitia, kwa hivyo kwenye graphite-clickhouse kamba yetu ya unganisho ya ClickHouse inaonekana kama hii:
```
url = "http://localhost:8123/?max_query_size=268435456&max_ast_elements=1000000"
```
ClickHouse mara nyingi hutoa matoleo mapya ya matoleo thabiti; yanaweza kuwa na mshangao: kuwa mwangalifu.
Vyombo vilivyoundwa kwa ubadilikaji katika kubernetes hutuma idadi kubwa ya vipimo kwa muda mfupi na bila mpangilio. Hakuna pointi nyingi za vipimo hivyo, na hakuna matatizo na nafasi. Lakini wakati wa kuunda hoja, ClickHouse huchukua idadi kubwa ya vipimo hivi kutoka kwa jedwali la 'metrics'. Katika 90% ya kesi, hakuna data juu yao zaidi ya dirisha (masaa 24). Lakini muda unatumika kutafuta data hii kwenye jedwali la 'data', na hatimaye hupita katika muda wa kuisha. Ili kusuluhisha tatizo hili, tulianza kudumisha mtazamo tofauti na maelezo kuhusu vipimo ambavyo vilipatikana mchana. Kwa hivyo, wakati wa kujenga ripoti (grafu) za vyombo vilivyoundwa kwa nguvu, tunauliza tu metriki ambazo zilikutana ndani ya dirisha fulani, na sio kwa wakati wote, ambayo iliharakisha sana ujenzi wa ripoti juu yao. Kwa suluhisho lililoelezwa hapo juu, nilikusanya grafiti-clickhouse (uma), ambayo inajumuisha utekelezaji wa kufanya kazi na jedwali la date_metrics.

Graphite+ClickHouse. Lebo

Kwa toleo la 1.1.0 Graphite ikawa rasmi vitambulisho vya msaada. Na tunafikiria kwa bidii juu ya nini na jinsi ya kufanya ili kuunga mkono mpango huu katika mrundikano wa graphite+clickhouse.

Graphite+ClickHouse. Kigunduzi kisicho cha kawaida

Kulingana na miundombinu iliyoelezwa hapo juu, tumetekeleza mfano wa detector isiyo ya kawaida, na inafanya kazi! Lakini zaidi juu yake katika makala inayofuata.

Jisajili, bonyeza kishale cha juu na ufurahie!

Chanzo: mapenzi.com

Hifadhi ya vipimo: jinsi tulivyobadilisha kutoka Graphite+Whisper hadi Graphite+ClickHouse