Tere kõigile! Oma Ma kirjutasin moodulmonitorimise süsteemi korraldamisest mikroteenuste arhitektuuris. Mitte miski ei seisa paigal, meie projekt kasvab pidevalt ning salvestatavate mõõdikute hulk suureneb samuti. Kuidas me korraldasime ülemineku Graphite+Whisperilt Graphite+ClickHouse'ile kõrgete koormuste tingimustes, ootuste ja migratsiooni tulemustega, loe allpool.
Enne kui räägin, kuidas korraldasime ülemineku mõõdikute hoidmisest Graphite+Whisperilt Graphite+ClickHouse'ile, tahaksin anda teavet selle otsuse põhjustest ja Whisperi puudustest, millega me pikka aega elasime.
Graphite+Whisperi probleemid
1. Suur koormus diskialusele
Ülemineku ajal jõudis meile umbes 1,5 miljonit mõõdikut minutis. Sellise voo korral oli serverite diskikäitus ~30%. Üldiselt oli see täiesti vastuvõetav – kõik töötas stabiilselt, kirjutamine ja lugemine olid kiired... Kuni hetkeni, mil üks arendusmeeskond ei käivitanud uut funktsiooni ning ei hakanud saatma meile 10 miljonit mõõdikut minutis. Siis sai diskialus tõeliselt koormatud ning nägime 100% käitust. Probleem suudeti kiiresti lahendada, kuid jätsime selle mälestuse.
2. Replikatsiooni ja järjepidevuse puudumine
Tõenäoliselt nagu kõik, kes kasutavad/kasutasid Graphite+Whisperit, saatsime me sama mõõdikute voogu mitmele Graphite serverile, et tagada tõrke talu. Sellega ei olnud erilisi probleeme – kuni hetkeni, mil üks server mingil põhjusel ei kukkunud. Mõnikord suutsime langetatud serveri piisavalt kiiresti uuesti ülesse saada ja carbon-c-relay jõudis oma vahemälust sinna mõõdikuid laadida, kuid mõnikord mitte. Siis oli mõõdikutel auk, mille me rsynciga kinni tõmbasime. Protseduur oli piisavalt pikaajaline. Ainus, mis meid päästis, oli see, et selline olukord juhtus väga harva. Samuti võtsime me perioodiliselt juhusliku mõõdikutega komplekti ja võrdlesime neid naapsete klastrinoodidega. Umbes 5% juhtudest oli mitmeid väärtusi erinevaid, mis meid ei rõõmustanud.
3. Suur mahukus
Kuna me kirjutame Graphite'sse mitte ainult infrastruktuuri, vaid ka ärimeetreid (ja nüüd ka Kubernetesest saadud mõõtmeid), siis satume üsna tihti olukorda, kus mõõtmes on vaid mõned väärtused, samas kui .wsp-faili luuakse kogu säilitustähtaja arvesse võttes, ja see nõuab meie eelmise mahtude kohta umbes 2 MB. Probleemi süvendab ka see, et sarnaste failide arv aja jooksul suureneb ja nende põhjal aruandeid koostades kulub palju aega ja ressursse tühjade punktide lugemisele.
Tahaksin kohe märkida, et eespool kirjeldatud probleemidega on võimalik erinevatel meetoditel ja erineva tõhususega võidelda, kuid mida rohkem andmeid teile hakkab laekuma, seda tugevamaks need probleemid muutuvad.
Olemasoleva info (arvesse võttes eelnevat ), samuti pidevalt kasvav mõõtmete hulk ja soov viia kõik mõõtmed 30-sekundilise säilitusaegade juurde (vajadusel kuni 10 sekundit), otsustasime proovida Graphite+ClickHouse'i kui perspektiivset alternatiivi Whisperile.
Graphite+ClickHouse. Ootused
Külastades mitmeid Yandexi kohtumisi, lugedes , uurides dokumentatsiooni ja leides mõistlikud komponendid ClickHouse'i Graphite'i ühendamiseks, otsustasime tegutseda!
Soovisime saavutada järgmist:
- vähendada kettaaluse kasutust 30%-lt 5%-le;
- vähendada mahtu 1 TB-lt 100 GB-le;
- omada võimalust vastu võtta 100 miljonit mõõdet minutis serverisse;
- andmete replikatsioon ja tõrkekindlus otse karbist;
- mitte veeta selle projekti kallal aastat ning teha üleminek mõistlikus ajavahemikus;
- ülalpidamatuse vältimine.
Piisavalt ambitsioonikas, eks?
Graphite+ClickHouse. Komponendid
Andmete saamiseks Graphite protokolli kaudu ja nende edasise salvestamise ClickHouse'is valiti (golang).
Ajareadude hoidmiseks valiti toona kõige uuem ClickHouse'i stabiilne versioon 1.1.54253. Töösel sellega tekkis probleeme: logides ilmus tohutul hulgal vigu ja ei olnud selge, mida nendega teha. Arutades (carbon-clickhouse, graphite-clickhouse ja veel palju-palju muud autor) valiti vanem Vead kadusid — kõik hakkas tööle suurepäraselt.
Andmete lugemiseks ClickHouse'ist valiti (golang). Graphite'i API-liidese jaoks — (golang). ClickHouse'i tabelite vahel replikatsiooni korraldamiseks kasutati . Meie armastatud meetrikate suunamiseks jätsime (C) .
Graphite+ClickHouse. Tabelite struktuur
„graphite” — andmebaas, mille me koostasime monitorimistabelite jaoks.
„graphite.metrics” — tabel, millel on ReplicatedReplacingMergeTree (replitseeritav ). Selles tabelis hoitakse meetrikate nimesid ja nende teid.
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” — tabel, millel on ReplicatedGraphiteMergeTree (replitseeritav ). Selles tabelis hoitakse meetrikate väärtusi.
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” — tabel, mida täidetakse tingimuste alusel, ReplicatedReplacingMergeTree mootoriga. Sellesse tabelisse kirjutatakse kõigi viimase päeva jooksul kokku puutunud meetrikate nimed. Loomise põhjused on kirjeldatud jaotises selle artikli lõpus.
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” — tabel, mida täidetakse tingimuste alusel, ReplicatedAggregatingMergeTree mootoriga (replitseeritav ). Sellesse tabelisse kirjutatakse sisenenud meetrikate arv, kusjuures see on jaotatud kuni 4 taseme sügavusele.
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. Komponentide vaheline suhtlus
Graphite+ClickHouse. Andmete migratsioon
Kuidas me mäletame selle projekti ootusi, peaks üleminek ClickHouse'ile toimuma ilma katkestusteta, seega pidime leidma viisi, kuidas kogu meie monitorimissüsteem sujuvalt uuele salvestusele üle viia, et meie kasutajad seda ei märkaks.
Teostasime seda nii.
carbon-c-relay'le lisasime reegli, et saata lisakanal meetrikatest carbon-clickhouse'i ühe serveri kaudu, mis osaleb ClickHouse tabelite replitseerimises.
Kirjutasime väikese skripti Pythonis, mis kasutas whisper-dump raamatukogu, et lugeda kõiki .wsp-faile meie hoidlast ja edastada need andmed eelpool nimetatud carbon-clickhouse'ile 24 lõngas. Sissetulevate mõõdikate arv carbon-clickhouse'is ulatus 125 mln/min ning ClickHouse ei märganud isegi pinget.
Loomasime Grafanas eraldi andmeallika, et siluda olemasolevates armatuurlaudades kasutatavaid funktsioone. Tuvastasime nimekirja funktsioonidest, mida kasutasime, kuid need polnud carbonapi-s rakendatud. Kirjutasime need funktsioonid juurde ja saatsime PR'id carbonapi autoritele (eriline tänu neile).
- Lugemiskoormuse ümbersuunamiseks muutsime koormuse tasakaalustajates lõpp-punkte graphite-api (Graphite+Whisperi API) carbonapi-ks.
Graphite+ClickHouse. Tulemused
vähendasime ketasüsteemi kasutust 30%lt 1%ni;
- vähendasime kogumahtu 1 TB-lt 300 GB-le;
- meil on võimalus vastu võtta 125 mln mõõdikate minutis serverisse (tipud migreerimise hetkel);
- üle viisime kõik mõõdikad kolmekümnesekundiliste säilitusaegadele;
- saime andmete replikatsiooni ja talitluse usaldusväärsuse;
- ülemineku korraldasime katkestusteta;
- kõigega kulus meil umbes 7 nädalat.
Graphite+ClickHouse. Probleemid
Kahjuks ei läinud meie puhul kõik valutult. Siin on, millega pärast üleminekut silmitsi seisisime.
- ClickHouse ei loe alati konfigureerimise faile reaalajas, mõnikord tuleb see taaskäivitada. Näiteks, klastrikirjeldust zookeeper’is ClickHouse konfiguraatoris ei rakendatud enne clickhouse-server’i taaskäivitamist.
- Suurte ClickHouse päringute läbimine ei õnnestunud, seetõttu näeb meie graphite-clickhouse ühenduse rea ClickHouse'iga välja nii:
url = "http://localhost:8123/?max_query_size=268435456&max_ast_elements=1000000" - ClickHouse'is ilmuvad suhteliselt tihti uued stabiilsed versioonid, need võivad tuua üllatusi: olge ettevaatlik.
- Dünaamiliselt loodud konteinerid kubernetes saadavad suurt hulka mõõdikuid lühikese ja juhusliku elueaga. Selliste mõõdikute punkte ei ole palju ja ruumi probleemidega pole. Kuid ClickHouse'i päringute koostamisel tõstetakse tohutult neid samu mõõdikuid tabelist ‘metrics’. 90% juhtudest puuduvad nende andmed akna (24 tunni) jooksul. Kuid nende andmete leidmiseks tabelis ‘data’ kulub aega ja lõpuks jõuab see ajaülesande piiranguni. Selle probleemi lahendamiseks hakkasime pidama eraldi vaadet, kus on teave mõõdikute kohta, mis ilmnesid ühe päeva jooksul. Seega, aruannete (graafikute) koostamisel dünaamiliselt loodud konteinerite kohta küsime ainult neid mõõdikuid, mis ilmnesid antud akna jooksul, mitte kogu aja jooksul, mis kiirendas nende aruannete koostamist mitu korda. Ülaltoodud lahenduse jaoks koostati , mis sisaldab teostust tabeliga date_metrics töötamiseks.
Graphite+ClickHouse. Märgistused
Alates versioonist 1.1.0 on Graphite ametlikult . Ja me mõtleme aktiivselt, mida ja kuidas teha, et seda algatust graphite+clickhouse tehnoloogias toetada.
Graphite+ClickHouse. Anomaaliate detektor
Ülaltoodud infrastruktuuri baasil oleme ellu viinud anomaaliate detektori prototüübi ja see töötab! Kuid sellest — järgmises artiklis.
Tellige, vajutage ülespoole ja olge õnnelikud!
Allikas: habr.com
