Ahoj všichni! V jeho poslední článek Psal jsem o organizaci modulárního monitorovacího systému pro architekturu mikroslužeb. Nic se nezastaví, náš projekt neustále roste, stejně jako počet uložených metrik. Jak jsme zorganizovali přechod z Graphite + Whisper na Graphite + ClickHouse za podmínek vysokého zatížení, přečtěte si o očekáváních od něj a výsledcích migrace pod řezem.

Než vám řeknu, jak jsme zorganizovali přechod z ukládání metrik v Graphite + Whisper na Graphite + ClickHouse, rád bych uvedl informace o důvodech takového rozhodnutí a o nevýhodách Whisperu, se kterými jsme žili dlouhou dobu.

Problémy s grafitem a šepotem

1. Vysoké zatížení diskového subsystému

V době přechodu k nám létalo přibližně 1.5 milionu metrik za minutu. S tímto tokem bylo využití disku na serverech ~ 30 %. Obecně to bylo celkem přijatelné – vše fungovalo stabilně, rychle se psalo, rychle se četlo... Dokud jeden z vývojových týmů nezavedl novou funkci a nezačal nám posílat 10 milionů metrik za minutu. Tehdy se diskový subsystém přitvrdil a viděli jsme 100% využití. Problém byl rychle vyřešen, ale sediment zůstal.

2. Nedostatek replikace a konzistence

S největší pravděpodobností, jako každý, kdo používá / používá Graphite + Whisper, jsme nalili stejný proud metrik na několik serverů Graphite najednou, abychom vytvořili odolnost proti chybám. A s tím nebyly žádné zvláštní problémy - až do okamžiku, kdy jeden ze serverů z nějakého důvodu nespadl. Někdy se nám podařilo vyvolat padlý server dostatečně rychle a carbon-c-relay jej dokázalo naplnit metrikami ze své mezipaměti, a někdy ne. A pak byla díra v metrikách, kterou jsme zakryli rsync. Postup byl poměrně dlouhý. Zachránil to jen fakt, že se to stávalo velmi zřídka. Také jsme pravidelně brali náhodnou sadu metrik a porovnávali je s jinými podobnými na sousedních uzlech shluku. Asi v 5 % případů se několik hodnot lišilo, což nás moc nepotěšilo.

3. Velké množství zabraného prostoru

Vzhledem k tomu, že v Graphite píšeme nejen infrastrukturu, ale i obchodní metriky (a nově i metriky od Kubernetes), dostáváme se poměrně často do situace, kdy je v metrice jen pár hodnot a soubor .wsp je vytvořen pomocí zohledňuje celou dobu uchování a zabírá předem přidělené množství místa, které jsme měli ~ 2 MB. Problém se zhoršuje tím, že takových souborů je postupem času hodně a při sestavování reportů na nich čtení prázdných bodů zabere spoustu času a prostředků.

Okamžitě bych rád poznamenal, že výše popsané problémy lze řešit různými metodami as různou mírou účinnosti, ale čím více dat začnete přijímat, tím více se zhorší.

Po všem výše uvedeném (s přihlédnutím k předchozímu články), stejně jako neustálý nárůst počtu přijatých metrik, přání přenést všechny metriky do intervalu ukládání 30 sekund. (v případě potřeby až 10 sekund), rozhodli jsme se vyzkoušet Graphite+ClickHouse jako slibnou alternativu k Whisper.

Graphite+ClickHouse. očekávání

Po návštěvě několika setkání kluků z Yandexu po přečtení pár článků o HabrémPoté, co jsme prošli dokumentaci a našli rozumné komponenty pro vázání ClickHouse pod Graphite, rozhodli jsme se jednat!

Chtěl jsem získat následující:

snížit využití diskového subsystému z 30 % na 5 %;
snížit množství zabraného prostoru z 1 TB na 100 GB;
být schopen přijímat 100 milionů metrik za minutu na server;
replikace dat a odolnost proti chybám ihned po vybalení;
neseďte na tomto projektu rok a neprovádějte přechod na nějakou rozumnou dobu;
přepnout bez prostojů.

Docela ambiciózní, že?

Graphite+ClickHouse. Komponenty

Pro příjem dat přes protokol Graphite a jejich následný zápis do ClickHouse jsem zvolil carbon-clickhouse (golang).

Jako databáze pro ukládání časových řad byla zvolena poslední verze ClickHouse stabilní verze 1.1.54253. Při práci s ním byly problémy: do protokolů se nasypala hora chyb a nebylo úplně jasné, co s nimi dělat. V diskusi s Roman Lomonosov (autor carbon-clickhouse, graphite-clickhouse a mnoho dalších) byl vybrán ten starší vydání 1.1.54236. Chyby zmizely - všechno začalo fungovat s třeskem.

Bylo vybráno čtení dat z ClickHouse grafitový klikhouse (golang). Jako API pro Graphite − carbonapi (golang). K organizaci replikace mezi tabulkami byl použit ClickHouse ošetřovatel zoo. Pro metriky směrování jsme opustili naši milovanou uhlík-c-relé (C) (viz předchozí článek).

Graphite+ClickHouse. Struktura tabulky

