Hej alle! I hans sidste artikel Jeg skrev om at organisere et modulært overvågningssystem til en mikroservicearkitektur. Intet står stille, vores projekt vokser konstant, og det samme er antallet af lagrede metrics. Hvordan vi organiserede overgangen fra Graphite + Whisper til Graphite + ClickHouse under høje belastningsforhold, læs om forventningerne fra det og resultaterne af migreringen under cut.

Inden jeg fortæller dig, hvordan vi organiserede overgangen fra lagring af metrics i Graphite + Whisper til Graphite + ClickHouse, vil jeg gerne give oplysninger om årsagerne til at træffe en sådan beslutning og om ulemperne ved Whisper, som vi levede med i lang tid.

Grafit+Hvisken problemer

1. Høj belastning på diskens undersystem

På tidspunktet for overgangen fløj cirka 1.5 millioner målinger i minuttet til os. Med dette flow var diskudnyttelsen på serverne ~30 %. Generelt var det ganske acceptabelt - alt fungerede stabilt, blev skrevet hurtigt, læst hurtigt ... Indtil et af udviklingsteamene rullede en ny funktion ud og begyndte at sende os 10 millioner metrics i minuttet. Det var dengang, at diskundersystemet strammede op, og vi så 100% udnyttelse. Problemet blev hurtigt løst, men sedimentet forblev.

2. Manglende replikation og konsistens

Mest sandsynligt, ligesom alle, der bruger / brugte Graphite + Whisper, hældte vi den samme strøm af metrikker til flere Graphite-servere på én gang for at skabe fejltolerance. Og der var ingen særlige problemer med dette - indtil det øjeblik, hvor en af serverne ikke faldt af en eller anden grund. Nogle gange lykkedes det os at få den faldne server frem hurtigt nok, og carbon-c-relay formåede at fylde den med metrics fra sin cache, og nogle gange ikke. Og så var der et hul i metrikken, som vi strammede med rsync. Proceduren var ret lang. Kun reddet af, at dette skete meget sjældent. Vi tog også med jævne mellemrum et tilfældigt sæt metrikker og sammenlignede dem med andre lignende på tilstødende noder i klyngen. I omkring 5% af tilfældene var flere værdier forskellige, hvilket ikke gjorde os særlig glade.

3. Stor mængde plads optaget

Da vi i Graphite ikke kun skriver infrastruktur, men også forretningsmetrik (og nu også metrics fra Kubernetes), får vi ret ofte en situation, hvor der kun er få værdier i metrikken, og .wsp-filen oprettes ved at tage tage højde for hele opbevaringsperioden, og optager en forudtildelt mængde plads, som vi havde ~ 2 MB. Problemet forværres af, at der er mange sådanne filer over tid, og når man bygger rapporter på dem, tager det meget tid og ressourcer at læse tomme punkter.

Jeg vil med det samme bemærke, at de ovenfor beskrevne problemer kan håndteres med forskellige metoder og med varierende grader af effektivitet, men jo flere data du begynder at modtage, jo mere forværres de.

At have alt ovenstående (under hensyntagen til det foregående Artikel), samt en konstant stigning i antallet af modtagne målinger, ønsket om at overføre alle målinger til et lagringsinterval på 30 sekunder. (op til 10 sekunder om nødvendigt), besluttede vi at prøve Graphite+ClickHouse som et lovende alternativ til Whisper.

Grafit+ClickHouse. forventninger

Efter at have besøgt flere møder med fyrene fra Yandex, efter at have læst et par artikler om Habré, efter at have gennemgået dokumentationen og fundet fornuftige komponenter til at binde ClickHouse under grafit, besluttede vi at handle!

Vil gerne have følgende:

reducere udnyttelsen af diskundersystemet fra 30 % til 5 %;
reducere mængden af optaget plads fra 1 TB til 100 GB;
være i stand til at modtage 100 millioner metrics pr. minut til serveren;
datareplikering og fejltolerance ud af boksen;
ikke sidde på dette projekt i et år og gøre overgangen i en fornuftig periode;
skifte uden nedetid.

Ret ambitiøst, ikke?

Grafit+ClickHouse. Komponenter

For at modtage data via Graphite-protokollen og derefter skrive dem til ClickHouse, valgte jeg kulstof-klikhus (golang).

Den sidste ClickHouse-udgivelse af den stabile version 1.1.54253 blev valgt som database til lagring af tidsserier. Når man arbejdede med det, var der problemer: et bjerg af fejl strømmede ind i logfilerne, og det var ikke helt klart, hvad man skulle gøre med dem. I diskussion med Roman Lomonosov (forfatter til carbon-clickhouse, graphite-clickhouse og meget mere) den ældre blev valgt udgivelse 1.1.54236. Fejl forsvandt - alt begyndte at fungere med et brag.

At læse data fra ClickHouse blev valgt grafit-klikhus (golang). Som en API til grafit - carbonapi (golang). Til at organisere replikering mellem tabeller blev ClickHouse brugt dyrepasser. For routing-metrics forlod vi vores elskede carbon-c-relæ (C) (se tidligere artikel).

Grafit+ClickHouse. Bordstruktur

"grafit" er en database, vi har oprettet til overvågning af tabeller.

