Zdravo svima! U njegovom Pisao sam o organizovanju modularnog nadzornog sistema za mikroservisnu arhitekturu. Ništa ne miruje, naš projekat stalno raste, kao i broj pohranjenih metrika. Kako smo organizovali prelazak sa Graphite + Whisper na Graphite + ClickHouse pod uslovima visokog opterećenja, pročitajte o očekivanjima od njega i rezultatima migracije ispod reza.
Prije nego što vam ispričam kako smo organizirali prelazak sa pohranjivanja metrike u Graphite + Whisper na Graphite + ClickHouse, želio bih dati informacije o razlozima za donošenje takve odluke i o nedostacima Whispera sa kojima smo dugo živjeli.
Graphite+Whisper problemi
1. Visoko opterećenje diskovnog podsistema
U vrijeme tranzicije, otprilike 1.5 miliona metrika u minuti je letjelo do nas. Sa ovim tokom, iskorištenost diska na serverima je bila ~30%. Generalno, bilo je sasvim prihvatljivo – sve je radilo stabilno, brzo se pisalo, brzo čitalo... Sve dok jedan od razvojnih timova nije izbacio novu funkciju i počeo da nam šalje 10 miliona metrika u minuti. Tada se diskovni podsistem pooštrio i vidjeli smo 100% iskorištenost. Problem je brzo riješen, ali je talog ostao.
2. Nedostatak replikacije i konzistentnosti
Najvjerovatnije, kao i svi koji koriste / koriste Graphite + Whisper, prelili smo isti tok metrika na nekoliko Graphite servera odjednom kako bismo stvorili toleranciju na greške. I nije bilo posebnih problema s ovim - sve do trenutka kada jedan od servera iz nekog razloga nije pao. Ponekad smo uspeli da pokrenemo pali server dovoljno brzo, i carbon-c-relay je uspeo da ga napuni metrikom iz svog keša, a ponekad ne. A onda je nastala rupa u metrici, koju smo prekrili rsync-om. Procedura je bila prilično duga. Spasava samo činjenica da se to dešavalo veoma retko. Također smo povremeno uzimali nasumični skup metrika i upoređivali ih s drugim sličnim na susjednim čvorovima klastera. U oko 5% slučajeva se razlikovalo nekoliko vrijednosti, što nas nije baš usrećilo.
3. Velika količina zauzetog prostora
Budući da u Graphite pišemo ne samo infrastrukturne, već i poslovne metrike (a sada i metrike iz Kubernetesa), često dolazimo do situacije u kojoj postoji samo nekoliko vrijednosti u metrici, a .wsp datoteka se kreira uzimajući uzima u obzir cijeli period zadržavanja, i zauzima unaprijed dodijeljenu količinu prostora, koju smo imali ~ 2 MB. Problem se pogoršava činjenicom da postoji mnogo takvih fajlova tokom vremena, a kada se gradi izveštaj o njima, čitanje praznih tačaka oduzima mnogo vremena i resursa.
Želio bih odmah napomenuti da se gore opisani problemi mogu rješavati različitim metodama i s različitim stupnjevima efikasnosti, ali što više podataka počnete da primate, oni se više pogoršavaju.
Imajući sve navedeno (uzimajući u obzir prethodno ), kao i stalno povećanje broja primljenih metrika, želja da se sve metrike prenesu u interval skladištenja 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 , nakon što smo prošli kroz dokumentaciju i pronašli zdrave komponente za vezivanje ClickHouse pod Graphite, odlučili smo djelovati!
Želio bih dobiti sljedeće:
- smanjiti iskorištenost diskovnog podsistema sa 30% na 5%;
- smanjiti količinu zauzetog prostora sa 1TB na 100GB;
- biti u mogućnosti da primi 100 miliona metrika u minuti na server;
- replikacija podataka i tolerancija grešaka iz kutije;
- ne sjedite na ovom projektu godinu dana i napravite tranziciju za neko razumno razdoblje;
- prekidač bez zastoja.
Prilično ambiciozno, zar ne?
Graphite+ClickHouse. Komponente
Odabrao sam da primam podatke putem Graphite protokola, a zatim ih zapisujem u ClickHouse (golang).
Kao baza podataka za pohranjivanje vremenskih serija izabrano je posljednje ClickHouse izdanje stabilne verzije 1.1.54253. Prilikom rada s njim došlo je do problema: brdo grešaka se slilo u dnevnike i nije bilo sasvim jasno šta da se radi s njima. U razgovoru sa (autor carbon-clickhouse, graphite-clickhouse i još mnogo toga) odabran je stariji . Greške su nestale - sve je počelo raditi s praskom.
Za čitanje podataka iz ClickHouse je odabrano (golang). Kao API za Graphite − (golang). Za organiziranje replikacije između tablica korišten je ClickHouse . Za metriku rutiranja, ostavili smo našu voljenu (C) .
Graphite+ClickHouse. Struktura tabele
“grafit” je baza podataka koju smo kreirali za praćenje tabela.
“graphite.metrics” je tabela s ReplicatedReplacingMergeTree motorom (replicirano ). Ova tabela pohranjuje nazive metrika i putanje 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” je tabela sa ReplicatedGraphiteMergeTree motorom (replicirano ). Ova tabela 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 uslovno popunjena tabela sa ReplicatedReplacingMergeTree motorom. Ova tabela sadrži nazive svih metrika na koje smo naišli tokom dana. Razlozi za stvaranje opisani su u odjeljku 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” je uslovna tabela sa ReplicatedAggregatingMergeTree motorom (replicirano ). Ova tabela bilježi broj dolaznih metrika, razbijenih na 4 nivoa 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, PrefixGraphite+ClickHouse. Šema interakcije komponenti
Graphite+ClickHouse. Migracija podataka
Kao što se sjećamo iz očekivanja od ovog projekta, prelazak na ClickHouse trebao bi biti bez zastoja, odnosno, morali smo nekako prebaciti cijeli naš sistem praćenja na novo skladište što transparentnije za naše korisnike.
Uradili smo to na ovaj način.
-
U carbon-c-relay je dodano pravilo za slanje dodatnog toka metrike u carbon-clickhouse jednog od servera uključenih u replikaciju ClickHouse tabela.
-
Napisali smo malu python skriptu koja je, koristeći šapat biblioteku, pročitala sve .wsp datoteke iz našeg skladišta i poslala ove podatke u carbon-clickhouse opisanu gore u 24 niti. Broj prihvaćenih metričkih vrijednosti u carbon-clickhouseu dostigao je 125 miliona/min., a ClickHouse se nije ni oznojio.
-
Napravili smo poseban izvor podataka u Grafani kako bismo otklonili greške koje se koriste u postojećim nadzornim pločama. Otkrivena je lista funkcija koje smo koristili, ali nisu implementirane u carbonapi. Završili smo ove funkcije i poslali PR autorima carbonapija (posebno im hvala).
- Da bismo prebacili opterećenje čitanja u postavkama balansera, promijenili smo krajnje tačke iz graphite-api (API interfejs za Graphite+Whisper) u carbonapi.
Graphite+ClickHouse. rezultate
-
smanjeno korištenje diskovnog podsistema sa 30% na 1%;
- smanjena količina zauzetog prostora sa 1 TB na 300 GB;
- imamo mogućnost da primimo 125 miliona metrika u minuti po serveru (vrhunci u vrijeme migracije);
- preneo sve metrike u interval skladištenja od trideset sekundi;
- replikacija primljenih podataka i tolerancija grešaka;
- uključen bez zastoja;
- Za sve je trebalo oko 7 sedmica.
Graphite+ClickHouse. Problemi
U našem slučaju je bilo nekih zamki. Evo na šta smo se susreli nakon tranzicije.
- ClickHouse ne čita uvijek konfiguracije u hodu, ponekad ih treba ponovo učitati. Na primjer, u slučaju opisa klastera zookeeper u konfiguraciji ClickHouse, nije primijenjen sve dok se clickhouse-server nije ponovo pokrenuo.
- Nije bilo velikih ClickHouse zahtjeva, tako da u našem graphite-clickhouseu, ClickHouse niz veze izgleda ovako:
url = "http://localhost:8123/?max_query_size=268435456&max_ast_elements=1000000" - ClickHouse često objavljuje nove verzije stabilnih izdanja, mogu sadržavati iznenađenja: budite oprezni.
- Dinamički kreirani kontejneri u kubernetesu šalju veliki broj metrika sa kratkim i nasumičnim životnim vijekom. Prema ovakvim metrikama nema puno bodova, a ni s mjestom nema problema. Ali kada pravi upite, ClickHouse podiže ogroman broj istih metrika iz tabele 'metrika'. U 90% slučajeva za njih nema podataka izvan prozora (24 sata). Ali vrijeme potrošeno na traženje ovih podataka u tabeli 'podataka' je potrošeno i na kraju počiva na isteku vremena. Kako bismo riješili ovaj problem, počeli smo održavati poseban pogled sa informacijama o metrikama koje smo naišli tokom dana. Dakle, prilikom izrade izvještaja (grafova) za dinamički kreirane kontejnere, anketiramo samo one metrike na koje smo naišli unutar navedenog prozora, a ne za cijelo vrijeme, što je uvelike ubrzalo kreiranje izvještaja o njima. Za gore navedeno rješenje je prikupljeno , što uključuje implementaciju rada sa tabelom date_metrics.
Graphite+ClickHouse. oznake
Od verzije 1.1.0 Graphite je postao zvaničan . I mi aktivno razmišljamo o tome šta i kako učiniti da podržimo ovu inicijativu u grafit+clickhouse steku.
Graphite+ClickHouse. Detektor anomalija
Na osnovu gore opisane infrastrukture implementirali smo prototip detektora anomalija i on radi! Ali o njemu - u sljedećem članku.
Pretplatite se, pritisnite strelicu nagore i budite sretni!
izvor: www.habr.com