„graphite“ je databáze, kterou jsme vytvořili pro monitorovací tabulky.

„graphite.metrics“ je tabulka s modulem ReplicatedReplacingMergeTree (replikovaný NahrazeníMergeTree). Tato tabulka ukládá názvy metrik 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“ je tabulka s modulem ReplicatedGraphiteMergeTree (replikovaný GraphiteMergeTree). Tato tabulka ukládá 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 podmíněně vyplněná tabulka s modulem ReplicatedReplacingMergeTree. Tato tabulka obsahuje názvy všech metrik, které byly během dne zjištěny. Důvody pro vytvoření jsou popsány v části "problémy" na konci tohoto č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“ je podmíněná tabulka s modulem ReplicatedAggregatingMergeTree (replikovaný AgregatingMergeTree). Tato tabulka zaznamenává počet příchozích metrik rozdělených do 4 úrovní vnoření.

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. Schéma vzájemného působení složek

Graphite+ClickHouse. Migrace dat

Jak si pamatujeme z očekávání od tohoto projektu, přechod na ClickHouse by měl být bez prostojů, respektive jsme museli nějak co nejtransparentněji pro naše uživatele přepnout celý náš monitorovací systém na nové úložiště.
Udělali jsme to takto.

Do carbon-c-relay bylo přidáno pravidlo pro odesílání dalšího proudu metrik do uhlíkového clickhouse jednoho ze serverů zapojených do replikace tabulek ClickHouse.
Napsali jsme malý skript pro python, který pomocí knihovny whisper-dump načetl všechny soubory .wsp z našeho úložiště a odeslal tato data do výše popsaného uhlíkového clickhouse ve 24 vláknech. Počet akceptovaných metrických hodnot v carbon-clickhouse dosáhl 125 milionů / min. a ClickHouse se ani nezapotil.
Vytvořili jsme samostatný DataSource v Grafaně, abychom ladili funkce používané ve stávajících dashboardech. Odhalil seznam funkcí, které jsme používali, ale nebyly implementovány v carbonapi. Dokončili jsme tyto funkce a zaslali PR autorům carbonapi (zvláštní díky jim).
Pro přepnutí zátěže čtení v nastavení balanceru jsme změnili koncové body z graphite-api (rozhraní API pro Graphite+Whisper) na carbonapi.

Graphite+ClickHouse. Výsledek

snížení využití diskového subsystému z 30 % na 1 %;
snížilo množství zabraného prostoru z 1 TB na 300 GB;
máme schopnost přijímat 125 milionů metrik za minutu na server (špičky v době migrace);
přeneseny všechny metriky do třicetisekundového intervalu ukládání;
replikace přijatých dat a odolnost proti chybám;
přepnuto bez prostojů;
Vše trvalo asi 7 týdnů.

Graphite+ClickHouse. Problémy

V našem případě to byla určitá úskalí. Zde je to, s čím jsme se po přechodu setkali.

ClickHouse ne vždy znovu načítá konfigurace za běhu, někdy je třeba je znovu načíst. Například v případě popisu clusteru zookeeper v konfiguraci ClickHouse nebyl použit, dokud nebyl server clickhouse restartován.
Nebyly zaznamenány žádné velké požadavky ClickHouse, takže v našem grafitovém clickhouse vypadá připojovací řetězec ClickHouse takto:
```
url = "http://localhost:8123/?max_query_size=268435456&max_ast_elements=1000000"
```
ClickHouse poměrně často vydává nové verze stabilních verzí, mohou obsahovat překvapení: buďte opatrní.
Dynamicky vytvářené kontejnery v kubernetes odesílají velké množství metrik s krátkou a náhodnou životností. Podle takových metrik není mnoho bodů a s místem nejsou žádné problémy. Při sestavování dotazů však ClickHouse vyvolává velké množství stejných metrik z tabulky „metriky“. V 90 % případů pro ně za oknem nejsou žádná data (24 hodin). Ale čas strávený hledáním těchto dat v tabulce 'data' je utracen a nakonec spočívá na časovém limitu. Abychom tento problém vyřešili, začali jsme udržovat samostatný pohled s informacemi o metrikách, se kterými jsme se během dne setkali. Při sestavování reportů (grafů) pro dynamicky vytvářené kontejnery tedy dotazujeme pouze ty metriky, na které jsme narazili v zadaném okně, nikoli za celou dobu, což tvorbu reportů o nich značně urychlilo. Pro výše uvedený roztok byl shromážděn grafit-clickhouse (vidlice), která zahrnuje implementaci práce s tabulkou date_metrics.

Graphite+ClickHouse. značky

Od verze 1.1.0 se Graphite stal oficiálním podpůrné značky. A aktivně přemýšlíme, co a jak udělat, abychom tuto iniciativu podpořili v stacku grafit+clickhouse.

Graphite+ClickHouse. Detektor anomálií

Na základě výše popsané infrastruktury jsme implementovali prototyp detektoru anomálií a funguje to! Ale o něm - v dalším článku.

Přihlaste se k odběru, stiskněte šipku nahoru a buďte šťastní!

Zdroj: www.habr.com

Metrické úložiště: jak jsme přešli z Graphite+Whisper na Graphite+ClickHouse