Kaixo guztioi! Berean azken artikulua Mikrozerbitzuen arkitektura baterako monitorizazio sistema modular bat antolatzeari buruz idatzi nuen. Ez dago ezer geldirik, gure proiektua etengabe hazten ari da, eta baita gordetako neurketa kopurua ere. Graphite + Whisper-etik Graphite + ClickHouserako trantsizioa nola antolatu genuen karga handiko baldintzetan, irakurri beraren itxaropenak eta ebakiaren azpiko migrazioaren emaitzak.

Grafito + Whisper-en neurketak gordetzetik Graphite + ClickHouserako trantsizioa nola antolatu genuen kontatu aurretik, horrelako erabakia hartzeko arrazoiei eta denbora luzez bizi izan genuen Whisper-en desabantailei buruzko informazioa eman nahiko nuke.

Grafitoa+Xxurla arazoak

1. Karga handia diskoaren azpisisteman

Trantsizio garaian, gutxi gorabehera, minutuko 1.5 milioi metrika joan ziren gurera. Fluxu honekin, zerbitzarietan diskoaren erabilera % 30ekoa izan zen. Oro har, nahiko onargarria zen: dena egonkor funtzionatzen zuen, azkar idatzi zen, azkar irakurri zen ... Garapen taldeetako batek funtzio berri bat zabaldu eta minutuko 10 milioi metrika bidaltzen hasi zen arte. Orduan disko azpisistema estutu zen, eta %100eko erabilera ikusi genuen. Arazoa azkar konpondu zen, baina sedimentua geratu zen.

2. Erreplikazio eta koherentzia falta

Seguruenik, Graphite + Whisper erabiltzen/erabiltzen duten guztiek bezala, metrika jario bera isuri genion grafito hainbat zerbitzaritara aldi berean akatsen tolerantzia sortzeko. Eta ez zen arazo berezirik izan honekin - zerbitzarietako bat arrazoiren batengatik erori ez zen unera arte. Batzuetan, eroritako zerbitzaria nahikoa azkar ekartzea lortzen genuen, eta carbon-c-relay-ek bere cacheko metrikaz betetzea lortu zuen, eta beste batzuetan ez. Eta gero zulo bat zegoen metriketan, rsync-ekin estali genuena. Prozedura nahiko luzea izan zen. Hau oso gutxitan gertatu izanagatik bakarrik salbatzen da. Aldian-aldian ausazko metrika-multzo bat ere hartu genuen eta klusterraren aldameneko nodoetan antzeko beste batzuekin alderatu genituen. Kasuen % 5 inguru, hainbat balio desberdinak ziren, eta horrek ez gintuen oso pozik egin.

3. Okupatutako leku handia

Graphite-n azpiegiturak ez ezik, negozioaren neurketak ere idazten ditugunez (eta orain Kubernetes-en neurketak ere), sarritan neurketan balio batzuk baino ez dauden egoera bat lortzen dugu eta .wsp fitxategia hartzen da. atxikipen-aldi osoa kontuan hartu, eta aurrez esleitutako espazio-kopuru bat hartzen du, ~ 2 MB genuen. Arazoa areagotu egiten da denboraren poderioz horrelako fitxategi asko egoteak, eta horien inguruko txostenak egitean, puntu hutsak irakurtzeak denbora eta baliabide asko eskatzen ditu.

Berehala adierazi nahi nuke goian deskribatutako arazoak hainbat metodorekin eta eraginkortasun maila ezberdinekin landu daitezkeela, baina zenbat eta datu gehiago jasotzen hasi, orduan eta larriagotu egiten dira.

Aurreko guztia edukita (aurrekoa kontuan hartuta Artikulua), baita jasotako metrika kopurua etengabe handitzea ere, metrika guztiak 30 segundoko biltegiratze tarte batera transferitzeko nahia. (10 segundo behar izanez gero), Graphite+ClickHouse probatzea erabaki genuen Whisper-en alternatiba itxaropentsu gisa.

Grafitoa+ClickHouse. itxaropenak

