ProHoster > Blog > Administrim > Ruajtja e metrikeve: si kaluam nga Graphite+Whisper në Graphite+ClickHouse

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

Të gjithëve përshëndetje! Në këtë artikullin e kaluar Shkruaja për organizimin e një sistemi modular monitorimi për arkitekturën mikroshërbimesh. Asgjë nuk qëndron në vend, projekti ynë është vazhdimisht në rritje, dhe numri i metrikave të ruajtura po rritet gjithashtu. Si e organizuam kalimin nga Graphite+Whisper në Graphite+ClickHouse në kushte ngarkesash të larta, për pritjet nga ai dhe rezultatet e migrimit, lexoni më poshtë.

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

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

Problemet me Graphite+Whisper

1. Ngarkesë e lartë në sistemin e diskut

NĂ« kohĂ«n e kalimit, ne merrnim rreth 1.5 milion metrika nĂ« minutĂ«. Me njĂ« fluks tĂ« tillĂ«, shfrytĂ«zimi i diskut nĂ« serverat ishte rreth ~30%. NĂ« pĂ«rgjithĂ«si, kjo ishte e pranueshme — gjithçka funksiononte stabilisht, shkruhej shpejt, lexohej shpejt
 Derisa njĂ«ra nga ekipet e zhvillimit publikoi njĂ« veçori tĂ« re dhe filloi tĂ« na dĂ«rgonte 10 milion metrika nĂ« minutĂ«. AtĂ«herĂ« sistemi i diskut u ngarkua, dhe ne pamĂ« 100% shfrytĂ«zim. Problemi u zgjidh shpejt, por mbeti njĂ« shenjĂ«.

2. Mungesë e replikimit dhe konsistencës

Ndoshta si tĂ« gjithĂ« ata qĂ« pĂ«rdorin/pĂ«rdorĂ«n Graphite+Whisper, ne derdhĂ«m tĂ« njĂ«jtin fluks metrikash nĂ« disa servera Graphite me qĂ«llim krijimin e qĂ«ndrueshmĂ«risĂ«. Dhe nuk kishte ndonjĂ« problem tĂ« madh — deri nĂ« momentin kur njĂ« nga serverat pĂ«r ndonjĂ« arsye nuk binte. NdonjĂ«herĂ« arrinim ta ngjisim serverin e rĂ«nĂ« mjaft shpejt, dhe carbon-c-relay arrinte tĂ« derdhte metrikat nga cache-i i tij, e ndonjĂ«herĂ« jo. Dhe atĂ«herĂ« kishte njĂ« boshllĂ«k nĂ« metrika, tĂ« cilin e mbushnim me rsync. Procedura ishte mjaft e gjatĂ«. Na shpĂ«tonte vetĂ«m fakti qĂ« ndodhte shumĂ« rrallĂ«. Po ashtu, herĂ« pas here merrnim njĂ« grup tĂ« rastĂ«sishĂ«m metrikash dhe i krahasonim ato me tĂ« tjera tĂ« tilla nĂ« nodet pĂ«rkatĂ«se tĂ« klasterit. NĂ« rreth 5% tĂ« rasteve, disa vlera ndryshonin, gjĂ« qĂ« nuk na bĂ«nte shumĂ« tĂ« lumtur.

3. Vëllimi i madh i hapësirës së zënë

Duke shkruajmë në Graphite jo vetëm metrikat e infrastrukturës, por edhe ato të biznesit ( dhe tani edhe metrikat nga Kubernetes), shpesh përballen me një situatë ku metrika ka vetëm disa vlera, dhe skedari .wsp krijohet duke marrë parasysh të gjithë periudhën e ruajtjes dhe merr hapësirën e paracaktuar që ishte rreth 2MB. Problemi përkeqësohet edhe më shumë nga fakti që me kalimin e kohës shfaqen shumë skedarë të tillë, dhe gjatë përgatitjes së raporteve mbi to, kalon shumë kohë dhe burime për të lexuar pikat bosh.

Fillimisht do të doja të theksoja se me problemet e përshkruara më sipër, mund të përballesh me metoda të ndryshme dhe me një shkallë të ndryshme efikasiteti, por sa më shumë të dhëna të fillojnë të vijnë, aq më shumë ato përkeqësohen.

Duke pasur gjithçka tĂ« pĂ«rmendur mĂ« parĂ« (duke marrĂ« parasysh) artikulli), si dhe rritjen e vazhdueshme tĂ« numrit tĂ« metrikeve tĂ« pranuara, dĂ«shira pĂ«r tĂ« rezervuar tĂ« gjitha metrikat nĂ« njĂ« interval ruajtjeje prej 30 sekondash (nĂ«se Ă«shtĂ« e nevojshme — deri nĂ« 10 sekonda), vendosĂ«m tĂ« provojmĂ« Graphite+ClickHouse si njĂ« alternativĂ« tĂ« perspektivĂ«s pĂ«r Whisper.

Graphite+ClickHouse. Pritet

Pas vizitave në disa mitape me djemtë e Yandex, duke lexuar disa artikuj në Habrë, pas shqyrtimit të dokumentacionit dhe gjetjes së komponenteve të arsyeshme për lidhjen e ClickHouse me Graphite, ne vendosëm të veprojmë!

