Üdv mindenkinek! A saját előző cikkben én írtam egy moduláris monitorozási rendszer szervezéséről mikroszervíz architektúrához. Semmi sem áll meg, a projektünk folyamatosan növekszik, és a tárolt metrikák száma is. Hogyan szerveztük meg az átmenetet a Graphite+Whisper-ről a Graphite+ClickHouse-ra magas terhelés mellett, az elvárásokról és a migráció eredményeiről a tizenöt alatt olvashattok.

Mérőszámok tárolása: hogyan váltottunk a Graphite+Whisperről a Graphite+ClickHouse-ra

Mielőtt elmesélném, hogyan szerveztük meg az átmenetet a Graphite+Whisper alapú metrikáktól a Graphite+ClickHouse-hoz, szeretnék információt adni azokról az okokról, amelyek ezt a döntést indokolták, és a Whisper hátrányairól, amelyeket hosszú időn keresztül elviseltünk.

A Graphite+Whisper problémái

1. Magas terhelés a lemezalrendszeren

Átmenetünk idején körülbelül 1,5 millió metrika érkezett percenként. Ezzel a forgalommal a lemez kihasználtság a szervereken körülbelül 30% volt. Összességében ez teljesen elfogadható volt — minden stabilan működött, gyorsan íródott, gyorsan olvasható volt… Egészen addig, amíg az egyik fejlesztőcsapat ki nem hozta az új funkciót, és nem kezdtek el nekünk 10 millió metrikát küldeni percenként. Akkor a lemezalrendszer megfeszítette magát, és 100%-os kihasználtságot tapasztaltunk. A problémát gyorsan megoldottuk, de azért maradt egy kis keserű utánérzés.

2. Replikáció és konzisztencia hiánya

Valószínűleg, mint mindenki, aki használja/használta a Graphite+Whisper-t, ugyanazt a metrikafolyamot öntöttük azonnal több Graphite szerverre a megbízhatóság érdekében. Ezzel nem volt különösebb probléma — egészen addig, amíg valamelyik szerver valamilyen okból le nem állt. Néha elég gyorsan sikerült újraindítanunk a leállt szervert, és a carbon-c-relay sikerült betöltenie a metrikákat a cache-ből, de néha nem. Ilyenkor a metrikákban keletkezett egy hiány, amit az rsync-szel töltöttünk ki. A folyamat elég hosszú volt. Csak azt mentette meg, hogy ez nagyon ritkán történt. Ezen kívül időnként véletlenszerű metrikakészletet vettünk és összehasonlítottuk a szomszédos klasztercsomópontok más, hasonlókkal. Körülbelül az esetek 5%-ában néhány érték eltért, ami nem sok örömet okozott számunkra.

3. Nagy tárolási igény

Mivel nemcsak infrastruktúrára, hanem üzleti metrikákra is írunk a Graphite-ban (és most már a Kubernetes-ből származó metrikákra is), gyakran olyan helyzetet tapasztalunk, ahol a metrikában csak néhány érték szerepel, míg a .wsp fájl a teljes megőrzési időszak figyelembevételével jön létre, és foglal egy előre meghatározott helyet, ami körülbelül ~2MB volt. A probléma súlyosbítja, hogy az ilyen fájlokból idővel egyre több keletkezik, és a jelentések készítése során, a üres pontok olvasására sok időt és erőforrást fordítunk.

Azonnal szeretnénk megjegyezni, hogy a fent leírt problémák ellen különböző módszerekkel és eltérő hatékonysággal lehet küzdeni, de minél több adat érkezik, annál súlyosabbá válnak ezek.

Figyelembe véve a fent említetteket (a korábbiak figyelembevételével, cikkből származnak), valamint a kapott metrikák folyamatos növekedését, a vágyunk az volt, hogy minden metrikát 30 másodperces tárolási intervallumra (szükség esetén akár 10 másodpercre) váltsunk, ezért úgy döntöttünk, hogy kipróbáljuk a Graphite + ClickHouse-t mint ígéretes alternatívát a Whisper számára.

