Pohrana metrike: kako smo se prebacili s Graphite+Whisper na Graphite+ClickHouse

Bok svima! U njegovom zadnji članak Pisao sam o organiziranju modularnog sustava nadzora za arhitekturu mikroservisa. Ništa ne stoji, naš projekt stalno raste, a samim time i broj pohranjenih metrika. Kako smo organizirali prijelaz s Graphite+Whisper na Graphite+ClickHouse pod uvjetima visokog opterećenja, pročitajte o očekivanjima od njega i rezultatima migracije ispod rezanja.

Pohrana metrike: kako smo se prebacili s Graphite+Whisper na Graphite+ClickHouse

Prije nego što vam ispričam kako smo organizirali prijelaz s pohranjivanja metrika u Graphite+Whisper na Graphite+ClickHouse, želio bih vam dati informacije o razlozima takve odluke te o nedostacima Whispera s kojim smo dugo živjeli.

Graphite+Whisper problemi

1. Veliko opterećenje diskovnog podsustava

U vrijeme prijelaza stizalo nam je približno 1.5 milijuna metrika u minuti. Uz takav protok, iskorištenost diska na poslužiteljima bila je ~30%. Općenito, to je bilo sasvim prihvatljivo - sve je radilo stabilno, brzo se pisalo, brzo čitalo... Sve dok jedan od razvojnih timova nije izbacio novu značajku i počeo nam slati 10 milijuna metrika u minuti. Tada se diskovni podsustav zategao i vidjeli smo 100% iskorištenost. Problem je brzo riješen, ali je ostao talog.

2. Nedostatak replikacije i dosljednosti

Najvjerojatnije smo, kao i svi koji koriste/koristili Graphite+Whisper, prelili isti tok metrike na nekoliko Graphite poslužitelja odjednom kako bismo stvorili toleranciju na greške. I s tim nije bilo posebnih problema - sve do trenutka kada se jedan od poslužitelja iz nekog razloga srušio. Ponekad smo uspjeli pokupiti pokvareni poslužitelj dovoljno brzo, a carbon-c-relay je uspio učitati metriku iz svoje predmemorije u njega, ali ponekad ne. A onda se pojavila rupa u metrici koju smo popunili pomoću rsync. Procedura je bila dosta duga. Jedini spas je bio taj što se to događalo vrlo rijetko. Također smo povremeno uzimali nasumični skup metrika i uspoređivali ih s drugima iste vrste na susjednim čvorovima klastera. U oko 5% slučajeva nekoliko se vrijednosti razlikovalo, što nam baš i nije bilo drago.

3. Velik otisak

Budući da u Graphite upisujemo ne samo infrastrukturne, već i poslovne metrike (a sada i metrike iz Kubernetesa), vrlo često imamo situaciju u kojoj metrika sadrži samo nekoliko vrijednosti, a .wsp datoteka je kreirana uzimajući u obzir sva zadržavanja period, i zauzima unaprijed dodijeljenu količinu prostora, koja je za nas bila ~2 MB. Problem je dodatno pogoršan činjenicom da se s vremenom pojavljuje puno sličnih datoteka, a prilikom izrade izvješća na njima čitanje praznih točaka oduzima puno vremena i resursa.

Želio bih odmah napomenuti da se gore opisani problemi mogu riješiti različitim metodama i s različitim stupnjevima učinkovitosti, ali što više podataka počnete primati, to se oni više pogoršavaju.

Imajući sve navedeno (uzimajući u obzir prethodno Članak), kao i konstantno povećanje broja primljenih metrika, želja za prijenosom svih metrika na interval pohrane od 30 sekundi. (do 10 sekundi ako je potrebno), odlučili smo isprobati Graphite+ClickHouse kao obećavajuću alternativu Whisperu.

Graphite+ClickHouse. Očekivanja

Posjetivši nekoliko susreta momaka iz Yandexa, pročitavši par članaka na Habréu, nakon što smo pregledali dokumentaciju i pronašli zdrave komponente za uvezivanje ClickHousea pod Graphite, odlučili smo nešto poduzeti!

Želim primiti sljedeće:

  • smanjiti iskorištenost diskovnog podsustava s 30% na 5%;
  • smanjiti količinu zauzetog prostora s 1TB na 100GB;
  • moći primiti 100 milijuna metrika u minuti na poslužitelj;
  • replikacija podataka i tolerancija grešaka izvan okvira;
  • nemojte sjediti na ovom projektu godinu dana i napravite prijelaz u razumnom roku;
  • prebacivanje bez zastoja.

Prilično ambiciozno, zar ne?

Graphite+ClickHouse. Komponente

Odabrao sam primati podatke putem Graphite protokola i naknadno ih snimati u ClickHouse carbon-clickhouse (golang).

Kao baza podataka za pohranjivanje vremenskih serija odabrano je posljednje izdanje ClickHousea, stabilna verzija 1.1.54253. Bilo je problema pri radu s njim: brdo pogrešaka ulilo se u zapisnike i nije bilo sasvim jasno što s njima učiniti. U razgovoru sa Roman Lomonosov (autor carbon-clickhouse, graphite-clickhouse i još mnogo, mnogo više) izabran je stariji izdanje 1.1.54236. Pogreške su nestale - sve je počelo raditi s praskom.

Odabrano za čitanje podataka iz ClickHouse grafitna tvornica (golang). Kao API za Graphite − karbonapi (golang). ClickHouse je korišten za organiziranje replikacije između tablica čuvar zoo vrta. Za metriku usmjeravanja ostavili smo našeg voljenog ugljik-c-relej (C) (vidi prethodni članak).

Graphite+ClickHouse. Struktura tablice