Doja të merrja sa vijon:

  • tĂ« ulĂ« shfrytĂ«zimin e sistemit tĂ« diskut nga 30% nĂ« 5%;
  • tĂ« ulet hapĂ«sira e zĂ«nĂ« nga 1TB nĂ« 100GB;
  • tĂ« kem mundĂ«sinĂ« pĂ«r tĂ« pranuar 100 milion metrika nĂ« minutĂ« nĂ« server;
  • replikimin e tĂ« dhĂ«nave dhe qĂ«ndrueshmĂ«rinĂ« nga kutia;
  • tĂ« mos qĂ«ndroj mbi kĂ«tĂ« projekt pĂ«r njĂ« vit dhe tĂ« bĂ«j kalimin brenda njĂ« periudhe tĂ« arsyeshme;
  • tĂ« kaloj pa ndalim.

Mjaft ambicioze, apo jo?

Graphite+ClickHouse. Komponentet

Për të marrë të dhënat përmes protokollit Graphite dhe për të shkruar ato në ClickHouse, u zgjodh carbon-clickhouse (golang).

Si databazĂ« pĂ«r ruajtjen e serive temporale, u zgjodh versioni mĂ« i fundit nĂ« atĂ« kohĂ« i ClickHouse nĂ« versionin stabil 1.1.54253. Kur punoje me tĂ«, kishte probleme: logje tĂ« plota me gabime, dhe nuk ishte krejt e qartĂ« se çfarĂ« tĂ« bĂ«je me to. NĂ« diskutimin me Roman Lomonosovin (autori i carbon-clickhouse, graphite-clickhouse dhe shumĂ« e shumĂ« gjĂ«ra tĂ« tjera), u zgjodh njĂ« version mĂ« i vjetĂ«r 1.1.54236.Gabimet zhduken — gjithçka filloi tĂ« punojĂ« siç duhet.

PĂ«r leximin e tĂ« dhĂ«nave nga ClickHouse, u zgjodh graphite-slickhouse (golang). Si API pĂ«r Graphite — carbonapi (golang). PĂ«r organizimin e replikimit ndĂ«rmjet tabelave ClickHouse u pĂ«rdor zookeeper. PĂ«r ruterizimin e metrikave ne lanĂ« tĂ« dashurin tonĂ« carbon-c-relay (C) (shih artikullin e kaluar).

Graphite+ClickHouse. Struktura e tabelave

“graphite” — njĂ« bazĂ« tĂ« dhĂ«nash, e krijuar nga ne pĂ«r tabelat e monitorimit.

“graphite.metrics” — njĂ« tabelĂ« me motorin ReplicatedReplacingMergeTree (replicuar ReplacingMergeTree). NĂ« kĂ«tĂ« tabelĂ« ruhet emrat e metrikave dhe rrugĂ«t deri te to.

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” — njĂ« tabelĂ« me motorin ReplicatedGraphiteMergeTree (replicuar GraphiteMergeTree). NĂ« kĂ«tĂ« tabelĂ« ruhet vlerat e metrikave.

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” — njĂ« tabelĂ« qĂ« plotĂ«sohet nĂ«n kushte, me motorin ReplicatedReplacingMergeTree. NĂ« kĂ«tĂ« tabelĂ« regjistrohen emrat e tĂ« gjitha metrikave qĂ« u takuan brenda njĂ« dite. Arsyet e krijimit janĂ« pĂ«rshkruar nĂ« seksionin «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Ă« qĂ« plotĂ«sohet nĂ«n kushte, me motorin ReplicatedAggregatingMergeTree (replicuar AggregatingMergeTree). NĂ« kĂ«tĂ« tabelĂ« regjistrohet numri i metrikave tĂ« ardhura, me ndarjen deri nĂ« nivelin e 4 tĂ« brendĂ«sisĂ«.

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. Schema e ndërveprimit të komponenteve

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

Graphite+ClickHouse. Migrimi i të dhënave

