Tere, kõigile! Oma eelmisel artiklil olen kirjutanud mikroteenuste arhitektuuri modulaarsüsteemi jälgimise korraldamisest. Miski ei seisa paigal, meie projekt kasvab pidevalt ning salvestatavate mõõdikute arv samuti. Kuidas me korraldasime ülemineku Graphite+Whisperilt Graphite+ClickHouse'ile kõrgete koormuste tingimustes, ootustest selle suhtes ja migreerimise tulemustest lugege allpool.

Enne kui räägin, kuidas me korraldasime ülemineku Graphite+Whisperilt Graphite+ClickHouse'ile, tahaksin jagada teavet sellise otsuse vastuvõtmise põhjuste ja Whisperi puuduste kohta, millega oleme pikka aega elanud.

Graphite+Whisperi probleemid

1. Kõrge koormus ketasüsteemile

Kui meile üle mindi, tuli umbes 1,5 miljonit mõõdikut minutis. Sellise mahuga oli serverite ketaste kasutus umbes 30%. Üldiselt oli see täiesti vastuvõetav — kõik toimis stabiilselt, kirjutas kiiresti, luges kiiresti... Kuni hetkeni, mil üks arendusmeeskond käivitas uue funktsiooni ja hakkas meile saatma 10 miljonit mõõdikut minutis. Siis läks ketasüsteem tõeliselt koormusse ja nägime 100% kasutust. Probleem suudeti kiiresti lahendada, kuid maitse jäi.

2. Replikatsiooni ja järjepidevuse puudumine

