Ahoj všichni! Ve svém jsem psal o organizaci modulárního systému monitorování pro mikroservisní architekturu. Nic nestojí na místě, náš projekt neustále roste a počet uložených metrik také. Jak jsme zorganizovali přechod z Graphite+Whisper na Graphite+ClickHouse za podmínek vysokých zátěží, očekávání od něj a výsledky migrace se dočtete níže.
Než vám povím, jak jsme zorganizovali přechod od ukládání metrik v Graphite+Whisper na Graphite+ClickHouse, rád bych poskytl informace o důvodech přijetí takového rozhodnutí a o těch nevýhodách Whisper, se kterými jsme žili po dlouhou dobu.
Problémy Graphite+Whisper
1. Vysoké zatížení diskového subsystému
V době přechodu k nám přicházelo asi 1,5 milionu metrik za minutu. Při takovém toku byla disková využitelnost na serverech přibližně 30 %. Celkově to bylo docela přijatelné — vše fungovalo stabilně, rychle se zapisovalo, rychle se četlo… Až do chvíle, kdy jeden z vývojových týmů nevydal novou funkci a nezačal nám posílat 10 milionů metrik za minutu. Tehdy se diskový subsystém začal pomalu dusit a viděli jsme 100% využitelnost. Problém jsme dokázali rychle vyřešit, ale pocity zůstaly.
2. Nepřítomnost replikace a konzistence
Pravděpodobně jako všichni, kdo používají/používali Graphite+Whisper, jsme posílali stejný tok metrik najednou na několik serverů Graphite s cílem vytvořit odolnost vůči chybám. A s tím žádné zvláštní problémy nebyly — až do momentu, kdy jeden z serverů z nějakého důvodu nefungoval. Někdy jsme stihli spadnulý server dost rychle znovu rozběhnout a carbon-c-relay stihnul do něj vložit metriky ze své cache, a jindy ne. A pak v metrikách byla díra, kterou jsme zacelovali přes rsync. Tento proces byl poměrně dlouhý. Zachraňovalo nás jen to, že se něco takového stávalo velmi zřídka. Také jsme občas brali náhodnou sadu metrik a porovnávali je s jinými na sousedních uzlech clusteru. Přibližně v 5 % případů se několik hodnot lišilo, což nás příliš nepotěšilo.
3. Velký objem zabraného místa
Protože v Graphite zapisujeme nejen infrastrukturní, ale i obchodní metriky (a nyní také metriky z Kubernetes), často se setkáváme se situací, kdy v metrice jsou pouze některé hodnoty, zatímco .wsp soubor se vytváří s ohledem na celé retention období a zabírá přidělený prostor, který byl přibližně 2 MB. Problém se zhoršuje tím, že se takových souborů časem objevuje velmi mnoho a při vytváření zpráv o nich se na čtení prázdných bodů spotřebovává spousta času a prostředků.
Hned bych chtěl poznamenat, že s problémy popsanými výše lze bojovat různými metodami a s různou efektivitou, ale čím více dat začíná přicházet, tím více se tyto problémy zhoršují.
S ohledem na vše výše uvedené (včetně předchozího ), a také na neustále rostoucí počet přijímaných metrik, s cílem převést všechny metriky na interval uchování 30 sekund (v případě potřeby až 10 sekund), jsme se rozhodli vyzkoušet Graphite+ClickHouse jako perspektivní alternativu k Whisper.
Graphite+ClickHouse. Očekávání
Po návštěvě několika meetupů od kluků z Yandexu, přečtení , prozkoumání dokumentace a nalezení rozumných komponentů pro integraci ClickHouse s Graphite jsme se rozhodli jednat!
Chtěli jsme dosáhnout následujícího:
- snížit využití diskového subsystému z 30 % na 5 %;
- snížit objem zaplněného místa z 1 TB na 100 GB;
- mít možnost přijímat 100 milionů metrik za minutu na server;
- replikaci dat a odolnost proti selhání z krabice;
- nepracovat na tomto projektu rok a provést přechod během rozumného období;
- přepnout se bez prostojů.
Docela ambiciózní, že?
Graphite+ClickHouse. Komponenty
Pro získávání dat prostřednictvím protokolu Graphite a jejich následné zapisování do ClickHouse byl vybrán (golang).
Za databázi pro uchovávání časových řad byla zvolena poslední dostupná stabilní verze ClickHouse 1.1.54253. Při práci s ním byly problémy: do logů se dostávalo mnoho chyb a nebylo zcela jasné, co s nimi dělat. Po diskusi s (autorem carbon-clickhouse, graphite-clickhouse a mnoha dalších komponent) byla zvolena starší . Chyby zmizely — vše začalo fungovat skvěle.
Pro čtení dat z ClickHouse byla zvolena (golang). Jako API rozhraní pro Graphite — (golang). Pro organizaci replikace mezi tabulkami ClickHouse byl použit . Pro směrování metrik jsme ponechali naši oblíbenou (C) .
Graphite+ClickHouse. Struktura tabulek
„graphite“ — databáze, kterou jsme vytvořili pro tabulky monitorování.
„graphite.metrics“ — tabulka s motorem ReplicatedReplacingMergeTree (replikovaný ). V této tabulce jsou uložena jména metrik a jejich cesty.
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“ — tabulka s motorem ReplicatedGraphiteMergeTree (replikovaný ). V této tabulce jsou uloženy hodnoty metrik.
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“ — tabulka, která se vyplňuje podle podmínky, s motorem ReplicatedReplacingMergeTree. Do této tabulky se zapisují jména všech metrik, které se objevily za den. Důvody vzniku jsou popsány v sekci 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“ — tabulka, která se vyplňuje podle podmínky, s motorem ReplicatedAggregatingMergeTree (replikovaný ). Do této tabulky se zapisuje počet příchozích metrik, rozdělený do 4 úrovní zanoř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, PrefixGraphite+ClickHouse. Schéma interakce komponentů
Graphite+ClickHouse. Migrace dat
Jak jsme si pamatovali z očekávání od tohoto projektu, přechod na ClickHouse by měl proběhnout bez výpadků, a proto jsme museli nějakým způsobem přepnout celý náš monitorovací systém na nové úložiště co nejtransparentněji pro naše uživatele.
Udělali jsme to takto.
Do carbon-c-relay jsme přidali pravidlo pro odesílání dalšího toku metrik do carbon-clickhouse jednoho ze serverů, které se podílejí na replikaci tabulek ClickHouse.
Napsali jsme malý skript v pythonu, který pomocí knihovny whisper-dump procházel všechny .wsp soubory v našem úložišti a odesílal tato data do výše uvedeného carbon-clickhouse ve 24 vláknech. Počet přijímaných hodnot metrik v carbon-clickhouse dosahoval 125 milionů/min, a ClickHouse se ani nezpotil.
Vytvořili jsme samostatný DataSource v Grafaně za účelem ladění funkcí používaných v existujících dashboardech. Identifikovali jsme seznam funkcí, které jsme používali, ale nebyly implementovány v carbonapi. Tyto funkce jsme doplnili a odeslali PR autorům carbonapi (díky za to).
- Pro změnu čtecí zátěže v nastavení vyvažovačů jsme změnili koncové body z graphite-api (API rozhraní pro Graphite+Whisper) na carbonapi.
Graphite+ClickHouse. Výsledky
snížili jsme vytížení diskového subsystému z 30 % na 1 %;
- snížili jsme objem místa z 1 TB na 300 GB;
- máme možnost přijímat 125 milionů metrik za minutu na server (vrcholy během migrace);
- převedli jsme všechny metriky na třicetisekundový interval uchovávání;
- získali jsme replikaci dat a odolnost proti chybám;
- přepnuli jsme se bez prostojů;
- na všechno jsme utratili přibližně 7 týdnů.
Graphite+ClickHouse. Problémy
V našem případě se neobešlo bez podvodních kamenů. Tady je, s čím jsme se setkali po přechodu.
- ClickHouse ne vždy načítá konfigurace za běhu, občas je potřeba ho restartovat. Například v případě popisu clusteru zookeeper v konfiguraci ClickHouse — neaplikoval se, dokud se neprovedl restart clickhouse-server.
- Velké dotazy ClickHouse se nedařilo projít, proto má naše připojení k ClickHouse v graphite-clickhouse následující podobu:
url = "http://localhost:8123/?max_query_size=268435456&max_ast_elements=1000000" - V ClickHouse se velmi často objevují nové stabilní verze, mohou obsahovat překvapení: buďte opatrní.
- Dynamicky vytvářené kontejnery v Kubernetes odesílají velké množství metrik s krátkým a náhodným životním cyklem. Počet těchto metrik není vysoký a s místem nejsou problémy. Při dotazování v ClickHouse však trvá extrahovat obrovské množství metrik z tabulky ‘metrics’. V 90 % případů jsou data k dispozici pouze za okno (24 hodin) a čas potřebný na jejich vyhledání v tabulce ‘data’ se nakonec protáhne na timeout. Abychom tento problém vyřešili, začali jsme vést samostatný pohled (view) s informacemi o metrikách, které se objevily během dne. Při vytváření zpráv (grafů) o dynamicky vytvářených kontejnerech dotazujeme pouze ty metriky, které se vyskytly v daném časovém okně, což dramaticky urychlilo tvorbu zpráv. , který zahrnuje implementaci práce s tabulkou date_metrics.
Graphite+ClickHouse. Tagy
Od verze 1.1.0 začal Graphite oficiálně . A my aktivně přemýšlíme o tom, co a jak udělat, abychom tuto iniciativu podpořili ve stacku graphite+clickhouse.
Graphite+ClickHouse. Detektor anomálií
Na základě výše popsané infrastruktury jsme vytvořili prototyp detektoru anomálií a ten funguje! Ale o něm — v příštím článku.
Odebírejte, klikněte na šipku nahoru a buďte šťastní!
Zdroj: habr.com
