Mõõdikute salvestamine: kuidas me läksime Graphite+Whisperilt Graphite+ClickHouse'i

Tere kõigile! Tema omas viimane artikkel Kirjutasin mikroteenuste arhitektuuri modulaarse jälgimissüsteemi korraldamisest. Miski ei seisa paigal, meie projekt kasvab pidevalt ja samuti ka salvestatud mõõdikute arv. Kuidas korraldasime suure koormuse tingimustes üleminekut Graphite + Whisperilt Graphite + ClickHouse'ile, lugege sellest tulenevaid ootusi ja lõike all toimunud migratsiooni tulemusi.

Mõõdikute salvestamine: kuidas me läksime Graphite+Whisperilt Graphite+ClickHouse'i

Enne kui ma räägin teile, kuidas me korraldasime ülemineku mõõdikute salvestamiselt Graphite + Whisperis Graphite + ClickHouse'ile, tahaksin anda teavet sellise otsuse tegemise põhjuste ja Whisperi puuduste kohta, millega me pikka aega elasime.

Grafiit+sosin probleemid

1. Ketta alamsüsteemi suur koormus

Ülemineku ajal lendas meieni umbes 1.5 miljonit mõõdikut minutis. Selle voo korral oli ketta kasutamine serverites ~30%. Üldiselt oli see üsna vastuvõetav – kõik töötas stabiilselt, kirjutati kiiresti, loeti kiiresti ... Kuni üks arendusmeeskondadest võttis kasutusele uue funktsiooni ja hakkas meile saatma 10 miljonit mõõdikut minutis. See oli siis, kui ketta alamsüsteem tihenes ja me nägime 100% kasutust. Probleem lahenes kiiresti, kuid sete jäi alles.

2. Replikatsiooni ja järjepidevuse puudumine

Tõenäoliselt, nagu kõik, kes kasutavad/kasutavad Graphite + Whisperit, valasime veataluvuse loomiseks sama mõõdikuvoo korraga mitmesse Graphite'i serverisse. Ja sellega ei olnud erilisi probleeme - kuni hetkeni, mil üks serveritest mingil põhjusel ei kukkunud. Mõnikord õnnestus meil kukkunud server piisavalt kiiresti üles tuua ja carbon-c-relay suutis selle vahemälust mõõdikutega täita, mõnikord aga mitte. Ja siis oli mõõdikutes auk, mille rsynciga katsime. Protseduur oli üsna pikk. Päästis ainult see, et seda juhtus väga harva. Võtsime perioodiliselt ka juhusliku mõõdikukomplekti ja võrdlesime neid klastri naabersõlmede sarnaste näitajatega. Umbes 5% juhtudest erinesid mitmed väärtused, mis meid eriti ei rõõmustanud.

3. Suur hulk ruumi hõivatud

Kuna me kirjutame Graphite'is mitte ainult infrastruktuuri, vaid ka ärimõõdikuid (ja nüüd ka Kubernetese mõõdikuid), tekib üsna sageli olukord, kus mõõdikus on vaid mõned väärtused ja .wsp-fail luuakse, võttes arvesse võtab arvesse kogu säilitusperioodi ja võtab eelnevalt eraldatud ruumi, mida meil oli ~ 2 MB. Probleemi süvendab asjaolu, et selliseid faile on aja jooksul palju ja nende kohta aruannete koostamisel võtab tühjade punktide lugemine palju aega ja ressursse.

Tahaksin kohe märkida, et ülalkirjeldatud probleeme saab lahendada erinevate meetoditega ja erineva efektiivsusega, kuid mida rohkem andmeid hakkate saama, seda rohkem need süvenevad.

Omades kõike ülaltoodut (võttes arvesse eelmist artiklid), samuti vastuvõetud mõõdikute arvu pidev suurenemine, soov kanda kõik mõõdikud üle 30-sekundilisele salvestusintervallile. (vajadusel kuni 10 sekundit), otsustasime proovida Graphite+ClickHouse'i kui paljulubavat alternatiivi Whisperile.

