Shranjevanje metrik: kako smo prešli z Graphite+Whisper na Graphite+ClickHouse

Pozdravljeni vsi skupaj! V njegovem zadnji članek Pisal sem o organizaciji modularnega nadzornega sistema za arhitekturo mikrostoritev. Nič ne miruje, naš projekt nenehno raste, s tem pa tudi število shranjenih metrik. Kako smo organizirali prehod iz Graphite+Whisper na Graphite+ClickHouse pod visokimi obremenitvami, o pričakovanjih in rezultatih selitve preberite pod rezom.

Shranjevanje metrik: kako smo prešli z Graphite+Whisper na Graphite+ClickHouse

Preden vam povem, kako smo organizirali prehod s shranjevanja metrik v Graphite+Whisper na Graphite+ClickHouse, bi rad povedal o razlogih za takšno odločitev in o slabostih Whisperja, s katerim smo živeli dolgo časa.

Težave Graphite+Whisper

1. Velika obremenitev diskovnega podsistema

V času prehoda je k nam prihajalo približno 1.5 milijona metrik na minuto. Pri takem toku je bila izkoriščenost diska na strežnikih ~30 %. Na splošno je bilo to povsem sprejemljivo – vse je delovalo stabilno, se je hitro pisalo, hitro bralo ... Dokler ena od razvojnih ekip ni uvedla nove funkcije in nam začela pošiljati 10 milijonov metrik na minuto. Takrat se je diskovni podsistem zaostril in videli smo 100-odstotno izkoriščenost. Težava je bila hitro odpravljena, ostanek pa je ostal.

2. Pomanjkanje replikacije in doslednosti

Najverjetneje smo, tako kot vsi, ki uporabljajo/uporabljajo Graphite+Whisper, prelili isti tok meritev na več strežnikov Graphite hkrati, da bi ustvarili toleranco napak. In s tem ni bilo posebnih težav - do trenutka, ko se je eden od strežnikov iz nekega razloga zrušil. Včasih smo uspeli dovolj hitro pobrati okvarjeni strežnik in je carbon-c-relay uspel vanj naložiti metrike iz svojega predpomnilnika, včasih pa ne. In potem je bila v metriki luknja, ki smo jo zapolnili z rsync. Postopek je bil precej dolg. Edina rešitev je bila, da se je to zgodilo zelo redko. Občasno smo vzeli tudi naključni nabor metrik in jih primerjali z drugimi enakega tipa na sosednjih vozliščih gruče. V približno 5% primerov je bilo več vrednosti različnih, s čimer nismo bili preveč zadovoljni.

3. Velik odtis

Ker v Graphite ne pišemo samo infrastrukturo, ampak tudi poslovne metrike (in zdaj tudi metrike iz Kubernetesa), se nemalokrat zgodi, da metrika vsebuje le nekaj vrednosti, datoteka .wsp pa je ustvarjena ob upoštevanju vseh zadržkov obdobje in zavzame vnaprej dodeljeno količino prostora, ki je za nas znašala ~2 MB. Težavo dodatno otežuje dejstvo, da se sčasoma pojavi veliko podobnih datotek, pri gradnji poročil na njih pa branje praznih točk vzame veliko časa in sredstev.

Želel bi takoj opozoriti, da je zgoraj opisane težave mogoče rešiti z različnimi metodami in z različnimi stopnjami učinkovitosti, vendar več podatkov, ki jih začnete prejemati, bolj se poslabšajo.

Ob vsem navedenem (ob upoštevanju prejšnjega Člen), pa tudi stalno povečevanje števila prejetih meritev, želja po prenosu vseh meritev v interval shranjevanja 30 sekund. (do 10 sekund, če je potrebno), smo se odločili, da preizkusimo Graphite+ClickHouse kot obetavno alternativo Whisperju.

Graphite+ClickHouse. Pričakovanja

Ko sem obiskal več srečanj fantov iz Yandexa, prebral nekaj člankov na Habréju, ko smo pregledali dokumentacijo in našli zdrave komponente za vezavo ClickHouse pod Graphite, smo se odločili ukrepati!

Želim prejeti naslednje:

  • zmanjšajte izkoriščenost diskovnega podsistema s 30 % na 5 %;
  • zmanjšajte količino zasedenega prostora z 1TB na 100GB;
  • biti sposoben prejeti 100 milijonov meritev na minuto v strežnik;
  • podvajanje podatkov in toleranca napak takoj po namestitvi;
  • ne sedite na tem projektu eno leto in naredite prehod v razumnem časovnem okviru;
  • preklopite brez izpadov.

Precej ambiciozno, kajne?

Graphite+ClickHouse. Komponente

Za prejemanje podatkov preko Graphite protokola in naknadno beleženje v ClickHouse sem izbral ogljik (golang).

Za bazo podatkov za shranjevanje časovnih vrst je bila izbrana zadnja izdaja ClickHouse, stabilna različica 1.1.54253. Pri delu z njim so bile težave: v dnevnike se je vlila gora napak in ni bilo povsem jasno, kaj storiti z njimi. V razpravi z Roman Lomonosov (avtor carbon-clickhouse, graphite-clickhouse in mnogih, mnogih drugih) je bil izbran starejši izdaja 1.1.54236. Napake so izginile - vse je začelo delovati s pokom.

Izbrano za branje podatkov iz ClickHouse grafitna tovarna (golang). Kot API za Graphite − karbonapi (golang). ClickHouse je bil uporabljen za organizacijo replikacije med tabelami oskrbnik živalskega vrta. Za metriko usmerjanja smo pustili našega ljubljenega ogljikov-c-rele (C) (glej prejšnji članek).

Graphite+ClickHouse. Struktura tabele

