Pershendetje te gjitheve! Në të tijën artikulli i fundit Kam shkruar për organizimin e një sistemi monitorimi modular për arkitekturën e mikroshërbimeve. Asgjë nuk qëndron ende, projekti ynë po rritet vazhdimisht, dhe po kështu edhe numri i metrikave të ruajtura. Si e organizuam kalimin nga Graphite+Whisper në Graphite+ClickHouse në kushte të ngarkesës së lartë, lexoni për pritjet prej tij dhe rezultatet e migrimit nën prerje.

Para se t'ju tregoj se si e organizuam kalimin nga ruajtja e metrikave në Graphite+Whisper në Graphite+ClickHouse, do të doja të jap informacion në lidhje me arsyet e marrjes së një vendimi të tillë dhe për disavantazhet e Whisper me të cilat kemi jetuar për një kohë të gjatë.

Probleme Graphite+Whisper

1. Ngarkesa e lartë në nënsistemin e diskut

Në kohën e tranzicionit, afërsisht 1.5 milion metrikë po vinin tek ne në minutë. Me një rrjedhë të tillë, përdorimi i diskut në serverë ishte ~30%. Në përgjithësi, kjo ishte mjaft e pranueshme - gjithçka funksiononte në mënyrë të qëndrueshme, shkruhej shpejt, lexohej shpejt... Derisa një nga ekipet e zhvillimit nxori një veçori të re dhe filloi të na dërgonte 10 milionë metrikë në minutë. Kjo ishte kur nënsistemi i diskut u shtrëngua dhe ne pamë përdorim 100%. Problemi u zgjidh shpejt, por mbeti një mbetje.

2. Mungesa e përsëritjes dhe konsistencës

Me shumë mundësi, si të gjithë ata që përdorin/përdorin Graphite+Whisper, ne derdhëm të njëjtën rrjedhë metrike në disa serverë Graphite në të njëjtën kohë për të krijuar tolerancë ndaj gabimeve. Dhe nuk kishte probleme të veçanta me këtë - deri në momentin kur një nga serverët u rrëzua për ndonjë arsye. Ndonjëherë ne arrinim të merrnim një server të rënë mjaft shpejt dhe karbon-c-relay arrinte të ngarkonte metrikat nga cache e tij në të, por ndonjëherë jo. Dhe më pas kishte një vrimë në metrikë, të cilën e mbushëm me rsync. Procedura ishte mjaft e gjatë. I vetmi hir shpëtimtar ishte se kjo ndodhte shumë rrallë. Ne gjithashtu morëm periodikisht një grup metrikash të rastësishme dhe i krahasuam ato me të tjera të të njëjtit lloj në nyjet fqinje të grupit. Në rreth 5% të rasteve, disa vlera ishin të ndryshme, për të cilat ne nuk ishim shumë të kënaqur.

3. Gjurmë e madhe

Meqenëse ne shkruajmë në Graphite jo vetëm infrastrukturën, por edhe metrikat e biznesit (dhe tani edhe metrikat nga Kubernetes), shpesh marrim një situatë në të cilën metrika përmban vetëm disa vlera, dhe skedari .wsp krijohet duke marrë parasysh të gjithë mbajtjen periudhë, dhe zë një hapësirë të paracaktuar, e cila për ne ishte ~2MB. Problemi përkeqësohet edhe më shumë nga fakti se shumë skedarë të ngjashëm shfaqen me kalimin e kohës, dhe kur ndërtoni raporte mbi to, leximi i pikave boshe kërkon shumë kohë dhe burime.

Do të doja të vëreja menjëherë se problemet e përshkruara më lart mund të trajtohen duke përdorur metoda të ndryshme dhe me shkallë të ndryshme efektiviteti, por sa më shumë të dhëna të filloni të merrni, aq më shumë ato përkeqësohen.

Duke pasur të gjitha sa më sipër (duke marrë parasysh të mëparshmen Artikull), si dhe një rritje konstante e numrit të matjeve të marra, dëshira për të transferuar të gjitha metrikat në një interval ruajtjeje prej 30 sekondash. (deri në 10 sekonda nëse është e nevojshme), vendosëm të provojmë Graphite+ClickHouse si një alternativë premtuese ndaj Whisper.

