Metrikas glabāŔana: kā mēs pārgājām no Graphite+Whisper uz Graphite+ClickHouse

Sveiki visiem! Viņa pēdējais raksts Es rakstÄ«ju par modulāras uzraudzÄ«bas sistēmas organizÄ“Å”anu mikropakalpojumu arhitektÅ«rai. Nekas nestāv uz vietas, mÅ«su projekts nepārtraukti aug, un lÄ«dz ar to arÄ« saglabāto rādÄ«tāju skaits. Kā mēs organizējām pāreju no Graphite+Whisper uz Graphite+ClickHouse lielas slodzes apstākļos, lasiet par no tā izrietoÅ”ajām cerÄ«bām un migrācijas rezultātiem zem griezuma.

Metrikas glabāŔana: kā mēs pārgājām no Graphite+Whisper uz Graphite+ClickHouse

Pirms pastāstÄ«Å”u, kā mēs organizējām pāreju no metrikas saglabāŔanas Graphite+Whisper uz Graphite+ClickHouse, vēlos sniegt informāciju par Ŕāda lēmuma pieņemÅ”anas iemesliem un par Whisper trÅ«kumiem, ar kuriem mēs dzÄ«vojām ilgu laiku.

Grafīta+čukstu problēmas

1. Liela diska apakÅ”sistēmas slodze

Pārejas brÄ«dÄ« pie mums tika saņemti aptuveni 1.5 miljoni metrikas minÅ«tē. Pie Ŕādas plÅ«smas diska izmantoÅ”ana serveros bija ~30%. Kopumā tas bija diezgan pieņemami - viss darbojās stabili, tika ātri uzrakstÄ«ts, ātri tika lasÄ«ts... LÄ«dz viena no izstrādes komandām izlaida jaunu funkciju un sāka sÅ«tÄ«t mums 10 miljonus metriku minÅ«tē. Toreiz diska apakÅ”sistēma nostiprinājās, un mēs redzējām 100% izmantoÅ”anu. Problēma tika ātri atrisināta, bet palika atlikums.

2. Replikācijas un konsekvences trūkums

Visticamāk, tāpat kā visi, kas izmanto/izmanto Graphite+Whisper, mēs vienu un to paÅ”u metrikas straumi ielējām vairākos Graphite serveros vienlaikus, lai radÄ«tu kļūdu toleranci. Un ar Å”o nebija Ä«paÅ”u problēmu - lÄ«dz brÄ«dim, kad kāds no serveriem nez kāpēc avarēja. Dažreiz mums izdevās pietiekami ātri paņemt nokrituÅ”u serveri, un carbon-c-relay spēja ielādēt tajā rādÄ«tājus no keÅ”atmiņas, bet dažreiz ne. Un tad metrikā bija caurums, ko mēs aizpildÄ«jām ar rsync. ProcedÅ«ra bija diezgan ilga. VienÄ«gais glābiņŔ bija tas, ka tas notika ļoti reti. Mēs arÄ« periodiski paņēmām nejauÅ”u metrikas kopu un salÄ«dzinājām tās ar citiem tāda paÅ”a veida blakus esoÅ”ajiem klastera mezgliem. Apmēram 5% gadÄ«jumu vairākas vērtÄ«bas bija atŔķirÄ«gas, par ko mēs nebijām Ä«paÅ”i priecÄ«gi.

3. Liels nospiedums

Tā kā Graphite rakstām ne tikai infrastruktÅ«ru, bet arÄ« biznesa metriku (un tagad arÄ« Kubernetes metriku), diezgan bieži rodas situācija, kad metrikā ir tikai dažas vērtÄ«bas, un .wsp fails tiek izveidots, ņemot vērā visu saglabāŔanu. periodā, un aizņem iepriekÅ” atvēlētu vietu, kas mums bija ~2MB. Problēmu vēl vairāk saasina fakts, ka laika gaitā parādās daudz lÄ«dzÄ«gu failu, un, veidojot par tiem atskaites, tukÅ”o punktu lasÄ«Å”ana aizņem daudz laika un resursu.

TÅ«lÄ«t gribu atzÄ«mēt, ka iepriekÅ” aprakstÄ«tās problēmas var risināt, izmantojot dažādas metodes un ar dažādu efektivitātes pakāpi, taču, jo vairāk datu sākat saņemt, jo vairāk tās pasliktinās.

Ņemot vērā visu iepriekÅ” minēto (ņemot vērā iepriekŔējo Raksts), kā arÄ« pastāvÄ«gs saņemto rādÄ«tāju skaita pieaugums, vēlme visus rādÄ«tājus pārsÅ«tÄ«t uz 30 sekunžu glabāŔanas intervālu. (lÄ«dz 10 sekundēm, ja nepiecieÅ”ams), mēs nolēmām izmēģināt Graphite+ClickHouse kā daudzsoloÅ”u alternatÄ«vu Whisper.