Graphite+ClickHouse. Elvárások

Miután részt vettünk néhány Yandex-es találkozón, és elolvastunk néhány cikket a Habr-on,, átnézve a dokumentációt és megfelelő komponenseket találva, hogy a ClickHouse-t a Graphite-hoz kapcsoljuk, úgy döntöttünk, hogy cselekszünk!

A következőket szerettük volna elérni:

csökkenteni a lemezrendszer kihasználtságát 30%-ról 5%-ra;
csökkenteni a tárolt helyet 1TB-ról 100GB-ra;
lehetővé tenni, hogy percenként 100 millió metrikát fogadjunk a szerverre;
adatreplicációt és hibatűrést dobozból való megoldást;
nem akartunk egy évet ülni ezen a projekten, hanem ésszerű időn belül szeretnénk átállni;
átállni állásidő nélkül.

Rendkívül ambiciózus, igaz?

Graphite+ClickHouse. Komponensek

A Graphite protokollon keresztüli adatok beszerzésére és a ClickHouse-ba való rögzítésére az carbon-clickhouse (golang) került kiválasztásra.

A időszakos sorok tárolására a ClickHouse stabil verziójának legfrissebb kiadását választottuk, 1.1.54253. Ennek használata során problémák adódtak: rengeteg hibaüzenet került a naplókba, és nem volt világos, hogy mit kezdjünk velük. Róman Lomonoszovval folytatott megbeszélés során (a carbon-clickhouse, graphite-clickhouse és sok más szerzője) egy régebbi 1.1.54236-os kiadást választottunk. A hibák eltűntek – minden simán működött.A ClickHouse adatainak olvasására a

graphite-slickhouse (golang) választottuk. A Graphite API interfészeként a carbonapi szolgál. (golang). A ClickHouse táblák közötti replikációs szervezéshez zookeeper. A metrikák irányításához a kedvenc megoldásunkat választottuk, a carbon-c-relay (C) (lásd az előző cikket).

Graphite+ClickHouse. A táblák felépítése

A “graphite” egy adatbázis, amelyet a monitorozó táblákhoz készítettünk.

A “graphite.metrics” táblázat ReplicatedReplacingMergeTree motorral rendelkezik (replikált ReplacingMergeTree). Ebben a táblában a metrikák nevei és az elérési útvonalak tárolódnak.

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);

A “graphite.data” táblázat ReplicatedGraphiteMergeTree motorral rendelkezik (replikált GraphiteMergeTree). Ebben a táblában a metrikák értékei tárolódnak.

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')

A “graphite.date_metrics” egy feltételesen feltöltött tábla, amely ReplicatedReplacingMergeTree motorral rendelkezik. Ebbe a táblába azoknak a metrikáknak a nevei íródnak be, amelyek egy nap alatt megjelentek. A létrehozás okai a „Problémák” szakaszban találhatók.

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

A “graphite.data_stat” egy feltételesen feltöltött tábla, amely ReplicatedAggregatingMergeTree motorral rendelkezik (replikált AggregatingMergeTree). Ebbe a táblába az érkező metrikák számát rögzítjük, legfeljebb 4 szintű hierarchikus bontásban.

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. A komponensek interakciójának rendszere

Mérőszámok tárolása: hogyan váltottunk a Graphite+Whisperről a Graphite+ClickHouse-ra

Graphite+ClickHouse. Adatmigráció

Ahogy a projekt várakozásaiból emlékszünk, a ClickHouse-ra való áttérésnek leállás nélkül kell történnie, ezért valamilyen módon át kellett állítanunk az egész monitorozó rendszerünket az új tárolóra, minél átláthatóbban a felhasználóink számára.
Ezt így valósítottuk meg.