Yandex-eko mutilen hainbat topaketa bisitatu ondoren, irakurrita Habré-ri buruzko artikulu pare bat, dokumentazioa aztertu eta ClickHouse Grafitoaren azpian lotzeko osagai sanoak aurkitu ondoren, jardutea erabaki genuen!

Honako hauek lortu nahiko lituzke:

Disko azpisistemaren erabilera %30etik %5era murriztu;
okupatutako espazioa 1TBtik 100GBra murriztu;
zerbitzariari minutuko 100 milioi metrika jasotzeko gai izan;
datuen erreplikazioa eta akatsen tolerantzia kutxatik kanpo;
ez zaitez proiektu honetan eseri urtebetez eta egin trantsizioa aldi sano baterako;
etenaldirik gabe aldatu.

Nahiko anbiziotsua, ezta?

Grafitoa+ClickHouse. Osagaiak

Graphite protokoloaren bidez datuak jaso eta gero ClickHouse-n idazteko, aukeratu nuen karbono-clickhouse (golang).

1.1.54253 bertsio egonkorraren azken ClickHouse bertsioa aukeratu zen denbora serieak gordetzeko datu-base gisa. Berarekin lan egitean, arazoak egon ziren: akats mordoa isurtzen zen erregistroetan, eta ez zegoen guztiz argi haiekin zer egin. -rekin eztabaidan Roman Lomonosov (carbon-clickhouse, graphite-clickhouse eta askoz gehiagoren egilea) zaharragoa aukeratu zen 1.1.54236 oharra. Akatsak desagertu ziren - dena bang batekin hasi zen funtzionatzen.

ClickHouse-ko datuak irakurtzeko hautatu zen grafito-clickhouse (golang). Grafitorako API gisa − karbonapi (golang). Taulen arteko erreplikazioa antolatzeko, ClickHouse erabili zen zaintzailea. Bideratze-neurrietarako, gure maitea utzi dugu karbono-c-errele (C) (ikus aurreko artikulua).

Grafitoa+ClickHouse. Taularen egitura

"grafitoa" taulen jarraipena egiteko sortu dugun datu-base bat da.

"graphite.metrics" ReplicatedReplacingMergeTree motorra duen taula bat da (erreplikatua MergeTree ordezkatuz). Taula honek neurgailuen izenak eta haietarako bideak gordetzen ditu.

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” ReplicatedGraphiteMergeTree motorra duen taula bat da (erreplikatua GraphiteMergeTree). Taula honek balio metrikoak gordetzen ditu.

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" baldintzaz betetako taula bat da, ReplicatedReplacingMergeTree motorra duena. Taula honek egunean zehar aurkitu diren neurketa guztien izenak jasotzen ditu. Sorreraren arrazoiak atalean azaltzen dira "Arazoak" artikulu honen amaieran.

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” baldintzapeko taula bat da ReplicatedAggregatingMergeTree motorra (erreplikatua AgregatingMergeTree). Taula honek sarrerako metrika kopurua erregistratzen du, 4 habia-mailatan banatuta.

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

Grafitoa+ClickHouse. Osagaien elkarrekintzaren eskema

Grafitoa+ClickHouse. Datuen migrazioa

Proiektu honen itxaropenetatik gogoratzen dugunez, ClickHouserako trantsizioak geldialdirik gabe izan beharko luke, hurrenez hurren, gure monitorizazio sistema osoa biltegiratze berrira aldatu behar izan genuen nolabait gure erabiltzaileentzat ahalik eta gardenen.
Horrela egin genuen.