Tõenäoliselt, nagu kõik, kes on kasutanud /kasutavad Graphite+Whisper, saatsime me sama mõõdikute voolu mitmele Graphite-serverile, et saavutada juurutatud usaldusväärsus. Sellega ei olnud erilisi probleeme — kuni hetkeni, mil üks server mingil põhjusel ei kukkunud. Mõnikord suutsime kukkunud serveri piisavalt kiiresti üles tõsta, ja carbon-c-relay jõudis selle kasti sisestada mõõdikud oma vahemälust, mõnikord aga mitte. Ja siis jäi mõõdikutesse auk, mille me täitsime rsync`i abil. Protseduur oli piisavalt pikk. Aitas ainult see, et selline asi juhtus väga harva. Samuti võtsime aeg-ajalt juhusliku mõõdikute komplekti ja võrdlesime neid teiste samalaadsete andmetega naabernodes klastris. Umbes 5% juhtudest erinevad mõned väärtused, mis ei olnud meelepärane.

3. Suur ruumihulk

Kuna me kirjutame Graphitese mitte ainult infrastruktuuri, vaid ka ärinäitajaid (ja nüüd isegi Kubernetesest tulevaid näitajaid), siis satume üsna sageli olukorda, kus näitajas on ainult mõned väärtused, samas kui .wsp-faili luuakse kogu säilitamisperioodi arvesse võttes ja see võtab ettenähtud mälu, mis meile oli umbes 2 MB. Probleemi süvendab veel see, et selliseid faile tekib aja jooksul väga palju ning aruande koostamisel nende üle kulub arvukate tühjade punktide lugemisele palju aega ja ressursse.

Tahaks kohe märkida, et eespool kirjeldatud probleemidega saab tõhusalt võidelda erinevate meetoditega, kuid mida rohkem andmeid te hajate, seda teravamaks need probleemid muutuvad.

Kuna meil on kõik eeltoodud (arvestades eelnevat artikkel), samuti pidev kasv saadud näitajate arvu osas ja soov viia kõik näitajad 30-sekundit säilitamisintervallile (vajadusel kuni 10 sekundit), otsustasime proovida Graphite+ClickHouse kui perspektiivikat alternatiivi Whisperile.

Graphite+ClickHouse. Ootused

Külastades mitmeid Yandexi üritusi ja lugedes mõningaid artikleid Habrast, läbivaatamisel dokumentatsiooni ja leidmisel mõistlikke komponente ClickHouse'i Graphite'i sidumiseks, otsustasime tegutsema asuda!

Soovisime saavutada järgmist:

• väheneda ketasüsteemi kasutamine 30%-lt 5%-le;
• vähendada hõivatud ruumi 1TB-lt 100GB-le;
• omada võimet vastu võtta 100 miljonit mõõtme minutis serverisse;
• andmete replikatsioon ja tõrke kestvus välja pakutud lahenduses;
• mitte viibida selle projekti juures aastat, vaid teha üleminek mõistliku aja jooksul;
• lülituda ilma seisakuta.

Seda on üsna ambitsioonikas, eks?

Graphite+ClickHouse. Komponendid

Andmete saamiseks Graphite'i protokolli kaudu ja nende edasiseks salvestamiseks ClickHouse'i, valiti carbon-clickhouse (golang).

Ajavahemike salvestamiseks valiti selle hetke uusim ClickHouse'i stabiilne versioon 1.1.54253. Selle kasutamisel esines probleeme: logides ilmnes palju vigu ja ei olnud päris selge, mida nendega teha. Koos Roman Lomonosovi (carbon-clickhouse, graphite-clickhouse ja veel paljude muude autor) valiti vanem versioon 1.1.54236.Vead kadusid — kõik hakkas tööle suurepäraselt.

Andmete lugemiseks ClickHouse'ist valiti graphite-slickhouse (golang). Graphite'i API-liidese jaoks — carbonapi (golang). Klientide vahelise replikatsiooni korraldamiseks ClickHouse'i tabelite vahel kasutati zookeeper. Meie väga armastatud jaoks metrikate suunamiseks jätsime carbon-c-relay (C) (vt eelmine artikkel).

Graphite+ClickHouse. Tabelite struktuur

“graphite” — andmebaas, mille lõime jälgimistabelite jaoks.

“graphite.metrics” — tabel ReplikaadiAsendavaMerePuuna (replicating ReplacingMergeTree). See tabel sisaldab metrikate nimesid ja teede viiteid.

Loo tabel graphite.metrics ( Kuupäev Kuupäev, Tase UInt32, Tee String, Kustutatud UInt8, Versioon UInt32 ) MOOTOR = ReplikaadiAsendavaMerePuuna('/clickhouse/tables/replicator/graphite.metrics', ‘r1’, Kuupäev, (Tase, Tee), 8192, Versioon);

“graphite.data” — tabel ReplikaadiGraafikaMerePuuna (replicating GraphiteMergeTree). See tabel sisaldab metrikate väärtusi.

Loo tabel graphite.data ( Tee String, Väärtus Float64, Aeg UInt32, Kuupäev Kuupäev, Ajatemperatuur UInt32 ) MOOTOR = ReplikaadiGraafikaMerePuuna('/clickhouse/tables/replicator/graphite.data', 'r1', Kuupäev, (Tee, Aeg), 8192, 'graphite_rollup')

“graphite.date_metrics” — tingimuse alusel täidetav tabel, ReplikaadiAsendavaMerePuuna mootoriga. Selles tabelis salvestatakse kõikide metrikate nimed, mis on päeva jooksul esinenud. Loomise põhjused on kirjeldatud jaotises „Probleemid“ käesoleva artikli lõpus.

LOO KERQUJUK 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, mis täidetakse tingimustes, ReplicatedAggregatingMergeTree (replicating) AggregatingMergeTree). Sellesse tabelisse salvestatakse sissetulevate mõõdikute arv, eraldiseisvusega kuni 4 taseme sügavusest.

LOO KERQUJUK 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. Komponentide koostöö skeem

Graphite+ClickHouse. Andmete rändamine

Kuna me mäletame, olid oodata, et see projekt peaks toimuma ilma katkestusteta, seega pidime me viima kogu meie seire süsteemi uude salvestusse nii, et see oleks meie kasutajatele võimalikult läbipaistev.
Me tegime seda nii.

• carbon-c-relay'le on lisatud reegel, et saata täiendav mõõdikute voog carbon-clickhouse'i ühest serverist, mis osaleb ClickHouse tabelite replikatsioonis.

• Kirjutasime väikese python skripti, mis kasutas whisper-dump teeki, et lugeda meie salvestusest välja kõik .wsp-failid ja saata need andmed ülalmainitud carbon-clickhouse'i 24 voogus. Saadetud mõõdikute väärtuste arv carbon-clickhouse'is ulatus 125 miljonini minutis, ja ClickHouse ei väsinud isegi.

• Loomisime Grafanas eraldi DataSource'i, et testida funktsioone, mida kasutatakse olemasolevates armatuurlaudades. Tuvasime loendi funktsioonidest, mida kasutasime, kuid need ei olnud carbonapi's rakendatud. Kirjutasime need funktsioonid juurde ja saatsime PR'id carbonapi autoritele (teise kordame nendele tänu).

• Lugemisekoormuse vahetamiseks muutsime tasakaalustajate seadetes lõpp-punkte graphite-api'lt (Graphite + Whisperi API liides) carbonapi'le.

Graphite + ClickHouse. Tulemused

• vähendasime diskisüsteemi kasutust 30%-lt 1%-ni;

  

• vähendasime hõivatava ruumi 1 TB-lt 300 GB-le;
• saame vastu võtta 125 miljonit mõõdikut minutis serverisse (tipud migreerimise ajal);
• oleme kõik mõõdikud viinud kolmekümne sekundi säilitamisintervallile;
• saime andmete replikatsioon ja tõrkeotsing;
• lülitusime suutmata katkestusteta;
• kulutasime sellele umbkaudu 7 nädalat.

Graphite+ClickHouse. Probleemid

Meie olukord ei lahenenud ilma tagasilöögita. Siin on, millega me silmitsi seisime pärast üleminekut.

1. ClickHouse ei loe konfigureerimisi alati automaatselt, mõnikord tuleb seda taaskäivitada. Näiteks, kui tegemist on zookeeperi klastriga ClickHouse'i konfiguratsioonis — see ei rakendunud enne clickhouse-serveri taaskäivitamist.
2. Suurte ClickHouse päringute kaudu ei saadud läbi, seega näeb meie graphite-clickhouse ühenduse string ClickHouse'iga välja niimoodi:

   url = "http://localhost:8123/?max_query_size=268435456&max_ast_elements=1000000"

3. ClickHouse'is ilmub üsna tihti uusi stabiilsete versioonide väljaandeid, milles võivad olla üllatused: ole ettevaatlik.
4. Dünaamiliselt loodud konteinerid Kuberneteses saadavad suures koguses mõõdikute andmeid lühikese ja juhusliku elueaga. Selliseid mõõdikute punkte on vähe ja ruumi probleemidega ei ole. Kuid ClickHouse'i päringute koostamisel tõstab see tohutult palju neid mõõdikute andmeid tabelist 'metrics'. 90% juhtudel puuduvad nende andmed antud ajavahemikus (24 tundi). Aeg, mis kulub nende andmete leidmiseks tabelist 'data', on samuti tähelepanuväärne ja lõppkokkuvõttes ulatub see ajapiirangute tõttu ajaülevaatusse. Selle probleemi lahendamiseks hakkasime pidama eraldi vaadet mõõdikute kohta, mis leiti ühe päeva jooksul. Seetõttu küsitleme aruandeid (grafikuid) koostades dünaamiliselt loodud konteinerite kohta ainult neid mõõdikuid, mis leiti määratud ajavahemiku jooksul, mitte kogu ajaloos, mis kiirendas nende aruannete koostamist märkimisväärselt. Ülaltoodud lahenduse jaoks on koostatud graphite-clickhouse (fork), sealhulgas rakenduse rakendamine tabeliga date_metrics.

Graphite+ClickHouse. Silte

Versioonist 1.1.0 hakkas Graphite ametlikult toetama silte. Ja me mõtleme aktiivselt, mida ja kuidas tuleks teha, et toetada seda algatust graphite+clickhouse virnas.

Graphite+ClickHouse. Anomaaliate avastamise süsteem

Ülaltoodud infrastruktuuri põhjal oleme loonud anomaaliate avastamise prototüübi, ja see töötab! Kuid sellest räägime järgmises artiklis.

Tellige, vajutage ülespoole noolt ja olge õnnelikud!

Allikas: habr.com