A carbon-c-relaybe hozzáadtuk a szabályt, hogy egy további metrikafolyamot küldjünk a carbon-clickhouse számára egy olyan szerverről, amely részt vesz a ClickHouse táblák replikációjában.
Írtunk egy kis python szkriptet, amely a whisper-dump könyvtárral kiolvasta az összes .wsp fájlt a tárolónkból, és ezeket az adatokat a fent említett carbon-clickhouse-ba küldte 24 szálon. A carbon-clickhouse-ba beérkező metrikák száma elérte a 125 milliót/perc, és a ClickHouse még a legnagyobb terhelés alatt sem izzadt meg.
Létrehoztunk egy külön DataSource-t a Grafana-ban a meglévő műszerfalakon használt funkciók hibakeresésére. Azonosítottuk azokat a funkciókat, amelyeket használtunk, de nem valósultak meg a carbonapi-ban. Kiegészítettük ezeket a funkciókat, és elküldtük a PR-okat a carbonapi készítőinek (külön köszönet nekik).
A terhelés átviteléhez a terheléselosztók beállításaiban megváltoztattuk az endpointokat graphite-api-ról (Graphite+Whisper API interfész) carbonapi-ra.

Graphite+ClickHouse. Eredmények

csökkentettük a lemezrendszer kihasználtságát 30%-ról 1%-ra;
csökkentettük a foglalt helyet 1 TB-rol 300 GB-ra;
lehetőségünk van 125 millió metrika fogadására percenként a szerverre (csúcsok a migrációs időszak alatt);
minden metrikát átkonvertáltunk harminc másodperces tárolási intervallumra;
adatok replikációját és hibatűrést kaptunk;
leállás nélkül váltottunk;
mindez körülbelül 7 hetet vett igénybe.

Graphite+ClickHouse. Problémák

A mi esetünkben is akadtak nehézségek. Íme a problémák, amelyekkel a váltás után szembesültünk.

A ClickHouse nem mindig olvassa újra a konfigurációkat valós időben, néha újra kell indítani. Például a zookeeper klaszter leírásával kapcsolatos ClickHouse konfiguráció nem lépett érvénybe a clickhouse-server újraindítása előtt.
A ClickHouse nem kezeli a nagy lekérdezéseket, ezért a graphite-clickhouse csatlakozási sora a ClickHouse-hoz így néz ki:
```
url = "http://localhost:8123/?max_query_size=268435456&max_ast_elements=1000000"
```
A ClickHouse-ban gyakran jelennek meg új stabil kiadások, amelyek tartalmazhatnak meglepetéseket: légy óvatos.
A dinamikusan létrehozott konténerek a Kubernetesben nagy mennyiségű metrikát küldenek rövid és véletlenszerű életciklusú időszakokkal. Ezekből a metrikákból nem sok található, és a helyhiány sem okoz problémát. Azonban a ClickHouse lekérdezések során hatalmas mennyiségű metrikát emel ki az 'metrics' táblából. Az esetek 90%-ában a 24 órás időablakban az adatok nem állnak rendelkezésre. Azonban a keresési idő a 'data' táblában eltelik, végül pedig időtúllépéshez vezet. Ennek a problémának a megoldása érdekében külön nézetet vezettünk be, amely az elmúlt 24 órában előforduló metrikák információit tartalmazza. Így a dinamikusan létrehozott konténerek jelentéseinek (diagramjainak) elkészítésekor csak azokat a metrikákat kérdezzük le, amelyek a beállított időablakban fordultak elő, nem pedig minden időpontban, ami jelentősen felgyorsította a jelentések elkészítését. Az említett megoldáshoz graphite-clickhouse (fork), amely tartalmazza a date_metrics táblával való munkavégzés megvalósítását.

Graphite+ClickHouse. Címkék

1.1.0 verziótól a Graphite hivatalosan támogatja a címkéket. És aktívan azon dolgozunk, hogy támogassuk ezt az kezdeményezést a graphite+clickhouse stackben.

Graphite+ClickHouse. Anomáliadetektor

A fent említett infrastruktúra alapján egy prototípust valósítottunk meg az anomáliadetektorról, és működik! De erről — a következő cikkben.

Iratkozzanak fel, nyomjanak egy felfelé mutató nyilat, és legyenek boldogok!

Forrás: habr.com