Graphite+ClickHouse. Cerības

Apmeklējot vairākas Yandex puiÅ”u tikÅ”anās, lasÄ«jis pāris raksti par Habrē, izpētot dokumentāciju un atraduÅ”i saprātÄ«gas sastāvdaļas ClickHouse iesieÅ”anai zem Graphite, mēs nolēmām rÄ«koties!

Vēlos saņemt sekojoÅ”o:

  • samazināt diska apakÅ”sistēmas izmantoÅ”anu no 30% lÄ«dz 5%;
  • samazināt aizņemtās vietas daudzumu no 1 TB lÄ«dz 100 GB;
  • spēj saņemt serverÄ« 100 miljonus metrikas minÅ«tē;
  • datu pavairoÅ”ana un kļūdu tolerance no iepakojuma;
  • nesēdiet pie Ŕī projekta gadu un veiciet pāreju saprātÄ«gā laika posmā;
  • slēdzis bez dÄ«kstāves.

Diezgan ambiciozi, vai ne?

Graphite+ClickHouse. Sastāvdaļas

Lai saņemtu datus, izmantojot protokolu Graphite, un pēc tam reģistrētu tos ClickHouse, es izvēlējos oglekļa-clickhouse (golangs).

Par datu bāzi laikrindu glabāŔanai tika izvēlēta ClickHouse jaunākā versija, stabilā versija 1.1.54253. Strādājot ar to, radās problēmas: baļķos iegāzās kļūdu kalns, un nebija lÄ«dz galam skaidrs, ko ar tām darÄ«t. Diskusijā ar Romāns Lomonosovs (carbon-clickhouse, graphite-clickhouse un daudzu, daudzu citu autors) tika izvēlēts vecākais izlaidums 1.1.54236. Kļūdas pazuda ā€“ viss sāka darboties ar lielu triecienu.

AtlasÄ«ts, lai lasÄ«tu datus no ClickHouse grafÄ«ta-slickhouse (golangs). Kā grafÄ«ta API ā€” carbonapi (golangs). ClickHouse tika izmantots, lai organizētu replikāciju starp tabulām zoodārznieks. Par marÅ”rutÄ“Å”anas metriku mēs atstājām savu mīļoto oglekļa-c-relejs (C) (skatÄ«t iepriekŔējo rakstu).

Graphite+ClickHouse. Tabulas struktūra

ā€œgrafÄ«tsā€ ir datu bāze, ko izveidojām tabulu uzraudzÄ«bai.

ā€œgraphite.metricsā€ ā€” tabula ar ReplicatedReplacingMergeTree dzinēju (replicēts Aizstājot MergeTree). Å ajā tabulā tiek saglabāti metrikas nosaukumi un ceļi uz tiem.

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ā€ ā€” tabula ar ReplicatedGraphiteMergeTree dzinēju (replicēts GraphiteMergeTree). Å ajā tabulā tiek saglabātas metrikas vērtÄ«bas.

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ā€ ir nosacÄ«ti aizpildÄ«ta tabula ar programmu ReplicatedReplacingMergeTree. Å ajā tabulā ir ierakstÄ«ti visu to metrikas nosaukumi, kas tika konstatēti dienas laikā. Tās izveides iemesli ir aprakstÄ«ti sadaļā "Problēmas" Ŕī raksta beigās.

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ā€ ā€” tabula, kas aizpildÄ«ta atbilstoÅ”i nosacÄ«jumam ar ReplicatedAggregatingMergeTree dzinēju (replicēta AggregatingMergeTree). Å ajā tabulā ir reÄ£istrēts ienākoÅ”o metrikas skaits, kas sadalÄ«ts 4 ligzdoÅ”anas lÄ«meņos.

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. Komponentu mijiedarbības diagramma

Metrikas glabāŔana: kā mēs pārgājām no Graphite+Whisper uz Graphite+ClickHouse

Graphite+ClickHouse. Datu migrācija