Graphite+ClickHouse. Pritshmëritë

Pasi vizitova disa takime të djemve nga Yandex, duke lexuar disa artikuj mbi Habré, pasi kaluam dokumentacionin dhe gjetëm komponentë të arsyeshëm për lidhjen e ClickHouse nën Graphite, vendosëm të ndërmarrim veprime!

Unë do të doja të marr sa vijon:

zvogëloni përdorimin e nënsistemit të diskut nga 30% në 5%;
zvogëloni sasinë e hapësirës së zënë nga 1 TB në 100 GB;
të jetë në gjendje të marrë 100 milion metrikë në minutë në server;
përsëritja e të dhënave dhe toleranca e gabimeve jashtë kutisë;
mos u ulni në këtë projekt për një vit dhe bëni kalimin brenda një afati të arsyeshëm kohor;
kaloni pa ndërprerje.

Mjaft ambicioze, apo jo?

Graphite+ClickHouse. Komponentët

Për të marrë të dhëna nëpërmjet protokollit Graphite dhe për t'i regjistruar më pas në ClickHouse, unë zgjodha karbon-clickhouse (golang).

Lëshimi i fundit i ClickHouse, versioni i qëndrueshëm 1.1.54253, u zgjodh si baza e të dhënave për ruajtjen e serive kohore. Kishte probleme gjatë punës me të: një mal gabimesh u derdhën në shkrime dhe nuk ishte plotësisht e qartë se çfarë të bëhej me to. Në diskutim me Roman Lomonosov (autor i karbon-clickhouse, graphite-clickhouse dhe shumë e shumë të tjera) u zgjodh më i vjetri lëshimi 1.1.54236. Gabimet u zhdukën - gjithçka filloi të funksiononte me një zhurmë.

Zgjedhur për të lexuar të dhënat nga ClickHouse grafit-clickhouse (golang). Si një API për Grafit - karbonapi (golang). ClickHouse u përdor për të organizuar përsëritjen midis tabelave ruajtësi i kopshtit zoologjik. Për matjet e rrugëtimit, ne lamë të dashurin tonë karbon-c-rele (C) (shih artikullin e mëparshëm).

Graphite+ClickHouse. Struktura e tabelës

“grafiti” është një bazë të dhënash që kemi krijuar për tabelat e monitorimit.

"graphite.metrics" - tabela me motorin ReplicatedReplacingMergeTree (e përsëritur Duke zëvendësuar MergeTree). Kjo tabelë ruan emrat e metrikës dhe shtigjet drejt tyre.

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" - tabela me motorin ReplicatedGraphiteMergeTree (e përsëritur Graphite MergeTree). Kjo tabelë ruan vlerat metrike.

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" është një tabelë e mbushur me kusht me motorin ReplicatedReplacingMergeTree. Kjo tabelë regjistron emrat e të gjitha metrikave që janë hasur gjatë ditës. Arsyet e krijimit të tij janë përshkruar në seksion "Problemet" në fund të këtij artikulli.

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" - një tabelë e mbushur sipas kushteve, me motorin ReplicatedAggregatingMergeTree (i përsëritur Agregating MergeTree). Kjo tabelë regjistron numrin e metrikës hyrëse, të zbërthyer në 4 nivele foleje.

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. Diagrami i ndërveprimit të komponentëve

Graphite+ClickHouse. Migrimi i të dhënave

Siç kujtojmë nga pritshmëritë nga ky projekt, kalimi në ClickHouse duhet të jetë pa ndërprerje; në përputhje me rrethanat, ne duhej të kalonim disi të gjithë sistemin tonë të monitorimit në ruajtjen e re sa më transparente për përdoruesit tanë.
Kështu e kemi bërë.

