Hej alla! I min den föregående artikeln. jag skrev om att organisera ett modulärt övervakningssystem för mikrotjänstarkitektur. Inget står still, vårt projekt växer ständigt och mängden lagrade metrikar ökar också. Hur vi organiserade övergången från Graphite+Whisper till Graphite+ClickHouse under hög belastning, samt våra förväntningar och resultaten av migreringen, kan du läsa nedan.

Innan jag berättar hur vi organiserade övergången från lagring av metrikar i Graphite+Whisper till Graphite+ClickHouse vill jag ge information om orsakerna till att vi fattade detta beslut och de nackdelar med Whisper som vi levde med under en längre tid.

Problem med Graphite+Whisper

1. Hög belastning på diskunderlaget

Vid tidpunkten för övergången fick vi in ungefär 1,5 miljoner metrikar per minut. Med denna ström var diskutnyttjandet på servrarna cirka ~30%. Så sett var det helt acceptabelt - allt fungerade stabilt, skrevs snabbt och lästes snabbt... Tills en av utvecklingsteamens lanserade en ny funktion och började skicka oss 10 miljoner metrikar per minut. Då pressades diskunderlaget, och vi såg 100% utnyttjande. Problemet lyckades vi snabbt lösa, men vi kände av det.

2. Avsaknad av replikering och konsistens

Troligtvis som alla som använder/använde Graphite+Whisper så skickade vi samma ström av metrikar till flera Graphite-servrar för att skapa redundans. Och med detta hade vi inga större problem - tills en av servrarna föll av någon anledning. Ibland lyckades vi återstarta den fallna servern tillräckligt snabbt, och carbon-c-relay lyckades ladda metrikarna från sin cache, men ibland gjorde den inte det. Och då fanns det ett glapp i metrikarna som vi fick täcka med rsync. Proceduren var ganska lång. Det enda som räddade oss var att det hände väldigt sällan. Vi tog också regelbundet ett slumpmässigt urval av metrikar och jämförde dem med likadana på angränsande noder i klustret. I ungefär 5% av fallen varierade flera värden, vilket inte gladde oss särskilt mycket.

3. Stor volym av upptagen plats

Eftersom vi skriver i Graphite inte bara infrastrukturmässiga utan också affärsmetriker (och nu även metrik från Kubernetes), får vi ganska ofta situationer där metriken bara innehåller några få värden, medan .wsp-filen skapas med hänsyn till hela retentionperioden och upptar det förutbestämda utrymme som vi haft, vilket var cirka ~2 MB. Problemet förvärras också av att sådana filer med tiden blir mycket många, och när man skapar rapporter på dem går det åt mycket tid och resurser för att läsa tomma punkter.

Det är viktigt att nämna att de problem som beskrivits ovan kan bekämpas med olika metoder och med varierande grad av effektivitet, men ju mer data som börjar strömma in, desto mer akuta blir dessa problem.

Med allt ovanstående (med hänsyn till tidigare artiklar), samt den ständiga ökningen av antalet mottagna metrik, önskan att översätta alla metriker till en lagringsintervall på 30 sekunder (vid behov — ner till 10 sekunder), beslutade vi oss för att pröva Graphite+ClickHouse som en lovande alternativ till Whisper.

Graphite+ClickHouse. Förväntningar

Efter att ha besökt ett par meetups med killarna från Yandex, läst några artiklar på Habré, genomsökt dokumentationen och hittat användbara komponenter för att integrera ClickHouse med Graphite, bestämde vi oss för att agera!

Vi ville uppnå följande:

• minska diskens utnyttjande från 30% till 5%;
• minska det upptagna utrymmet från 1 TB till 100 GB;
• ha möjlighet att ta emot 100 miljoner metrik per minut på servrar;
• datakopiering och redundans ur lådan;
• inte spendera ett år på det här projektet och göra övergången inom en rimlig tidsram;
• omkoppla utan driftstopp.

Ganska ambitiöst, eller hur?

Graphite+ClickHouse. Komponenter

För att få data via Graphite-protokollet och efterföljande uppdatering till ClickHouse valdes carbon-clickhouse (golang).

Som databas för lagring av tidsserier valdes den senaste stabila versionen av ClickHouse, som vid den tiden var 1.1.54253. När vi arbetade med den uppstod problem: det dumpades mängder av fel i loggarna och det var inte helt klart vad vi skulle göra med dem. I diskussion med Roman Lomonosov (skapare av carbon-clickhouse, graphite-clickhouse och mycket, mycket mer) valdes en äldre version 1.1.54236. Felen försvann — allt började fungera utmärkt.

För att läsa data från ClickHouse valdes graphite-slickhouse (golang). Som API-gränssnitt för Graphite — carbonapi (golang). För att organisera replikering mellan tabeller i ClickHouse användes zookeeper. För att dirigera metrikerna behöll vi vår älskade carbon-c-relay (C) (se föregående artikel).

Graphite+ClickHouse. Tabellstrukturen

“graphite” — en databas som vi skapade för övervakningstabeller.

