Ukladanie metrík: ako sme prešli z Graphite+Whisper na Graphite+ClickHouse

Ahojte všetci! V jeho posledný článok Písal som o organizovaní modulárneho monitorovacieho systému pre architektúru mikroslužieb. Nič sa nezastaví, náš projekt neustále rastie a tým rastie aj počet uložených metrík. Ako sme zorganizovali prechod z Graphite+Whisper na Graphite+ClickHouse v podmienkach vysokej záťaže, prečítajte si o očakávaniach od toho a o výsledkoch migrácie pod rezom.

Ukladanie metrík: ako sme prešli z Graphite+Whisper na Graphite+ClickHouse

Predtým, ako vám poviem, ako sme zorganizovali prechod z ukladania metrík v Graphite+Whisper na Graphite+ClickHouse, rád by som uviedol informácie o dôvodoch takéhoto rozhodnutia a o nevýhodách Whisper, s ktorými sme dlho žili.

Problémy s grafitom a šepotom

1. Vysoké zaťaženie diskového subsystému

V čase prechodu k nám prichádzalo približne 1.5 milióna metrík za minútu. Pri takomto toku bolo využitie disku na serveroch ~ 30 %. Vo všeobecnosti to bolo celkom prijateľné – všetko fungovalo stabilne, rýchlo sa písalo, rýchlo čítalo... Až kým jeden z vývojových tímov nezaviedol novú funkciu a nezačal nám posielať 10 miliónov metrík za minútu. Vtedy sa diskový subsystém sprísnil a videli sme 100% využitie. Problém bol rýchlo vyriešený, ale zvyšok zostal.

2. Nedostatok replikácie a konzistencie

S najväčšou pravdepodobnosťou, ako každý, kto používa/používa Graphite+Whisper, sme naliali rovnaký prúd metrík na niekoľko serverov Graphite naraz, aby sme vytvorili odolnosť voči chybám. A s tým neboli žiadne zvláštne problémy - až do okamihu, keď jeden zo serverov z nejakého dôvodu havaroval. Niekedy sa nám podarilo zachytiť spadnutý server dostatočne rýchlo a carbon-c-relay doň dokázal načítať metriky zo svojej vyrovnávacej pamäte, ale niekedy nie. A potom bola diera v metrike, ktorú sme vyplnili pomocou rsync. Postup bol dosť dlhý. Jedinou záchranou bolo, že sa to stávalo veľmi zriedka. Pravidelne sme tiež brali náhodný súbor metrík a porovnávali sme ich s inými rovnakými typmi na susedných uzloch klastra. Zhruba v 5 % prípadov bolo viacero hodnôt odlišných, čo nás veľmi nepotešilo.

3. Veľká stopa

Keďže v Graphite píšeme nielen infraštruktúru, ale aj obchodné metriky (a teraz už aj metriky od Kubernetes), pomerne často sa dostávame do situácie, že metrika obsahuje len niekoľko hodnôt a súbor .wsp je vytvorený s prihliadnutím na všetky retencie. a zaberá vopred pridelené množstvo miesta, ktoré pre nás predstavovalo ~2 MB. Problém ešte zhoršuje skutočnosť, že sa postupom času objavuje množstvo podobných súborov a pri vytváraní prehľadov na nich čítanie prázdnych bodov zaberie veľa času a prostriedkov.

Okamžite by som rád poznamenal, že s vyššie popísanými problémami sa možno vysporiadať pomocou rôznych metód as rôznym stupňom účinnosti, ale čím viac údajov začnete dostávať, tým viac sa zhoršia.

Po všetkých vyššie uvedených (berúc do úvahy predchádzajúce Článok), ako aj neustály nárast počtu prijatých metrík, túžba preniesť všetky metriky do intervalu ukladania 30 sekúnd. (v prípade potreby až 10 sekúnd), rozhodli sme sa vyskúšať Graphite+ClickHouse ako sľubnú alternatívu k Whisper.