Grafiit+ClickHouse. ootustele

Olles külastanud mitmeid Yandexi poiste kohtumisi, lugenud paar artiklit Habré kohta, olles läbinud dokumentatsiooni ja leidnud mõistlikud komponendid ClickHouse'i Graphite'i alla sidumiseks, otsustasime tegutseda!

Tahtsin saada järgmist:

  • vähendada ketta alamsüsteemi kasutamist 30%-lt 5%-le;
  • vähendage hõivatud ruumi mahtu 1 TB-lt 100 GB-le;
  • suutma serverisse vastu võtta 100 miljonit mõõdikut minutis;
  • andmete replikatsioon ja rikketaluvus karbist väljas;
  • ärge istuge selle projekti kallal aasta ja tehke üleminek mõneks mõistlikuks perioodiks;
  • lüliti ilma seisakuta.

Päris ambitsioonikas, eks?

Grafiit+ClickHouse. Komponendid

Andmete saamiseks Graphite protokolli kaudu ja seejärel ClickHouse'i kirjutamiseks valisin süsinik-clickhouse (golang).

Aegridade salvestamise andmebaasiks valiti stabiilse versiooni 1.1.54253 viimane ClickHouse'i väljalase. Sellega töötades tekkis probleeme: palkide sisse voolas mägi vigu ja polnud päris selge, mida nendega peale hakata. Arutelus koos Roman Lomonosov (carbon-clickhouse, graphite-clickhouse ja palju muu autor) valiti vanem väljalase 1.1.54236. Vead kadusid – kõik hakkas pauguga tööle.

Andmete lugemiseks valiti ClickHouse grafiit-clickhouse (golang). Grafiidi API-na – carbonapi (golang). Tabelitevahelise replikatsiooni korraldamiseks kasutati ClickHouse'i loomaaiaomanik. Marsruutimise mõõdikute jaoks jätsime oma armastatud süsinik-c-relee (C) (vt eelmist artiklit).

Grafiit+ClickHouse. Tabeli struktuur

“grafiit” on andmebaas, mille lõime tabelite jälgimiseks.

"graphite.metrics" on tabel mootoriga ReplicatedReplacingMergeTree (replitseeritud MergeTree asendamine). See tabel salvestab mõõdikute nimed ja teed nendeni.

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" on tabel ReplicatedGraphiteMergeTree mootoriga (replitseeritud GraphiteMergeTree). See tabel salvestab mõõdikute väärtused.

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" on tingimuslikult täidetud tabel mootoriga ReplicatedReplacingMergeTree. See tabel sisaldab kõigi päeva jooksul esinenud mõõdikute nimesid. Loomise põhjuseid kirjeldatakse jaotises "Probleemid" selle artikli lõpus.

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" on tingimustabel mootoriga ReplicatedAggregatingMergeTree (replitseeritud AggregatingMergeTree). See tabel salvestab sissetulevate mõõdikute arvu, mis on jaotatud neljale pesastustasemele.

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

Grafiit+ClickHouse. Komponentide koostoime skeem

Mõõdikute salvestamine: kuidas me läksime Graphite+Whisperilt Graphite+ClickHouse'i

Grafiit+ClickHouse. Andmete migratsioon

Nagu me selle projekti ootustest mäletame, peaks ClickHouse'ile üleminek toimuma vastavalt seisakuteta, pidime kogu oma monitooringusüsteemi kuidagi võimalikult läbipaistvalt oma kasutajate jaoks uuele salvestusruumile ümber lülitama.
Me tegime seda nii.

  • Carbon-c-releele lisati reegel, et saata täiendav mõõdikute voog ühe ClickHouse'i tabeli replikatsioonis osaleva serveri süsiniku klikimajja.

  • Kirjutasime väikese pythoni skripti, mis luges whisper-dump teeki kasutades kõik meie salvestusruumis olevad .wsp-failid ja saatis need andmed 24 lõimes ülalkirjeldatud süsinikuklõpsamismajja. Süsinik-clickhouse'i aktsepteeritud mõõdikute arv jõudis 125 miljonini minutis ja ClickHouse isegi ei higistanud.

  • Olemasolevates armatuurlaudades kasutatavate funktsioonide silumiseks lõime Grafanas eraldi andmeallika. Avastasime funktsioonide loendi, mida kasutasime, kuid neid ei rakendatud carbonapis. Lõpetasime need funktsioonid ja saatsime Carbonapi autoritele PR-i (eriline tänu neile).

  • Tasakaalustaja seadetes lugemiskoormuse muutmiseks muutsime lõpp-punktid grafiit-api (Graphite+Whisperi API liides) asemel carbonapi.

