Hei alle sammen! I hans siste artikkel Jeg skrev om å organisere et modulært overvåkingssystem for mikrotjenestearkitektur. Ingenting står stille, prosjektet vårt vokser stadig, og det samme er antallet lagrede beregninger. Hvordan vi organiserte overgangen fra Graphite+Whisper til Graphite+ClickHouse under høye belastningsforhold, les om forventningene fra det og resultatene av migreringen under kuttet.

Før jeg forteller deg hvordan vi organiserte overgangen fra å lagre beregninger i Graphite+Whisper til Graphite+ClickHouse, vil jeg gjerne gi informasjon om årsakene til å ta en slik beslutning og om ulempene med Whisper som vi levde med lenge.

Problemer med grafitt+hvisking

1. Høy belastning på diskundersystemet

På tidspunktet for overgangen kom omtrent 1.5 millioner beregninger til oss per minutt. Med en slik flyt var diskutnyttelsen på servere ~30 %. Generelt var dette ganske akseptabelt - alt fungerte stabilt, ble skrevet raskt, lest raskt... Helt til et av utviklingsteamene rullet ut en ny funksjon og begynte å sende oss 10 millioner beregninger per minutt. Det var da diskundersystemet strammet opp, og vi så 100% utnyttelse. Problemet ble raskt løst, men en rest gjensto.

2. Mangel på replikering og konsistens

Mest sannsynlig, som alle som bruker/brukte Graphite+Whisper, helte vi den samme strømmen av beregninger på flere Graphite-servere samtidig for å skape feiltoleranse. Og det var ingen spesielle problemer med dette - inntil øyeblikket da en av serverne krasjet av en eller annen grunn. Noen ganger klarte vi å plukke opp en falt server raskt nok, og carbon-c-relay klarte å laste inn beregninger fra cachen til den, men noen ganger ikke. Og så var det et hull i metrikken, som vi fylte med rsync. Prosedyren var ganske lang. Den eneste frelsende nåden var at dette skjedde svært sjelden. Vi tok også med jevne mellomrom et tilfeldig sett med beregninger og sammenlignet dem med andre av samme type på nabonoder i klyngen. I omtrent 5 % av tilfellene var flere verdier forskjellige, noe vi ikke var veldig fornøyd med.

3. Stort fotavtrykk

Siden vi skriver i Graphite ikke bare infrastruktur, men også forretningsberegninger (og nå også beregninger fra Kubernetes), får vi ganske ofte en situasjon der metrikken bare inneholder noen få verdier, og .wsp-filen opprettes under hensyntagen til all oppbevaring. periode, og tar opp en forhåndstildelt mengde plass, som for oss var ~2MB. Problemet forverres ytterligere av det faktum at mange lignende filer dukker opp over tid, og når man bygger rapporter på dem, tar det mye tid og ressurser å lese tomme punkter.

Jeg vil umiddelbart merke meg at problemene beskrevet ovenfor kan håndteres ved hjelp av ulike metoder og med ulik grad av effektivitet, men jo mer data du begynner å motta, jo mer forverres de.

Å ha alt det ovennevnte (ta hensyn til det forrige artikler), samt en konstant økning i antall mottatte beregninger, ønsket om å overføre alle beregninger til et lagringsintervall på 30 sekunder. (opptil 10 sekunder om nødvendig), bestemte vi oss for å prøve Graphite+ClickHouse som et lovende alternativ til Whisper.

Grafitt+ClickHouse. Forventninger

Etter å ha besøkt flere møter med gutta fra Yandex, etter å ha lest et par artikler om Habré, etter å ha gått gjennom dokumentasjonen og funnet fornuftige komponenter for binding av ClickHouse under Graphite, bestemte vi oss for å ta grep!

Jeg vil gjerne motta følgende:

redusere bruken av diskundersystem fra 30 % til 5 %;
redusere mengden plass okkupert fra 1 TB til 100 GB;
kunne motta 100 millioner beregninger per minutt inn på serveren;
datareplikering og feiltoleranse ut av esken;
ikke sitt på dette prosjektet i et år og foreta overgangen innen en rimelig tidsramme;
bryter uten nedetid.

Ganske ambisiøst, ikke sant?

Grafitt+ClickHouse. Komponenter

For å motta data via Graphite-protokollen og deretter registrere dem i ClickHouse, valgte jeg karbon-klikkhus (golang).

Den siste utgivelsen av ClickHouse, stabil versjon 1.1.54253, ble valgt som database for lagring av tidsserier. Det var problemer når man jobbet med det: et berg av feil strømmet inn i loggene, og det var ikke helt klart hva man skulle gjøre med dem. I diskusjon med Roman Lomonosov (forfatter av carbon-clickhouse, graphite-clickhouse og mange, mange flere) den eldste ble valgt utgivelse 1.1.54236. Feilene forsvant – alt begynte å fungere med et brak.

Valgt for å lese data fra ClickHouse grafitt-klikkhus (golang). Som et API for grafitt − karbonapi (golang). ClickHouse ble brukt til å organisere replikering mellom tabeller dyrepasser. For rutingmålinger forlot vi vår elskede karbon-c-relé (C) (se forrige artikkel).

Grafitt+ClickHouse. Tabellstruktur

"grafitt" er en database vi har laget for å overvåke tabeller.