Carbon-c-relay-ri arau bat gehitu zitzaion ClickHouse taulen errepliketan parte hartzen duen zerbitzarietako baten karbono-clickhouse-ra metrika-jario gehigarri bat bidaltzeko.
Python script txiki bat idatzi genuen, whisper-dump liburutegia erabiliz, gure biltegitik .wsp fitxategi guztiak irakurri eta datu hauek goian deskribatutako carbon-clickhousera bidali zituen 24 haritan. Carbon-clickhouse-n onartutako balio metrikoen kopurua 125 milioi / min-ra iritsi zen, eta ClickHousek ez zuen izerdirik egin.
Datu-iturburu bereizi bat sortu dugu Grafanan lehendik dauden aginte-paneletan erabiltzen diren funtzioak arazteko. Erabili ditugun ezaugarrien zerrenda agertu da, baina ez ziren carbonapi-n inplementatu. Funtzio hauek amaitu, eta PRak bidali genizkien carbonapi-ren egileei (esker bereziak haiei).
Balantzailearen ezarpenetan irakurketa-karga aldatzeko, grafito-api-tik (API interfazea Graphite+Whisper) carbonapira aldatu ditugu.

Grafitoa+ClickHouse. emaitzak

disko azpisistemaren erabilera %30etik %1era murriztu zuen;
okupatutako espazioa 1 TBtik 300 GBra murriztu du;
zerbitzari bakoitzeko minutuko 125 milioi metrika jasotzeko gaitasuna dugu (gehienak migrazioaren unean);
neurketa guztiak hogeita hamar segundoko biltegiratze tarte batera transferitu ditu;
jasotako datuen errepikapena eta akatsen tolerantzia;
etenaldirik gabe aldatu;
7 aste inguru behar izan zituen denetarako.

Grafitoa+ClickHouse. Arazoak

Gure kasuan, tranpa batzuk zeuden. Hona hemen trantsizioaren ostean topatu genuena.

ClickHouse-k ez ditu beti konfigurazioak berriro irakurtzen hegan, batzuetan berriro kargatu behar da. Adibidez, ClickHouse konfigurazioan zookeeper klusterraren deskribapenaren kasuan, ez zen aplikatu clickhouse-zerbitzaria berrabiarazi arte.
Ez zegoen ClickHouse eskaera handirik, beraz, gure grafito-clickhouse-n, ClickHouse konexio-kateak itxura hau du:
```
url = "http://localhost:8123/?max_query_size=268435456&max_ast_elements=1000000"
```
ClickHouse-k sarritan kaleratzen ditu bertsio egonkorren bertsio berriak, sorpresak eduki ditzakete: kontuz.
Kubernetes-en dinamikoki sortutako edukiontziak neurketa ugari bidaltzen ditu bizitza labur eta ausazkoarekin. Ez dago puntu asko halako metrikaren arabera, eta lekuarekin ez dago arazorik. Baina kontsultak eraikitzean, ClickHouse-k metrika hauen kopuru handi bat planteatzen du "neurriak" taulatik. Kasuen %90ean, leihotik kanpo (24 ordu) ez dago horien daturik. Baina "datu" taulan datu horiek bilatzen emandako denbora igarotzen da, eta, azken batean, denbora-muga batean oinarritzen da. Arazo hau konpontzeko, egunean zehar aurkitutako neurketen inguruko ikuspegi bereizia mantentzen hasi ginen. Horrela, dinamikoki sortutako edukiontzietan txostenak (grafikoak) eraikitzean, zehaztutako leihoan aurkitu ziren neurketak soilik galdetzen ditugu, eta ez denbora osoan, eta horrek asko azkartu zuen horien inguruko txostenak sortzea. Goiko soluziorako bildu zen grafito-clickhouse (sardexka), data_metrics taularekin lan egiteko inplementazioa barne hartzen duena.

Grafitoa+ClickHouse. etiketak

1.1.0 bertsiotik Graphite ofizial bihurtu da laguntza etiketak. Eta aktiboki pentsatzen ari gara zer eta nola egin ekimen honi laguntzeko grafito+clickhouse pilan.

Grafitoa+ClickHouse. Anomalia detektagailua

Goian azaldutako azpiegituran oinarrituta, anomalien detektagailu prototipo bat ezarri dugu, eta funtzionatzen du! Baina berari buruz - hurrengo artikuluan.

Harpidetu, sakatu gorako gezia eta izan pozik!

Iturria: www.habr.com

Biltegiratze metrikoa: Graphite+Whisper-etik Graphite+ClickHouse-ra nola pasatu ginen