Grafiit+ClickHouse. tulemused

  • vähendas ketta alamsüsteemi kasutamist 30%-lt 1%-le;

    Mõõdikute salvestamine: kuidas me läksime Graphite+Whisperilt Graphite+ClickHouse'i

  • vähendas hõivatud ruumi mahtu 1 TB-lt 300 GB-ni;
  • meil on võimalus vastu võtta 125 miljonit mõõdikut minutis serveri kohta (tipptasemed migratsiooni ajal);
  • kandis kõik mõõdikud üle kolmekümnesekundilisele salvestusintervallile;
  • vastuvõetud andmete replikatsioon ja veataluvus;
  • lülitatakse ilma seisakuta;
  • Kõigele kulus umbes 7 nädalat.

Grafiit+ClickHouse. Probleemid

Meie puhul oli mõningaid lõkse. Siin on see, mida me pärast üleminekut kohtasime.

  1. ClickHouse ei loe alati konfiguratsioone käigu pealt ümber, mõnikord tuleb see uuesti laadida. Näiteks ClickHouse'i konfiguratsioonis oleva zookeeperi klastri kirjelduse puhul ei rakendatud seda enne, kui clickhouse-server oli taaskäivitatud.
  2. Suuri ClickHouse'i taotlusi ei olnud, nii et meie grafiit-clickhouse'is näeb ClickHouse'i ühendusstring välja järgmine:
    url = "http://localhost:8123/?max_query_size=268435456&max_ast_elements=1000000"
  3. ClickHouse annab üsna sageli välja stabiilsete väljaannete uusi versioone, need võivad sisaldada üllatusi: ole ettevaatlik.
  4. Kubernetesis dünaamiliselt loodud konteinerid saadavad lühikese ja juhusliku elueaga suure hulga mõõdikuid. Punkte selliste mõõdikute järgi palju ei ole ja kohaga probleeme pole. Kuid päringute koostamisel tõstab ClickHouse 'mõõdikute' tabelist suure hulga neid samu mõõdikuid. 90% juhtudest pole nende kohta andmeid väljaspool akent (24 tundi). Kuid aeg, mis kulub nende andmete otsimisele „andmete” tabelist, kulub ära ja lõpuks toetub aeg. Selle probleemi lahendamiseks hakkasime pidama eraldi vaadet, mis sisaldab teavet päeva jooksul esinenud mõõdikute kohta. Seega, dünaamiliselt loodud konteineritele aruannete (graafikute) koostamisel küsitleme ainult neid mõõdikuid, mis antud aknas esinesid, mitte kogu aja jooksul, mis kiirendas oluliselt nende kohta aruannete genereerimist. Ülaltoodud lahenduse jaoks koguti grafiit-clickhouse (kahvel), mis hõlmab tabeli date_metrics töötamise rakendamist.

Grafiit+ClickHouse. sildid

Alates versioonist 1.1.0 on Graphite muutunud ametlikuks tugisildid. Ja mõtleme aktiivselt, mida ja kuidas teha, et seda algatust grafiit+clickhouse stackis toetada.

Grafiit+ClickHouse. Anomaalia detektor

Tuginedes ülalkirjeldatud infrastruktuurile, oleme juurutanud anomaaliadetektori prototüübi ja see töötab! Aga tema kohta - järgmises artiklis.

Telli, vajuta üles noolt ja ole õnnelik!

Allikas: www.habr.com

Lisa kommentaar