"graphite.metrics" - tabell med ReplicatedReplacingMergeTree-motoren (replikert Erstatter MergeTree). Denne tabellen lagrer navnene på beregninger og stier 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" - tabell med ReplicatedGraphiteMergeTree-motoren (replikert GraphiteMergeTree). Denne tabellen lagrer metriske verdier.

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 fylt tabell med ReplicatedReplacingMergeTree-motoren. Denne tabellen registrerer navnene på alle beregninger som ble oppdaget i løpet av dagen. Årsakene til opprettelsen er beskrevet i avsnittet "Problemer" på slutten av denne artikkelen.

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 fylt i henhold til tilstanden, med ReplicatedAggregatingMergeTree-motoren (replikert AggregatingMergeTree). Denne tabellen registrerer antall innkommende beregninger, fordelt på 4 hekkenivåer.

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

Grafitt+ClickHouse. Komponentinteraksjonsdiagram

Grafitt+ClickHouse. Datamigrering

Som vi husker fra forventningene fra dette prosjektet, skulle overgangen til ClickHouse være uten nedetider, og derfor måtte vi på en eller annen måte bytte hele overvåkingssystemet til den nye lagringen så transparent som mulig for brukerne våre.
Slik gjorde vi det.

En regel er lagt til carbon-c-relay for å sende en ekstra strøm av beregninger til karbon-klikkhuset til en av serverne som deltar i replikeringen av ClickHouse-tabeller.
Vi skrev et lite skript i python, som ved å bruke whisper-dump-biblioteket leste alle .wsp-filer fra lagringen vår og sendte disse dataene til det ovenfor beskrevne carbon-clickhouse i 24 tråder. Antall aksepterte metriske verdier i carbon-clickhouse nådde 125 millioner/min, og ClickHouse svettet ikke engang.
Vi opprettet en egen DataSource i Grafana for å feilsøke funksjoner som brukes i eksisterende dashboards. Vi identifiserte en liste over funksjoner som vi brukte, men de ble ikke implementert i carbonapi. Vi la til disse funksjonene og sendte PR-er til forfatterne av carbonapi (spesiell takk til dem).
For å bytte lesebelastningen i balanserinnstillingene endret vi endepunktene fra grafitt-api (API-grensesnitt for Graphite+Whisper) til carbonapi.

Grafitt+ClickHouse. resultater

redusert bruk av diskundersystem fra 30 % til 1 %;
reduserte mengden plass okkupert fra 1 TB til 300 GB;
vi har muligheten til å motta 125 millioner beregninger per minutt inn på serveren (topp på tidspunktet for migrering);
overførte alle beregninger til et trettisekunders lagringsintervall;
mottatt datareplikering og feiltoleranse;
byttet uten nedetid;
Det tok ca 7 uker å fullføre alt.

Grafitt+ClickHouse. Problemer

I vårt tilfelle var det noen fallgruver. Dette er hva vi møtte etter overgangen.

ClickHouse leser ikke alltid konfigurasjoner på nytt, noen ganger må den startes på nytt. For eksempel, når det gjelder beskrivelsen av dyrepasserklyngen i ClickHouse-konfigurasjonen, ble den ikke brukt før clickhouse-serveren ble startet på nytt.
Store ClickHouse-forespørsler gikk ikke gjennom, så i graphite-clickhouse ser vår ClickHouse-tilkoblingsstreng slik ut:
```
url = "http://localhost:8123/?max_query_size=268435456&max_ast_elements=1000000"
```
ClickHouse slipper ganske ofte nye versjoner av stabile utgivelser; de kan inneholde overraskelser: vær forsiktig.
Dynamisk opprettede beholdere i kubernetes sender et stort antall beregninger med kort og tilfeldig levetid. Det er ikke mange poeng for slike beregninger, og det er ingen problemer med plass. Men når du bygger spørringer, plukker ClickHouse opp et stort antall av de samme beregningene fra 'metrics'-tabellen. I 90 % av tilfellene er det ingen data om dem utenfor vinduet (24 timer). Men tid brukes på å søke etter disse dataene i 'data'-tabellen, og går til slutt inn i et tidsavbrudd. For å løse dette problemet begynte vi å opprettholde en egen visning med informasjon om beregninger som ble møtt i løpet av dagen. Når vi bygger rapporter (grafer) for dynamisk opprettede beholdere, spør vi derfor bare de metrikkene som ble oppdaget innenfor et gitt vindu, og ikke for hele tiden, noe som betydelig fremskyndet konstruksjonen av rapporter om dem. For løsningen beskrevet ovenfor, samlet jeg grafitt-klikkhus (gaffel), som inkluderer implementering av arbeid med date_metrics-tabellen.

Grafitt+ClickHouse. Tagger

Med versjon 1.1.0 ble Graphite offisiell støttekoder. Og vi tenker aktivt på hva og hvordan vi skal gjøre for å støtte dette initiativet i grafitt+klikkhusstakken.

Grafitt+ClickHouse. Anomalidetektor

Basert på infrastrukturen beskrevet ovenfor har vi implementert en prototype av en anomalidetektor, og det fungerer! Men mer om ham i neste artikkel.

Abonner, trykk på pil opp og vær glad!

Kilde: www.habr.com

Metrikklagring: hvordan vi byttet fra Graphite+Whisper til Graphite+ClickHouse