Një rregull është shtuar në karbon-c-rele për të dërguar një rrjedhë shtesë të metrikës në qendrën e klikimeve të karbonit të një prej serverëve që marrin pjesë në riprodhimin e tabelave të ClickHouse.
Ne shkruam një skrip të vogël në python, i cili, duke përdorur bibliotekën whisper-dump, lexoi të gjithë skedarët .wsp nga ruajtja jonë dhe i dërgoi këto të dhëna në karbon-clickhouse të përshkruar më sipër në 24 tema. Numri i vlerave metrike të pranuara në karbon-clickhouse arriti në 125 milionë/min, dhe ClickHouse as që u mundua.
Ne krijuam një burim të veçantë të të dhënave në Grafana për të korrigjuar funksionet e përdorura në panelet ekzistuese. Ne identifikuam një listë funksionesh që përdorëm, por ato nuk u zbatuan në karbonapi. Ne i shtuam këto funksione dhe u dërguam PR autorëve të carbonapi (faleminderit të veçantë për ta).
Për të ndërruar ngarkesën e leximit në cilësimet e balancuesit, ne ndryshuam pikat fundore nga graphite-api (ndërfaqja API për Graphite+Whisper) në karbonapi.

Graphite+ClickHouse. rezultatet

reduktimi i përdorimit të nënsistemit të diskut nga 30% në 1%;
zvogëloi sasinë e hapësirës së zënë nga 1 TB në 300 GB;
ne kemi mundësinë të marrim 125 milionë metrikë në minutë në server (pikat në momentin e migrimit);
transferoi të gjitha metrikat në një interval ruajtjeje tridhjetë e dytë;
përsëritja e të dhënave të marra dhe toleranca e gabimeve;
ndërrohet pa ndërprerje;
U deshën rreth 7 javë për të përfunduar gjithçka.

Graphite+ClickHouse. Problemet

Në rastin tonë, kishte disa gracka. Kjo është ajo që kemi hasur pas tranzicionit.

ClickHouse jo gjithmonë i rilexon konfigurimet menjëherë; ndonjëherë duhet të rindizet. Për shembull, në rastin e përshkrimit të grupit të kujdestarit të kopshtit zoologjik në konfigurimin ClickHouse, ai nuk u përdor derisa serveri clickhouse u rindez.
Kërkesat e mëdha të ClickHouse nuk kaluan, kështu që në grafit-clickhouse vargu ynë i lidhjes ClickHouse duket si ky:
```
url = "http://localhost:8123/?max_query_size=268435456&max_ast_elements=1000000"
```
ClickHouse mjaft shpesh lëshon versione të reja të lëshimeve të qëndrueshme; ato mund të përmbajnë surpriza: kini kujdes.
Kontejnerët e krijuar në mënyrë dinamike në kubernetes dërgojnë një numër të madh metrikash me një jetëgjatësi të shkurtër dhe të rastësishme. Nuk ka shumë pika për metrikë të tillë, dhe nuk ka probleme me hapësirën. Por kur ndërton pyetje, ClickHouse zgjedh një numër të madh të këtyre metrikave nga tabela 'metrika'. Në 90% të rasteve nuk ka të dhëna për to përtej dritares (24 orë). Por koha harxhohet duke kërkuar për këto të dhëna në tabelën e 'të dhënave' dhe përfundimisht përfundon në një afat kohor. Për të zgjidhur këtë problem, filluam të mbajmë një pamje të veçantë me informacione mbi metrikat që u ndeshën gjatë ditës. Kështu, kur ndërtojmë raporte (grafikë) për kontejnerë të krijuar në mënyrë dinamike, ne kërkojmë vetëm ato metrika që janë hasur brenda një dritareje të caktuar, dhe jo për të gjithë kohën, gjë që shpejtoi ndjeshëm ndërtimin e raporteve mbi to. Për zgjidhjen e përshkruar më sipër, mblodha grafit-clickhouse (pirun), e cila përfshin zbatimin e punës me tabelën date_metrics.

Graphite+ClickHouse. Etiketat

Me versionin 1.1.0 Graphite u bë zyrtar etiketat mbështetëse. Dhe ne jemi duke menduar në mënyrë aktive se çfarë dhe si të bëjmë për të mbështetur këtë iniciativë në raftin graphite+clickhouse.

Graphite+ClickHouse. Detektor i anomalive

Bazuar në infrastrukturën e përshkruar më sipër, ne kemi implementuar një prototip të një detektori anomalish dhe funksionon! Por më shumë rreth tij në artikullin vijues.

Abonohuni, shtypni shigjetën lart dhe jini të lumtur!

Burimi: www.habr.com

Ruajtja e metrikës: si kaluam nga Graphite+Whisper në Graphite+ClickHouse