“graphite.metrics” — en tabell med ReplicatedReplacingMergeTree-motorn (replicerad ReplacingMergeTree). I denna tabell lagras namnen på metrikerna och deras sökvägar.

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” — en tabell med ReplicatedGraphiteMergeTree-motorn (replicerad GraphiteMergeTree). I denna tabell lagras värdena för metrikerna.

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” — en tabell som fylls under vissa villkor, med ReplicatedReplacingMergeTree-motorn. Namnen på alla metrik som förekommit under dygn lagras i denna tabell. Orsaken till skapandet beskrivs i avsnittet «Problem» i slutet av denna artikel.

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” — en tabell som fylls under vissa villkor, med ReplicatedAggregatingMergeTree-motorn (replicerad AggregatingMergeTree). I denna tabell lagras antalet inkommande metrik med uppdelning ned till 4 nivåer av inbäddning.

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. Komponentinteraktionens schema

Graphite+ClickHouse. Datamigrering

Som vi minns från förväntningarna på detta projekt, bör övergången till ClickHouse ske utan driftstopp, därför måste vi på något sätt växla hela vårt övervakningssystem till det nya lagret så transparent som möjligt för våra användare.
Så här gjorde vi det.

• I carbon-c-relay lade vi till en regel för att skicka en extra ström av metrik till carbon-clickhouse från en av de servrar som deltar i replikeringen av ClickHouse-tabeller.

• Vi skrev ett litet skript i Python som med hjälp av biblioteket whisper-dump läste av alla .wsp-filer från vårt förråd och skickade dessa data till den ovan nämnda carbon-clickhouse i 24 trådar. Antalet mottagna värden för mätningar i carbon-clickhouse nådde upp till 125 miljoner/min, och ClickHouse blev inte ens ansträngd.

• Vi skapade en separat DataSource i Grafana för att felsöka funktioner som används i befintliga dashboards. Vi identifierade en lista med funktioner som vi använde, men de var inte implementerade i carbonapi. Vi kompletterade dessa funktioner och skickade PR:er till författarna av carbonapi (ett särskilt tack till dem).

• För att styra läsbelastningen i inställningarna för lastbalanserarna ändrade vi slutpunkterna från graphite-api (API-gränssnittet för Graphite+Whisper) till carbonapi.

Graphite+ClickHouse. Resultat

• minskade diskens utnyttjande från 30% till 1%;

  

• minskade det upptagna utrymmet från 1 TB till 300 GB;
• har möjlighet att ta emot 125 miljoner mätningar per minut till servern (toppar under migreringen);
• överförde alla mätningar till en trettio sekunders lagringsintervall;
• fick dat replication och hög tillgänglighet;
• bytte utan driftstopp;
• vi spenderade totalt cirka 7 veckor.

Graphite+ClickHouse. Problem

I vårt fall stötte vi på några hinder. Här är vad vi stötte på efter övergången.

1. ClickHouse läser inte alltid om konfigurationerna i realtid, ibland måste den startas om. Till exempel, i fallet med beskrivningen av klustret zookeeper i ClickHouse-konfigurationen — applicerades det inte förrän clickhouse-servern startades om.
2. Stora förfrågningar passerade inte i ClickHouse, så vår anslutningssträng till ClickHouse i graphite-clickhouse ser ut så här:

   url = "http://localhost:8123/?max_query_size=268435456&max_ast_elements=1000000"

3. I ClickHouse släpps ganska ofta nya versioner av stabila utgåvor, och det kan finnas överraskningar i dem: var försiktig.
4. Dynamiskt skapade containrar i Kubernetes skickar en stor mängd mätningar med kort och slumpmässig livslängd. Det finns inte många punkter för sådana mätningar, och det finns inga problem med utrymmet. Men när vi bygger frågor höjer ClickHouse en enorm mängd av dessa mätningar från tabellen 'metrics'. I 90 % av fallen saknas data för dem under fönstret (24 timmar). Men tiden som spenderas på att söka efter dessa data i tabellen 'data' är påtaglig och resulterar i sista hand i en timeout. För att lösa detta problem började vi hålla en separat vy med information om de mätningar som har förekommit under ett dygn. Därmed, vid skapandet av rapporter (diagram) för dynamiskt skapade containrar, frågar vi endast de mätningar som har förekommit inom det angivna fönstret, snarare än att ta med hela tiden, vilket har ökat hastigheten för skapandet av rapporter avsevärt. graphite-clickhouse (fork), som inkluderar implementeringen av arbete med tabellen date_metrics.

Graphite+ClickHouse. Taggar

Från version 1.1.0 började Graphite officiellt stötta taggar. Och vi tänker aktivt på vad och hur vi ska göra för att stödja denna initiativ i stacken graphite+clickhouse.

Graphite+ClickHouse. Anomalidetektor

Baserat på den beskrivna infrastrukturen har vi implementerat en prototyp av anomalidetektorn, och den fungerar! Men mer om det i nästa artikel.

Prenumerera, tryck på uppåtpilen och var lycklig!

Källa: habr.com