Siç e kemi kujtuar nga pritshmëritë për këtë projekt, kalimi në ClickHouse duhet të bëhej pa ndalime, për rrjedhojë, ne duhej të kishim ndonjë mënyrë për të kaluar të gjithë sistemin tonë të monitorimit në sistemin e ri të ruajtjes sa më transparencë për përdoruesit tanë.
Kështu e bëmë këtë.

  • NĂ« carbon-c-relay shtuam njĂ« rregull pĂ«r tĂ« dĂ«rguar njĂ« rrjedhĂ« shtesĂ« metrikash nĂ« carbon-clickhouse tĂ« njĂ«rit nga serverĂ«t, tĂ« cilĂ«t morin pjesĂ« nĂ« replikimin e tabelave ClickHouse.

  • Krijuam njĂ« skript tĂ« vogĂ«l nĂ« python, i cili me ndihmĂ«n e bibliotekĂ«s whisper-dump lexonte tĂ« gjithĂ« .wsp-file nga depoja jonĂ« dhe dĂ«rgonte kĂ«to tĂ« dhĂ«na nĂ« carbon-clickhouse tĂ« pĂ«rmendur mĂ« parĂ« me 24 procese. Numri i vlerave tĂ« metrikave qĂ« pranohen nĂ« carbon-clickhouse arrinte deri nĂ« 125 milion/min, dhe ClickHouse as nuk u ndje.

  • Krijuam njĂ« DataSource tĂ« veçantĂ« nĂ« Grafana me qĂ«llim pĂ«r tĂ« debug-uar funksionet qĂ« pĂ«rdoren nĂ« dashboard-at ekzistues. Identifikuam listĂ«n e funksioneve qĂ« ne pĂ«rdoronim, por ato nuk ishin implementuar nĂ« carbonapi. Shtuam kĂ«to funksione, dhe dĂ«rguam PR-tĂ« autorĂ«ve tĂ« carbonapi (falĂ«nderim tĂ« veçantĂ« pĂ«r ta).

  • PĂ«r tĂ« ndryshuar ngarkesĂ«n lexuese, kemi ndryshuar endpoint-et nĂ« konfigurimin e balancuesve nga graphite-api (interfejsi API pĂ«r Graphite+Whisper) nĂ« carbonapi.

Graphite+ClickHouse. Rezultatet

  • ullĂ«m pĂ«rdorimin e sistemit tĂ« diskut nga 30% nĂ« 1%;

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

  • ullĂ«m volumet e hapĂ«sirĂ«s sĂ« zĂ«nĂ« nga 1 TB nĂ« 300 GB;
  • kemi mundĂ«sinĂ« tĂ« pranojmĂ« deri nĂ« 125 milion metrika nĂ« minutĂ« nĂ« server (kulmin gjatĂ« migrimit);
  • kemi transferuar tĂ« gjitha metrikat nĂ« intervalin e ruajtjes prej tridhjetĂ« sekondash;
  • kemi siguruar replikimin e tĂ« dhĂ«nave dhe qĂ«ndrueshmĂ«rinĂ« ndaj dĂ«shtimit;
  • kemi kaluar pa ndalim;
  • pĂ«r tĂ« gjitha shpenzuam rreth 7 javĂ«.

Graphite+ClickHouse. Problematikat

Në rastin tonë, nuk kaluam pa pengesa. Këtu janë disa nga sfidat që hasëm pas kalimit.

  1. ClickHouse nuk e lexon gjithmonĂ« konfigurimin nĂ« fluks, herĂ« pas here duhet ta rinisni. PĂ«r shembull, nĂ« rastin e pĂ«rshkrimit tĂ« klasterit zookeeper nĂ« konfigurimin e ClickHouse — nuk ishte aplikuar deri nĂ« rinisjen e clickhouse-server.
  2. Nuk kalonin kërkesa të mëdha në ClickHouse, prandaj linja jonë e lidhjes për graphite-clickhouse dukej kështu:
    url = "http://localhost:8123/?max_query_size=268435456&max_ast_elements=1000000"
  3. Në ClickHouse shpesh dalin versione të reja të qëndrueshme, ku mund të hasen surpriza: jini të kujdesshëm.
  4. Kontenierët që krijohen në mënyrë dinamike në Kubernetes dërgojnë një numër të madh metrike me periudha të shkurtra dhe të rastit jetese. Nuk ka shumë pika për këto metrika, dhe nuk ka probleme me hapësirën. Megjithatë, kur krijohen kërkesat, ClickHouse ngre një sasi të madhe të këtyre metrikeve nga tabela 'metrics'. Në 90% të rasteve, të dhënat për ta mungojnë në dritaren (24 orë). Por koha që shpenzohet për të gjetur këto të dhëna në tabelën 'data' është e madhe, dhe përfundon në kohën e ndërprerjes. Për të zgjidhur këtë problem, filluam të mbajmë një pamje të veçantë me informacion mbi metrikët që janë hasur në 24 orët e fundit. Në këtë mënyrë, kur krijojmë raporte (grafikë) për kontenierët që krijohen dinamikisht, ne pyetëm vetëm ato metrika që janë hasur në brendësi të dritares së caktuar dhe jo për të gjitha kohërat, çka e përshpejtoi ndjeshëm krijimin e raporteve për to. Për zgjidhjen e përshkruar më sipër është ndërtuar graphite-clickhouse (fork), duke përfshirë implementimin e punës me tabelën date_metrics.

Graphite+ClickHouse. Etiketat

Që nga versioni 1.1.0, Graphite zyrtarisht mbështet etiketat. Dhe ne po mendojmë aktivisht se çfarë dhe si duhet të bëjmë për të mbështetur këtë iniciativë në grumbullin graphite+clickhouse.

Graphite+ClickHouse. Detektori i anomalive

NĂ« bazĂ« tĂ« infrastrukturĂ«s sĂ« pĂ«rshkruar mĂ« lart, kemi realizuar njĂ« prototip tĂ« detektorĂ«t tĂ« anomalive dhe ai po funksionon! Por pĂ«r tĂ« — nĂ« artikullin tjetĂ«r.

Regjistrohuni, shtypni shenjën lart dhe jetëni të lumtur!

Burimi: habr.com

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster