Hi almal! In sy laaste artikel Ek het geskryf oor die organisering van 'n modulêre moniteringstelsel vir 'n mikrodiensargitektuur. Niks staan stil nie, ons projek groei voortdurend, en so ook die aantal gestoorde metrieke. Hoe ons die oorgang van Graphite + Whisper na Graphite + ClickHouse onder hoë lastoestande georganiseer het, lees oor die verwagtinge daarvan en die resultate van die migrasie onder die sny.

Voordat ek jou vertel hoe ons die oorgang van die stoor van statistieke in Graphite + Whisper na Graphite + ClickHouse georganiseer het, wil ek graag inligting gee oor die redes vir die neem van so 'n besluit en oor die nadele van Whisper waarmee ons lank geleef het.

Grafiet+fluisterprobleme

1. Hoë las op die skyfsubstelsel

Ten tyde van die oorgang het ongeveer 1.5 miljoen metrieke per minuut na ons gevlieg. Met hierdie vloei was skyfbenutting op die bedieners ~30%. Oor die algemeen was dit heel aanvaarbaar - alles het stabiel gewerk, is vinnig geskryf, vinnig gelees ... Tot een van die ontwikkelingspanne 'n nuwe kenmerk uitgerol het en vir ons 10 miljoen statistieke per minuut begin stuur het. Dit was toe dat die skyfsubstelsel strenger geword het, en ons het 100% benutting gesien. Die probleem is vinnig opgelos, maar die sediment het gebly.

2. Gebrek aan replikasie en konsekwentheid

Heel waarskynlik, soos almal wat Graphite + Whisper gebruik / gebruik, het ons dieselfde stroom metrieke gelyktydig na verskeie Graphite-bedieners gegooi om fouttoleransie te skep. En daar was geen spesiale probleme hiermee nie - tot die oomblik toe een van die bedieners om een of ander rede nie geval het nie. Soms het ons daarin geslaag om die gevalle bediener vinnig genoeg op te roep, en koolstof-c-relay het daarin geslaag om dit met statistieke uit sy kas te vul, en soms nie. En dan was daar 'n gat in die metrieke, wat ons met rsync bedek het. Die prosedure was redelik lank. Slegs gered deur die feit dat dit baie selde gebeur het. Ons het ook van tyd tot tyd 'n ewekansige stel metrieke geneem en dit vergelyk met ander soortgelykes op naburige nodusse van die groepering. In ongeveer 5% van die gevalle het verskeie waardes verskil, wat ons nie baie gelukkig gemaak het nie.

3. Groot hoeveelheid spasie beset

Aangesien ons nie net infrastruktuur in Graphite skryf nie, maar ook besigheidsstatistieke (en nou ook metrieke van Kubernetes), kry ons dikwels 'n situasie waarin daar net 'n paar waardes in die metriek is, en die .wsp-lêer word geskep met die hele retensietydperk in ag neem, en neem 'n vooraf-toegewysde hoeveelheid spasie in beslag, wat ons ~ 2 MB gehad het. Die probleem word vererger deur die feit dat daar mettertyd baie sulke lêers is, en wanneer verslae daaroor gebou word, neem die lees van leë punte baie tyd en hulpbronne.

Ek wil dadelik daarop let dat die probleme wat hierbo beskryf word deur verskeie metodes en met verskillende grade van doeltreffendheid hanteer kan word, maar hoe meer data jy begin ontvang, hoe meer word dit vererger.

Met al die bogenoemde (met inagneming van die vorige Artikel), sowel as 'n konstante toename in die aantal ontvangde statistieke, die begeerte om alle statistieke oor te dra na 'n stoorinterval van 30 sekondes. (tot 10 sekondes indien nodig), het ons besluit om Graphite+ClickHouse te probeer as 'n belowende alternatief vir Whisper.

Graphite+ClickHouse. verwagtinge

Nadat ek verskeie ontmoetings van die ouens van Yandex besoek het, gelees het 'n paar artikels oor HabréNadat ons deur die dokumentasie gegaan het en gesonde komponente gevind het om ClickHouse onder Graphite te bind, het ons besluit om op te tree!

Wil graag die volgende kry:

verminder skyfsubstelselbenutting van 30% tot 5%;
verminder die hoeveelheid spasie wat beset word van 1TB tot 100GB;
in staat wees om 100 miljoen metrieke per minuut na die bediener te ontvang;
data replikasie en fouttoleransie uit die boks;
moenie vir 'n jaar op hierdie projek sit en die oorgang maak vir 'n gesonde tydperk nie;
skakel sonder stilstand.

Redelik ambisieus, reg?

Graphite+ClickHouse. Komponente

Om data via die Graphite-protokol te ontvang en dit dan aan ClickHouse te skryf, het ek gekies koolstof-klikhuis (golang).

Die laaste ClickHouse-vrystelling van die stabiele weergawe 1.1.54253 is gekies as die databasis vir die stoor van tydreekse. Toe daar daarmee gewerk word, was daar probleme: 'n berg foute het in die stompe gestroom, en dit was nie heeltemal duidelik wat om daarmee te doen nie. In gesprek met Roman Lomonosov (skrywer van carbon-clickhouse, graphite-clickhouse en vele meer) die ouer een is gekies vrystelling 1.1.54236. Foute het verdwyn - alles het met 'n knal begin werk.

Om data van ClickHouse te lees is gekies grafiet-klikhuis (golang). As 'n API vir grafiet - karbonapie (golang). Om replikasie tussen tabelle te organiseer, is ClickHouse gebruik dieretuinopsigter. Vir roetebepalings het ons ons geliefde verlaat koolstof-c-aflos (C) (sien vorige artikel).

Graphite+ClickHouse. Tafelstruktuur

"grafiet" is 'n databasis wat ons geskep het vir die monitering van tabelle.

"graphite.metrics" is 'n tabel met die ReplicatedReplacingMergeTree-enjin (gerepliseer VervangMergeTree). Hierdie tabel stoor die name van die metrieke en die paaie na hulle.

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" is 'n tabel met die ReplicatedGraphiteMergeTree-enjin (gerepliseer GraphiteMergeTree). Hierdie tabel stoor metrieke waardes.

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" is 'n voorwaardelik gevulde tabel met die ReplicatedReplacingMergeTree-enjin. Hierdie tabel bevat die name van al die maatstawwe wat gedurende die dag teëgekom is. Die redes vir die skepping word in die afdeling beskryf "Probleme" aan die einde van hierdie 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" is 'n voorwaardelike tabel met die ReplicatedAggregatingMergeTree-enjin (gerepliseer AggregatingMergeTree). Hierdie tabel teken die aantal inkomende maatstawwe aan, afgebreek na 4 vlakke van nes.

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. Skema van interaksie van komponente

Graphite+ClickHouse. Datamigrasie

Soos ons onthou uit die verwagtinge van hierdie projek, die oorgang na ClickHouse behoort onderskeidelik sonder stilstand te wees, ons moes op een of ander manier ons hele moniteringstelsel oorskakel na die nuwe berging so deursigtig as moontlik vir ons gebruikers.
Ons het dit op hierdie manier gedoen.

'n Reël is by koolstof-c-relay gevoeg om 'n bykomende stroom metrieke na die koolstof-klikhuis van een van die bedieners wat betrokke is by die replikasie van ClickHouse-tabelle te stuur.
Ons het 'n klein luislangskrif geskryf wat, met behulp van die fluisterstorting-biblioteek, al die .wsp-lêers van ons berging gelees het en hierdie data na die koolstof-klikhuis wat hierbo beskryf is in 24 drade gestuur het. Die aantal aanvaarde metrieke waardes in koolstof-klikhuis het 125 miljoen / min bereik, en ClickHouse het nie eens gesweet nie.
Ons het 'n aparte DataSource in Grafana geskep om die funksies wat in bestaande kontroleskerms gebruik word, te ontfout. Onthul 'n lys van kenmerke wat ons gebruik het, maar hulle is nie in carbonapi geïmplementeer nie. Ons het hierdie funksies voltooi en PR's aan die skrywers van carbonapi gestuur (spesiale dank aan hulle).
Om die leeslading in die balanseerder-instellings te verander, het ons eindpunte van grafiet-api (API-koppelvlak vir Graphite+Whisper) na carbonapi verander.

Graphite+ClickHouse. resultate

verminder die gebruik van die skyfsubstelsel van 30% tot 1%;
verminder die hoeveelheid ruimte wat beset word van 1 TB tot 300 GB;
ons het die vermoë om 125 miljoen statistieke per minuut per bediener te ontvang (pieke ten tye van migrasie);
alle maatstawwe oorgedra na 'n dertig-sekonde bergingsinterval;
ontvang data replikasie en fouttoleransie;
oorgeskakel sonder stilstand;
Dit het omtrent 7 weke geneem vir alles.

Graphite+ClickHouse. Probleme

In ons geval was daar 'n paar slaggate. Hier is wat ons na die oorgang teëgekom het.

ClickHouse herlees nie altyd konfigurasies dadelik nie, soms moet dit herlaai word. Byvoorbeeld, in die geval van die beskrywing van die dieretuinwagter-groepering in die ClickHouse-opstelling, is dit nie toegepas totdat die clickhouse-bediener herbegin is nie.
Daar was geen groot ClickHouse-versoeke nie, so in ons grafiet-klikhuis lyk die ClickHouse-verbindingstring so:
```
url = "http://localhost:8123/?max_query_size=268435456&max_ast_elements=1000000"
```
ClickHouse stel gereeld nuwe weergawes van stabiele vrystellings vry, dit kan verrassings bevat: wees versigtig.
Dinamies geskep houers in kubernetes stuur 'n groot aantal statistieke met 'n kort en ewekansige leeftyd. Daar is nie baie punte volgens sulke maatstawwe nie, en daar is geen probleme met die plek nie. Maar wanneer navrae gebou word, bring ClickHouse 'n groot aantal van dieselfde statistieke uit die 'metrieke'-tabel. In 90% van die gevalle is daar geen data vir hulle buite die venster nie (24 uur). Maar die tyd wat spandeer word om na hierdie data in die 'data'-tabel te soek, word spandeer, en berus uiteindelik op 'n uitteltyd. Om hierdie probleem op te los, het ons 'n aparte aansig begin handhaaf met inligting oor die maatstawwe wat gedurende die dag teëgekom is. Dus, wanneer ons verslae (grafieke) op dinamies geskepte houers bou, ondersoek ons slegs daardie maatstawwe wat binne die gespesifiseerde venster teëgekom is, en nie vir die hele tyd nie, wat die generering van verslae daaroor aansienlik versnel het. Vir die bogenoemde oplossing is versamel grafiet-klikhuis (vurk), wat die implementering van werk met die date_metrics-tabel insluit.

Graphite+ClickHouse. etikette

Sedert weergawe 1.1.0 het Graphite amptelik geword ondersteuning tags. En ons dink aktief na oor wat en hoe om te doen om hierdie inisiatief in die grafiet+klikhuisstapel te ondersteun.

Graphite+ClickHouse. Anomalie detektor

Gebaseer op die infrastruktuur hierbo beskryf, het ons 'n prototipe anomalie detector geïmplementeer, en dit werk! Maar oor hom - in die volgende artikel.

Teken in, druk die op-pyltjie en wees gelukkig!

Bron: will.com

Metrieke berging: hoe ons van Graphite+Whisper na Graphite+ClickHouse beweeg het