“graphite” je zbirka podatkov, ki smo jo ustvarili za spremljanje tabel.

“graphite.metrics” - tabela z mehanizmom ReplicatedReplacingMergeTree (podvojeno Zamenjava MergeTree). V tej tabeli so shranjena imena metrik in poti do njih.

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 z motorjem ReplicatedGraphiteMergeTree (podvojeno GraphiteMergeTree). V tej tabeli so shranjene metrične vrednosti.

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« je pogojno izpolnjena tabela z mehanizmom ReplicatedReplacingMergeTree. V tej tabeli so zapisana imena vseh meritev, ki so se pojavile čez dan. Razlogi za nastanek so opisani v poglavju "Težave" na koncu tega članka.

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” – tabela, izpolnjena s pogojem, z mehanizmom ReplicatedAggregatingMergeTree (podvojeno AggregatingMergeTree). Ta tabela beleži število dohodnih meritev, razčlenjeno na 4 ravni gnezdenja.

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. Diagram interakcije komponent

Shranjevanje metrik: kako smo prešli z Graphite+Whisper na Graphite+ClickHouse

Graphite+ClickHouse. Migracija podatkov

Kot se spominjamo pričakovanj od tega projekta, bi moral prehod na ClickHouse potekati brez izpadov, zato smo morali nekako preklopiti naš celoten nadzorni sistem na novo skladišče čim bolj pregledno za naše uporabnike.
Tako smo naredili.

  • V carbon-c-relay je bilo dodano pravilo za pošiljanje dodatnega toka meritev v carbon-clickhouse enega od strežnikov, ki sodelujejo pri replikaciji tabel ClickHouse.

  • Napisali smo majhen skript v pythonu, ki je z uporabo knjižnice whisper-dump prebral vse datoteke .wsp iz našega pomnilnika in poslal te podatke v zgoraj opisano hišo za klikanje ogljika v 24 nitih. Število sprejetih metričnih vrednosti v carbon-clickhouseu je doseglo 125 milijonov/min, ClickHouse pa se ni niti malo oznojil.

  • Ustvarili smo ločen DataSource v Grafani za odpravljanje napak v funkcijah, ki se uporabljajo v obstoječih nadzornih ploščah. Identificirali smo seznam funkcij, ki smo jih uporabili, vendar niso bile implementirane v carbonapi. Te funkcije smo dodali in avtorjem carbonapija poslali PR (posebna hvala).

  • Za preklop obremenitve branja v nastavitvah izravnalnika smo spremenili končne točke iz graphite-api (vmesnik API za Graphite+Whisper) v carbonapi.

Graphite+ClickHouse. rezultate

  • zmanjšana izkoriščenost diskovnega podsistema s 30 % na 1 %;

    Shranjevanje metrik: kako smo prešli z Graphite+Whisper na Graphite+ClickHouse

  • zmanjšal količino zasedenega prostora z 1 TB na 300 GB;
  • imamo možnost sprejema 125 milijonov metrik na minuto v strežnik (vrh v času selitve);
  • prenese vse metrike v tridesetsekundni interval shranjevanja;
  • podvajanje prejetih podatkov in toleranca napak;
  • preklopljen brez izpadov;
  • Za dokončanje vsega je trajalo približno 7 tednov.

Graphite+ClickHouse. Težave

V našem primeru je bilo nekaj pasti. To je tisto, s čimer smo se srečali po prehodu.

  1. ClickHouse konfiguracij ne prebere vedno sproti; včasih ga je treba znova zagnati. Na primer, v primeru opisa gruče zookeeper v konfiguraciji ClickHouse ni bil uporabljen, dokler ni bil znova zagnan strežnik clickhouse.
  2. Velike zahteve ClickHouse niso šle skozi, zato je v graphite-clickhouse naš povezovalni niz ClickHouse videti takole:
    url = "http://localhost:8123/?max_query_size=268435456&max_ast_elements=1000000"
  3. ClickHouse pogosto izda nove različice stabilnih izdaj, ki lahko vsebujejo presenečenja: bodite previdni.
  4. Dinamično ustvarjeni vsebniki v kubernete pošiljajo veliko število metrik s kratko in naključno življenjsko dobo. Za takšno metriko ni veliko točk, s prostorom pa ni težav. Toda pri ustvarjanju poizvedb ClickHouse pobere ogromno teh istih meritev iz tabele »metrike«. V 90% primerov ni podatkov o njih onstran okna (24 ur). Toda čas se porabi za iskanje teh podatkov v tabeli 'podatki' in na koncu naleti na časovno omejitev. Da bi rešili to težavo, smo začeli vzdrževati ločen pogled z informacijami o meritvah, na katere smo naleteli čez dan. Tako pri izdelavi poročil (grafov) za dinamično ustvarjene vsebnike poizvedujemo samo po tistih metrikah, ki smo jih srečali znotraj danega okna, in ne za ves čas, kar je bistveno pohitrilo izgradnjo poročil na njih. Za zgoraj opisano rešitev sem zbral graphite-clickhouse (vilice), ki vključuje implementacijo dela s tabelo date_metrics.

Graphite+ClickHouse. Oznake

Z različico 1.1.0 je Graphite postal uraden podporne oznake. In aktivno razmišljamo o tem, kaj in kako narediti, da podpremo to pobudo v skladu graphite+clickhouse.

Graphite+ClickHouse. Detektor anomalij

Na podlagi zgoraj opisane infrastrukture smo implementirali prototip detektorja nepravilnosti in deluje! A več o njem v naslednjem članku.

Naročite se, pritisnite puščico navzgor in bodite srečni!

Vir: www.habr.com

Dodaj komentar