“graphite” je baza koju smo kreirali za praćenje tablica.

“graphite.metrics” - tablica s motorom ReplicatedReplacingMergeTree (replicirano Zamjena MergeTree). Ova tablica pohranjuje nazive metrika i putove 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” - tablica s motorom ReplicatedGraphiteMergeTree (replicirano GraphiteMergeTree). Ova tablica pohranjuje metričke vrijednosti.

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 uvjetno ispunjena tablica s ReplicatedReplacingMergeTree motorom. Ova tablica bilježi nazive svih metrika na koje smo naišli tijekom dana. Razlozi njegovog nastanka opisani su u odjeljku "Problemi" na kraju ovog č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” - tablica ispunjena prema uvjetima, s ReplicatedAggregatingMergeTree motorom (replicirano AggregatingMergeTree). Ova tablica bilježi broj dolaznih metrika, podijeljenih na 4 razine ugniježđenja.

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. Dijagram interakcije komponenti

Pohrana metrike: kako smo se prebacili s Graphite+Whisper na Graphite+ClickHouse

Graphite+ClickHouse. Migracija podataka

Kao što se sjećamo iz očekivanja od ovog projekta, tranzicija na ClickHouse trebala bi biti bez zastoja, stoga smo morali nekako prebaciti naš cijeli sustav nadzora na novu pohranu što transparentnije za naše korisnike.
Ovako smo to napravili.

  • Pravilo je dodano u carbon-c-relay za slanje dodatnog toka metrike u carbon-clickhouse jednog od poslužitelja koji sudjeluju u replikaciji ClickHouse tablica.

  • Napisali smo malu skriptu u pythonu, koja je, koristeći biblioteku šapata-dumpa, čitala sve .wsp datoteke iz naše pohrane i slala te podatke u gore opisanu ugljičnu kuću za klikanje u 24 niti. Broj prihvaćenih metričkih vrijednosti u carbon-clickhouseu dosegao je 125 milijuna/min, a ClickHouse se nije ni oznojio.

  • Napravili smo zaseban DataSource u Grafani za otklanjanje pogrešaka u funkcijama koje se koriste u postojećim nadzornim pločama. Identificirali smo popis funkcija koje smo koristili, ali one nisu implementirane u carbonapi. Dodali smo ove funkcije i poslali PR-ove autorima carbonapija (njih posebno zahvaljujemo).

  • Kako bismo prebacili opterećenje čitanja u postavkama balansera, promijenili smo krajnje točke iz graphite-api (API sučelje za Graphite+Whisper) u carbonapi.

Graphite+ClickHouse. rezultate

  • smanjeno iskorištenje diskovnog podsustava s 30% na 1%;

    Pohrana metrike: kako smo se prebacili s Graphite+Whisper na Graphite+ClickHouse

  • smanjena količina zauzetog prostora s 1 TB na 300 GB;
  • imamo mogućnost primanja 125 milijuna metrika u minuti na poslužitelj (vrhunci u vrijeme migracije);
  • prebacio sve metrike na interval pohranjivanja od trideset sekundi;
  • replikacija primljenih podataka i tolerancija na pogreške;
  • prebacio bez zastoja;
  • Bilo je potrebno oko 7 tjedana da se sve završi.

Graphite+ClickHouse. Problemi

U našem slučaju bilo je zamki. To je ono s čim smo se susreli nakon tranzicije.

  1. ClickHouse ne čita uvijek konfiguracije u hodu; ponekad ga je potrebno ponovno pokrenuti. Na primjer, u slučaju opisa klastera zookeeper u konfiguraciji ClickHouse, on nije korišten sve dok se clickhouse-poslužitelj nije ponovno pokrenuo.
  2. Veliki ClickHouse zahtjevi nisu prošli, tako da u graphite-clickhouseu naš niz za povezivanje ClickHousea izgleda ovako:
    url = "http://localhost:8123/?max_query_size=268435456&max_ast_elements=1000000"
  3. ClickHouse prilično često izdaje nove verzije stabilnih izdanja; ona mogu sadržavati iznenađenja: budite oprezni.
  4. Dinamički stvoreni spremnici u kubernetesu šalju veliki broj metrika s kratkim i nasumičnim vijekom trajanja. Za takvu metriku nema puno bodova, a nema problema ni s prostorom. Ali prilikom izrade upita, ClickHouse preuzima veliki broj tih istih metrika iz tablice "metrika". U 90% slučajeva o njima nema podataka nakon prozora (24 sata). Ali vrijeme se troši na traženje ovih podataka u tablici 'podataka' i na kraju dolazi do vremenskog ograničenja. Kako bismo riješili ovaj problem, počeli smo održavati zaseban prikaz s informacijama o metrikama na koje smo naišli tijekom dana. Dakle, prilikom izrade izvještaja (grafova) za dinamički kreirane spremnike, ispitujemo samo one metrike koje smo naišli unutar zadanog prozora, a ne za cijelo vrijeme, što je znatno ubrzalo izradu izvještaja na njima. Za gore opisano rješenje prikupio sam grafitna klizna kućica (vilica), što uključuje implementaciju rada s tablicom date_metrics.

Graphite+ClickHouse. Oznake

S verzijom 1.1.0 Graphite je postao službeni oznake podrške. I aktivno razmišljamo o tome što i kako učiniti da podržimo ovu inicijativu u stacku graphite+clickhouse.

Graphite+ClickHouse. Detektor anomalija

Na temelju gore opisane infrastrukture implementirali smo prototip detektora anomalija i on radi! No, više o njemu u sljedećem članku.

Pretplatite se, pritisnite strelicu gore i budite sretni!

Izvor: www.habr.com

Dodajte komentar