Graphite+ClickHouse. Očakávania

Po návšteve niekoľkých stretnutí chlapcov z Yandexu po prečítaní pár článkov o HabrémPo preštudovaní dokumentácie a nájdení rozumných komponentov na viazanie ClickHouse pod Graphite sme sa rozhodli konať!

Chcel by som získať nasledovné:

  • znížiť využitie diskového subsystému z 30 % na 5 %;
  • znížiť množstvo obsadeného priestoru z 1 TB na 100 GB;
  • byť schopný prijímať 100 miliónov metrík za minútu na server;
  • replikácia dát a odolnosť proti chybám hneď po vybalení;
  • neseďte na tomto projekte rok a urobte prechod v rozumnom časovom rámci;
  • prepínač bez prestojov.

Celkom ambiciózne, však?

Graphite+ClickHouse. Komponenty

Pre príjem dát cez protokol Graphite a následné zaznamenanie v ClickHouse som zvolil carbon-clickhouse (golang).

Ako databáza na ukladanie časových radov bola zvolená najnovšia verzia ClickHouse, stabilná verzia 1.1.54253. Pri práci s ním sa vyskytli problémy: do protokolov sa nalialo množstvo chýb a nebolo úplne jasné, čo s nimi robiť. V diskusii s Roman Lomonosov (autor carbon-clickhouse, graphite-clickhouse a mnohých, mnohých ďalších) bol vybraný ten starší vydanie 1.1.54236. Chyby zmizli - všetko začalo fungovať s treskom.

Vybraté na čítanie údajov z ClickHouse grafit-slickhouse (golang). Ako API pre grafit − carbonapi (golang). ClickHouse bol použitý na organizáciu replikácie medzi tabuľkami ošetrovateľ v zoo. Pre metriky smerovania sme opustili nášho milovaného uhlík-c-relé (C) (pozri predchádzajúci článok).

Graphite+ClickHouse. Štruktúra tabuľky

„graphite“ je databáza, ktorú sme vytvorili pre monitorovacie tabuľky.

“graphite.metrics” – tabuľka s motorom ReplicatedReplacingMergeTree (replikovaný NahradenieMergeTree). V tejto tabuľke sú uložené názvy metrík a cesty k nim.

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“ - tabuľka s motorom ReplicatedGraphiteMergeTree (replikovaná GraphiteMergeTree). V tejto tabuľke sú uložené metrické hodnoty.

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“ je podmienečne vyplnená tabuľka s motorom ReplicatedReplacingMergeTree. Táto tabuľka zaznamenáva názvy všetkých metrík, ktoré boli zaznamenané počas dňa. Dôvody jeho vzniku sú popísané v časti "problémy" na konci tohto článku.

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“ – tabuľka vyplnená podľa podmienky pomocou nástroja ReplicatedAggregatingMergeTree (replikovaný AgregatingMergeTree). Táto tabuľka zaznamenáva počet prichádzajúcich metrík rozdelených na 4 úrovne vnorenia.

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. Diagram interakcie komponentov

Ukladanie metrík: ako sme prešli z Graphite+Whisper na Graphite+ClickHouse

Graphite+ClickHouse. Migrácia dát