Kā atceramies no Ŕī projekta cerÄ«bām, pārejai uz ClickHouse ir jānotiek bez dÄ«kstāvēm, lÄ«dz ar to mums nācās kaut kā pārslēgt visu mÅ«su uzraudzÄ«bas sistēmu uz jauno krātuvi, cik vien iespējams pārskatāmāk mÅ«su lietotājiem.
Tā mēs to izdarījām.

  • Carbon-c-relay ir pievienota kārtula, lai nosÅ«tÄ«tu papildu metrikas straumi uz vienu no serveriem, kas piedalās ClickHouse tabulu replikācijā.

  • Mēs uzrakstÄ«jām nelielu skriptu programmā python, kas, izmantojot whisper-dump bibliotēku, nolasÄ«ja visus .wsp failus no mÅ«su krātuves un nosÅ«tÄ«ja Å”os datus uz iepriekÅ” aprakstÄ«to oglekļa klikŔķu namu 24 pavedienos. Pieņemto metrikas vērtÄ«bu skaits oglekļa-clickhouse sasniedza 125 miljonus/min, un ClickHouse pat nesvÄ«da.

  • Grafana izveidojām atseviŔķu datu avotu, lai atkļūdotu esoÅ”ajos informācijas paneļos izmantotās funkcijas. Mēs identificējām izmantoto funkciju sarakstu, taču tās netika ieviestas Carbonapi. Mēs pievienojām Ŕīs funkcijas un nosÅ«tÄ«jām PR carbonapi autoriem (viņiem Ä«paÅ”s paldies).

  • Lai pārslēgtu lasÄ«Å”anas slodzi balansētāja iestatÄ«jumos, mēs mainÄ«jām galapunktus no grafÄ«ta-api (API saskarne Graphite+Whisper) uz carbonapi.

Graphite+ClickHouse. rezultātus

  • samazināta diska apakÅ”sistēmas izmantoÅ”ana no 30% lÄ«dz 1%;

    Metrikas glabāŔana: kā mēs pārgājām no Graphite+Whisper uz Graphite+ClickHouse

  • samazināts aizņemtās vietas apjoms no 1 TB lÄ«dz 300 GB;
  • mums ir iespēja saņemt serverÄ« 125 miljonus metrikas minÅ«tē (migrācijas laikā maksimums);
  • pārsÅ«tÄ«ja visus rādÄ«tājus uz trÄ«sdesmit sekunžu uzglabāŔanas intervālu;
  • saņemto datu replikācija un kļūdu tolerance;
  • pārslēgts bez dÄ«kstāves;
  • Lai visu paveiktu, vajadzēja apmēram 7 nedēļas.

Graphite+ClickHouse. Problēmas

Mūsu gadījumā bija dažas nepilnības. Ar to mēs saskārāmies pēc pārejas.

  1. ClickHouse ne vienmēr pārlasa konfigurācijas lidojuma laikā; dažreiz tas ir jāpārstartē. Piemēram, zookeeper klastera apraksta gadījumā ClickHouse konfigurācijā tas netika izmantots, līdz Clickhouse serveris tika pārstartēts.
  2. Lielie ClickHouse pieprasÄ«jumi netika izpildÄ«ti, tāpēc mÅ«su ClickHouse savienojuma virkne izskatās Ŕādi:
    url = "http://localhost:8123/?max_query_size=268435456&max_ast_elements=1000000"
  3. ClickHouse diezgan bieži izlaiž jaunas stabilu laidienu versijas, tās var saturēt pārsteigumus: esiet uzmanīgi.
  4. Dinamiski izveidotie konteineri pakalpojumā kubernetes nosÅ«ta lielu skaitu metrikas ar Ä«su un nejauÅ”u kalpoÅ”anas laiku. Šādiem rādÄ«tājiem nav daudz punktu, un nav problēmu ar vietu. Bet, veidojot vaicājumus, ClickHouse no ā€œmetrikuā€ tabulas iegÅ«st milzÄ«gu skaitu Å”o paÅ”u metrikas. 90% gadÄ«jumu par tiem nav datu ārpus loga (24 stundas). Taču laiks tiek pavadÄ«ts, meklējot Å”os datus ā€œdatuā€ tabulā, un galu galā iestājas taimauts. Lai atrisinātu Å”o problēmu, mēs sākām uzturēt atseviŔķu skatu ar informāciju par metriku, kas tika konstatēta dienas laikā. Tādējādi, veidojot pārskatus (grafikus) dinamiski izveidotiem konteineriem, mēs vaicājam tikai tos rādÄ«tājus, kas tika atrasti konkrētajā logā, nevis visu laiku, kas ievērojami paātrināja pārskatu veidoÅ”anu par tiem. IepriekÅ” aprakstÄ«tajam risinājumam es savācu grafÄ«ta klikŔķa māja (dakÅ”a), kas ietver darba ar tabulu date_metrics ievieÅ”anu.

Graphite+ClickHouse. Tagi

Ar versiju 1.1.0 Graphite kļuva oficiāls atbalsta tagus. Un mēs aktÄ«vi domājam par to, ko un kā darÄ«t, lai atbalstÄ«tu Å”o iniciatÄ«vu grafÄ«ts+clickhouse kaudzē.

Graphite+ClickHouse. Anomāliju detektors

Pamatojoties uz iepriekÅ” aprakstÄ«to infrastruktÅ«ru, esam ieviesuÅ”i anomāliju detektora prototipu, un tas darbojas! Bet vairāk par viņu nākamajā rakstā.

Abonējiet, nospiediet augÅ”upvērsto bultiņu un esiet laimÄ«gi!

Avots: www.habr.com

Pievieno komentāru