"graphite.metrics" er en tabel med ReplicatedReplacingMergeTree-motoren (replikeret Udskifter MergeTree). Denne tabel gemmer navnene på metrikken og stierne til dem.

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" er en tabel med ReplicatedGraphiteMergeTree-motoren (replikeret GraphiteMergeTree). Denne tabel gemmer metriske værdier.

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" er en betinget udfyldt tabel med ReplicatedReplacingMergeTree-motoren. Denne tabel indeholder navnene på alle de metrics, der blev stødt på i løbet af dagen. Årsagerne til oprettelsen er beskrevet i afsnittet "Problemer" i slutningen af denne 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" er en betinget tabel med ReplicatedAggregatingMergeTree-motoren (replikeret AggregatingMergeTree). Denne tabel registrerer antallet af indgående metrics, opdelt til 4 niveauer af indlejring.

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

Grafit+ClickHouse. Skema for interaktion mellem komponenter

Grafit+ClickHouse. Datamigrering

Som vi husker fra forventningerne fra dette projekt, skulle overgangen til ClickHouse være uden nedetid, hhv. vi måtte på en eller anden måde skifte hele vores overvågningssystem til det nye lager så gennemsigtigt som muligt for vores brugere.
Vi gjorde det på denne måde.

En regel blev føjet til carbon-c-relay for at sende en ekstra strøm af metrikker til carbon-clickhouse på en af de servere, der er involveret i replikeringen af ClickHouse-tabeller.
Vi skrev et lille python-script, der ved hjælp af whisper-dump-biblioteket læste alle .wsp-filerne fra vores lager og sendte disse data til carbon-clickhouse beskrevet ovenfor i 24 tråde. Antallet af accepterede metriske værdier i carbon-clickhouse nåede 125 millioner / min., og ClickHouse sved ikke engang.
Vi oprettede en separat DataSource i Grafana for at fejlsøge de funktioner, der bruges i eksisterende dashboards. Afslørede en liste over funktioner, som vi brugte, men de blev ikke implementeret i carbonapi. Vi afsluttede disse funktioner og sendte PR'er til forfatterne af carbonapi (særlig tak til dem).
For at skifte læsebelastningen i balancer-indstillingerne ændrede vi endepunkter fra grafit-api (API-grænseflade for Graphite+Whisper) til carbonapi.

Grafit+ClickHouse. resultater

reducerede udnyttelsen af diskundersystemet fra 30% til 1%;
reduceret mængden af optaget plads fra 1 TB til 300 GB;
vi har mulighed for at modtage 125 millioner metrics pr. minut pr. server (peaks på migrationstidspunktet);
overførte alle metrikker til et XNUMX sekunders lagerinterval;
modtagne datareplikering og fejltolerance;
skiftet uden nedetid;
Det tog omkring 7 uger for alt.

Grafit+ClickHouse. Problemer

I vores tilfælde var der nogle faldgruber. Her er hvad vi stødte på efter overgangen.

ClickHouse genlæser ikke altid konfigurationer i farten, nogle gange skal den genindlæses. For eksempel, i tilfælde af beskrivelsen af zookeeper-klyngen i ClickHouse-konfigurationen, blev den ikke anvendt, før clickhouse-serveren blev genstartet.
Der var ingen store ClickHouse-anmodninger, så i vores grafit-clickhouse ser ClickHouse-forbindelsesstrengen sådan ud:
```
url = "http://localhost:8123/?max_query_size=268435456&max_ast_elements=1000000"
```
ClickHouse udgiver ret ofte nye versioner af stabile udgivelser, de kan indeholde overraskelser: vær forsigtig.
Dynamisk oprettede containere i kubernetes sender et stort antal metrics med en kort og tilfældig levetid. Der er ikke mange point ifølge sådanne målinger, og der er ingen problemer med stedet. Men når man bygger forespørgsler, rejser ClickHouse et stort antal af de samme metrics fra 'metrics'-tabellen. I 90 % af tilfældene er der ingen data for dem uden for vinduet (24 timer). Men den tid, der bruges på at søge efter disse data i 'data'-tabellen, bruges og hviler i sidste ende på en timeout. For at løse dette problem begyndte vi at opretholde en separat visning med oplysninger om de målinger, der blev stødt på i løbet af dagen. Når vi bygger rapporter (grafer) på dynamisk oprettede containere, spørger vi således kun de metrics, der blev stødt på inden for det angivne vindue, og ikke for hele tiden, hvilket i høj grad fremskyndede genereringen af rapporter om dem. Til ovennævnte opløsning blev indsamlet grafit-klikhus (gaffel), som omfatter implementering af arbejde med date_metrics-tabellen.

Grafit+ClickHouse. tags

Siden version 1.1.0 er Graphite blevet officiel support tags. Og vi tænker aktivt på, hvad og hvordan vi skal gøre for at støtte dette initiativ i grafit+klikhusstakken.

Grafit+ClickHouse. Anomali detektor

Baseret på den ovenfor beskrevne infrastruktur har vi implementeret en prototype anomalidetektor, og den virker! Men om ham - i næste artikel.

Abonner, tryk på pil op og vær glad!

Kilde: www.habr.com

Metrisk lagring: hvordan vi flyttede fra Graphite+Whisper til Graphite+ClickHouse