Ako si pamätáme z očakávaní od tohto projektu, prechod na ClickHouse by mal prebehnúť bez výpadkov, preto sme museli nejakým spôsobom pre našich používateľov prepnúť celý náš monitorovací systém na nové úložisko čo najtransparentnejšie.
Takto sme to urobili.

  • Do carbon-c-relay bolo pridané pravidlo na odoslanie dodatočného prúdu metrík do uhlíkového kliknutia jedného zo serverov, ktoré sa podieľajú na replikácii tabuliek ClickHouse.

  • Napísali sme malý skript v pythone, ktorý pomocou knižnice whisper-dump načítal všetky .wsp súbory z nášho úložiska a tieto údaje odoslal do vyššie opísaného carbon-clickhouse v 24 vláknach. Počet akceptovaných metrických hodnôt v carbon-clickhouse dosiahol 125 miliónov/min a ClickHouse sa ani nezapotil.

  • Vytvorili sme samostatný DataSource v Grafane na ladenie funkcií používaných v existujúcich dashboardoch. Identifikovali sme zoznam funkcií, ktoré sme použili, ale neboli implementované v carbonapi. Pridali sme tieto funkcie a poslali sme PR autorom carbonapi (osobitne im ďakujeme).

  • Aby sme v nastaveniach balancera prepli záťaž čítania, zmenili sme koncové body z graphite-api (rozhranie API pre Graphite+Whisper) na carbonapi.

Graphite+ClickHouse. výsledky

  • zníženie využitia diskového subsystému z 30 % na 1 %;

    Ukladanie metrík: ako sme prešli z Graphite+Whisper na Graphite+ClickHouse

  • znížilo množstvo obsadeného priestoru z 1 TB na 300 GB;
  • máme schopnosť prijímať 125 miliónov metrík za minútu na server (špičky v čase migrácie);
  • preniesť všetky metriky do tridsaťsekundového intervalu ukladania;
  • replikácia prijatých údajov a odolnosť proti chybám;
  • prepínané bez prestojov;
  • Dokončenie všetkého trvalo asi 7 týždňov.

Graphite+ClickHouse. Problémy

V našom prípade tam boli isté úskalia. S tým sme sa stretli po prechode.

  1. ClickHouse nie vždy znova načítava konfigurácie za behu; niekedy je potrebné reštartovať. Napríklad v prípade popisu klastra zookeeper v konfigurácii ClickHouse nebol použitý, kým sa nereštartoval server clickhouse.
  2. Veľké požiadavky ClickHouse neprešli, takže v graphite-clickhouse vyzerá náš reťazec pripojenia ClickHouse takto:
    url = "http://localhost:8123/?max_query_size=268435456&max_ast_elements=1000000"
  3. ClickHouse pomerne často vydáva nové verzie stabilných verzií; môžu obsahovať prekvapenia: buďte opatrní.
  4. Dynamicky vytvorené kontajnery v kubernetes odosielajú veľké množstvo metrík s krátkou a náhodnou životnosťou. Za takéto metriky nie je veľa bodov a s priestorom nie sú žiadne problémy. Pri vytváraní dopytov však ClickHouse zhromažďuje obrovské množstvo rovnakých metrík z tabuľky „metrík“. V 90% prípadov o nich nie sú žiadne údaje za oknom (24 hodín). Čas sa však strávi hľadaním týchto údajov v tabuľke „údaje“ a nakoniec vyprší časový limit. Aby sme tento problém vyriešili, začali sme udržiavať samostatný pohľad s informáciami o metrikách, s ktorými sme sa počas dňa stretli. Pri zostavovaní reportov (grafov) pre dynamicky vytvárané kontajnery teda dopytujeme len tie metriky, ktoré sa vyskytli v rámci daného okna, a nie za celý čas, čo výrazne urýchlilo stavbu reportov na nich. Pre vyššie opísané riešenie som zhromaždil grafitový klikací domček (vidlica), ktorá zahŕňa implementáciu práce s tabuľkou date_metrics.

Graphite+ClickHouse. Tagy

S verziou 1.1.0 sa Graphite stal oficiálnym podporné značky. A aktívne uvažujeme o tom, čo a ako urobiť, aby sme túto iniciatívu podporili v stacku grafit+clickhouse.

Graphite+ClickHouse. Detektor anomálií

Na základe vyššie opísanej infraštruktúry sme implementovali prototyp detektora anomálií a funguje to! Ale viac o ňom v ďalšom článku.

Prihláste sa na odber, stlačte šípku nahor a buďte šťastní!

Zdroj: hab.com

Pridať komentár