Sziasztok! Az övében Írtam a mikroszolgáltatási architektúra moduláris felügyeleti rendszerének megszervezéséről. Semmi sem áll meg, projektünk folyamatosan növekszik, és a tárolt mutatók száma is. Hogyan szerveztük meg a Graphite+Whisperről a Graphite+ClickHouse-ra való átállást nagy terhelési körülmények között, olvassa el az ezzel kapcsolatos elvárásokat és a vágás alatti migráció eredményeit.
Mielőtt elmondanám, hogyan szerveztük meg az átállást a mérőszámok tárolásáról a Graphite+Whisperben a Graphite+ClickHouse-ra, szeretnék tájékoztatást adni egy ilyen döntés okairól és a Whisper hátrányairól, amelyekkel sokáig együtt éltünk.
Grafit+Suttogás problémák
1. Nagy terhelés a lemez alrendszeren
Az átállás idején körülbelül 1.5 millió mérőszám érkezett hozzánk percenként. Egy ilyen áramlás mellett a lemezkihasználás a szervereken ~30% volt. Általánosságban elmondható, hogy ez teljesen elfogadható volt – minden stabilan működött, gyorsan megírták, gyorsan olvashatók... Amíg az egyik fejlesztőcsapat ki nem fejlesztett egy új funkciót, és percenként 10 millió mérőszámot nem küldött nekünk. Ekkor szigorodott a lemez alrendszer, és 100%-os kihasználtságot láttunk. A probléma gyorsan megoldódott, de maradvány maradt.
2. A replikáció és a következetesség hiánya
Valószínűleg, mint mindenki, aki használja/használja a Graphite+Whispert, ugyanazt a mérőszámot öntöttük egyszerre több Graphite szerverre, hogy hibatűrést teremtsünk. És ezzel nem is volt különösebb probléma – egészen addig a pillanatig, amikor az egyik szerver valamilyen okból összeomlott. Néha elég gyorsan sikerült összeszednünk egy ledőlt szervert, és a carbon-c-relay-nek sikerült a gyorsítótárából metrikákat betölteni, de néha nem. Aztán volt egy lyuk a metrikákban, amit rsync-el pótoltunk. Az eljárás meglehetősen hosszú volt. Az egyetlen megmentő kegyelem az volt, hogy ez nagyon ritkán fordult elő. Időnként vettünk egy véletlenszerű metrikakészletet is, és összehasonlítottuk azokat a klaszter szomszédos csomópontjain lévő azonos típusú mérőszámokkal. Az esetek körülbelül 5%-ában több érték különbözött, aminek nem nagyon örültünk.
3. Nagy lábnyom
Mivel a Graphite-ban nem csak infrastruktúrát írunk, hanem üzleti mérőszámokat is (és most már Kubernetes mérőszámait is), gyakran kapunk olyan helyzetet, amikor a metrika csak néhány értéket tartalmaz, és a .wsp fájl minden megőrzést figyelembe véve jön létre. időszakban, és előre lefoglalt helyet foglal el, ami számunkra ~2MB volt. A problémát tovább súlyosbítja, hogy idővel nagyon sok hasonló fájl jelenik meg, és az ezekről készült jelentések elkészítésekor az üres pontok beolvasása sok időt és erőforrást igényel.
Azonnal szeretném megjegyezni, hogy a fent leírt problémákat különféle módszerekkel és különböző hatékonysággal lehet kezelni, de minél több adat érkezik, annál inkább súlyosbodnak.
A fentiek mindegyikével (figyelembe véve az előzőt ), valamint a fogadott mutatók számának állandó növekedése, az a vágy, hogy az összes mérőszámot 30 másodperces tárolási intervallumra vigyék át. (szükség esetén akár 10 másodpercig), úgy döntöttünk, hogy kipróbáljuk a Graphite+ClickHouse-t a Whisper ígéretes alternatívájaként.
Grafit+ClickHouse. Elvárások
Miután meglátogatta a Yandex srácainak több találkozóját, elolvasta , miután átnéztük a dokumentációt, és ésszerű alkatrészeket találtunk a ClickHouse Graphite alá kötéséhez, úgy döntöttünk, hogy intézkedünk!
Az alábbiakat szeretném megkapni:
- a lemezalrendszer kihasználtságának csökkentése 30%-ról 5%-ra;
- csökkentse az elfoglalt terület mennyiségét 1 TB-ról 100 GB-ra;
- percenként 100 millió mérőszámot tudjon fogadni a szerverre;
- adatreplikáció és hibatűrés a dobozból;
- ne üljön egy évig ezen a projekten, és ésszerű időn belül hajtsa végre az átállást;
- kapcsoló leállás nélkül.
Elég ambiciózus, igaz?
Grafit+ClickHouse. Alkatrészek
A Graphite protokollon keresztüli adatok fogadásához, majd a ClickHouse-ban történő rögzítéséhez választottam (golang).
Az idősorok tárolására szolgáló adatbázisnak a ClickHouse legújabb kiadását, az 1.1.54253-as stabil verziót választották. Problémák adódtak a vele való munka során: rengeteg hiba ömlött a rönkökbe, és nem volt teljesen világos, hogy mit kezdjünk velük. Megbeszélés alatt (a carbon-clickhouse, graphite-clickhouse és még sok más szerzője) a régebbire esett a választás . A hibák eltűntek – minden rohamosan működni kezdett.
Kiválasztva a ClickHouse adatainak olvasásához (golang). A Graphite API-jaként − (golang). A ClickHouse-t a táblák közötti replikáció megszervezésére használták . Az útválasztási mérőszámokért elhagytuk kedvesünket (C) .
Grafit+ClickHouse. Táblázat szerkezete
A „grafit” egy adatbázis, amelyet a megfigyelési táblákhoz hoztunk létre.
"graphite.metrics" - táblázat ReplicatedReplacingMergeTree motorral (replikált ). Ez a tábla a metrikák és a hozzájuk vezető útvonalak nevét tárolja.
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" - táblázat ReplicatedGraphiteMergeTree motorral (replikált ). Ez a táblázat a metrikaértékeket tárolja.
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 kitöltött táblázat a ReplicatedReplacingMergeTree motorral. Ez a táblázat a nap folyamán talált összes metrika nevét rögzíti. Létrehozásának okait a fejezet ismerteti a cikk végén.
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” – a feltételeknek megfelelően kitöltött táblázat a ReplicatedAggregatingMergeTree motorral (replikált ). Ez a táblázat a beérkező mutatók számát rögzíti, 4 beágyazási szintre lebontva.
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, PrefixGrafit+ClickHouse. Alkatrész kölcsönhatás diagram
Grafit+ClickHouse. Adatmigrálás
Ahogyan a projekttel kapcsolatos elvárásokból is emlékszünk, a ClickHouse-ra való átállásnak leállásmentesnek kell lennie, ennek megfelelően a teljes felügyeleti rendszerünket valahogy a lehető legátláthatóbban át kellett állítanunk az új tárhelyre.
Mi így csináltuk.
-
Egy szabály került hozzáadásra a carbon-c-relay-hez, amely további metrikafolyamot küld a ClickHouse táblák replikációjában részt vevő egyik kiszolgáló szén-clickhouse-jába.
-
Írtunk egy kis szkriptet pythonban, amely a whisper-dump könyvtár segítségével beolvassa az összes .wsp fájlt a tárhelyünkről, és ezeket az adatokat 24 szálban elküldte a fent leírt carbon-clickhouse-nak. A karbon-clickhouse-ban az elfogadott metrikaértékek száma elérte a 125 millió/perc értéket, és a ClickHouse még csak izzadt sem volt.
-
Létrehoztunk egy külön adatforrást a Grafana-ban a meglévő irányítópultokon használt funkciók hibakeresésére. Meghatároztuk az általunk használt függvények listáját, de a carbonapiban nem voltak implementálva. Ezeket a funkciókat hozzáadtuk, és PR-t küldtünk a carbonapi szerzőinek (külön köszönet nekik).
- Az olvasási terhelés megváltoztatásához a kiegyenlítő beállításaiban a végpontokat graphite-api-ról (API-interfész a Graphite+Whisperhez) carbonapi-ra változtattuk.
Grafit+ClickHouse. eredmények
-
a lemezalrendszer kihasználtságának csökkentése 30%-ról 1%-ra;
- az elfoglalt terület mennyisége 1 TB-ról 300 GB-ra csökkent;
- képesek vagyunk percenként 125 millió mérőszámot fogadni a szerverre (a migráció idején a csúcsok);
- az összes mérőszámot átvitte egy harminc másodperces tárolási intervallumba;
- fogadott adatok replikációja és hibatűrése;
- leállás nélkül kapcsolva;
- Körülbelül 7 hétbe telt, mire mindenre sikerült.
Grafit+ClickHouse. Problémák
A mi esetünkben volt néhány buktató. Ezzel találkoztunk az átállás után.
- A ClickHouse nem mindig olvassa újra a konfigurációkat menet közben, néha újra kell indítani. Például a ClickHouse konfigurációban a zookeeper klaszter leírása esetén nem használták a clickhouse-szerver újraindításáig.
- A nagy ClickHouse kérések nem mentek át, így a grafit-clickhouse-ban a ClickHouse kapcsolati karakterláncunk így néz ki:
url = "http://localhost:8123/?max_query_size=268435456&max_ast_elements=1000000" - A ClickHouse gyakran ad ki stabil kiadások új verzióit, amelyek meglepetéseket tartalmazhatnak: légy óvatos.
- A kubernetesben dinamikusan létrehozott tárolók nagyszámú metrikát küldenek rövid és véletlenszerű élettartammal. Az ilyen mérőszámokért nem sok pont jár, és a hellyel sincs gond. De a lekérdezések összeállításakor a ClickHouse rengeteg ilyen mérőszámot vesz fel a „metrics” táblázatból. Az esetek 90%-ában az ablakon túl (24 óra) nincs róluk adat. De időt töltenek az adatok keresésével az „adat” táblázatban, és végül időtúllépésbe kerül. A probléma megoldása érdekében elkezdtünk egy külön nézetet fenntartani a napközben tapasztalt mérőszámokkal kapcsolatos információkkal. Így a dinamikusan létrehozott tárolókra vonatkozó jelentések (grafikonok) készítésekor csak azokat a metrikákat kérdezzük le, amelyek egy adott ablakon belül találkoztak, nem pedig a teljes időtartamra, ami jelentősen felgyorsította az ezekről szóló jelentések elkészítését. A fent leírt megoldáshoz gyűjtöttem , amely magában foglalja a date_metrics táblával való munkavégzés megvalósítását.
Grafit+ClickHouse. Címkék
Az 1.1.0-s verzióval a Graphite hivatalossá vált . És aktívan gondolkodunk azon, hogy mit és hogyan tegyünk, hogy támogassuk ezt a kezdeményezést a grafit+clickhouse veremben.
Grafit+ClickHouse. Anomália detektor
A fent leírt infrastruktúra alapján megvalósítottuk egy anomália detektor prototípusát, és működik! De többet róla a következő cikkben.
Iratkozz fel, nyomd meg a felfelé mutató nyilat és légy boldog!
Forrás: will.com