Halo kabeh! Ing dheweke artikel pungkasan Aku nulis babagan ngatur sistem pemantauan modular kanggo arsitektur microservice. Ora ana sing mandheg, proyek kita terus berkembang, lan uga jumlah metrik sing disimpen. Carane kita ngatur transisi saka Graphite + Whisper kanggo Graphite + ClickHouse ing kahanan mbukak dhuwur, maca babagan pangarepan saka iku lan asil migrasi ing Cut.

Sadurunge aku pitutur marang kowe carane kita ngatur transisi saka nyimpen metrik ing Graphite+Whisper kanggo Graphite+ClickHouse, aku arep kanggo menehi informasi bab alasan kanggo nggawe kaputusan kuwi lan bab kerugian saka Whisper sing kita urip karo kanggo dangu.

Masalah grafit + bisikan

1. Beban dhuwur ing subsistem disk

Ing wektu transisi, kira-kira 1.5 yuta metrik teka ing kita saben menit. Kanthi aliran kasebut, panggunaan disk ing server yaiku ~ 30%. Umumé, iki cukup ditrima - kabeh bisa digunakake kanthi stabil, ditulis kanthi cepet, diwaca kanthi cepet ... Nganti salah sawijining tim pangembangan ngetokake fitur anyar lan wiwit ngirim 10 yuta metrik saben menit. Nalika iku subsistem disk tightened munggah, lan kita weruh 100% pemanfaatan. Masalah kasebut cepet ditanggulangi, nanging isih ana sisa.

2. Kurang replikasi lan konsistensi

Paling kamungkinan, kaya kabeh wong sing nggunakake / nggunakake Graphite + Whisper, kita diwutahake aliran metrik padha menyang sawetara server Graphite bebarengan kanggo nggawe toleransi fault. Lan ora ana masalah khusus karo iki - nganti wayahe salah sawijining server nabrak sakperangan alesan. Kadhangkala kita bisa njupuk server sing tiba kanthi cepet, lan karbon-c-relay bisa mbukak metrik saka cache menyang, nanging kadhangkala ora. Banjur ana bolongan ing metrik, sing diisi karo rsync. Prosedur iki cukup dawa. Siji-sijine sih-rahmat sing nylametake yaiku kedadeyan kasebut arang banget. Kita uga kanthi periodik njupuk metrik acak lan mbandhingake karo wong liya sing padha ing simpul tetanggan kluster. Ing babagan 5% kasus, sawetara nilai beda-beda, sing kita ora seneng banget.

3. Tapak gedhe

Amarga kita nulis ing Graphite ora mung infrastruktur, nanging uga metrik bisnis (lan saiki uga metrik saka Kubernetes), kita cukup kerep nemu kahanan sing metrik mung ngemot sawetara nilai, lan file .wsp digawe kanthi njupuk kabeh retensi. wektu, lan njupuk munggah jumlah wis diparengake papan, kang kanggo kita ana ~ 2MB. Masalah kasebut saya tambah akeh amarga akeh file sing padha katon ing wektu, lan nalika nggawe laporan, maca titik kosong mbutuhake wektu lan sumber daya.

Aku pengin langsung nyathet yen masalah sing diterangake ing ndhuwur bisa ditangani kanthi nggunakake macem-macem cara lan tingkat efektifitas sing beda-beda, nanging luwih akeh data sing sampeyan wiwiti, saya tambah akeh.

Duwe kabeh sing kasebut ing ndhuwur (njupuk akun sadurunge artikel), uga tambah akeh metrik sing ditampa, kepinginan kanggo mindhah kabeh metrik menyang interval panyimpenan 30 detik. (nganti 10 detik yen perlu), kita mutusaké kanggo nyoba Graphite+ClickHouse minangka alternatif janji kanggo Whisper.

Grafit+ClickHouse. Pangarep-arep

Sawise ngunjungi sawetara pertemuan wong lanang saka Yandex, sawise maca saperangan saka artikel ing Habré, Duwe liwat dokumentasi lan nemokake komponen waras kanggo naleni ClickHouse ing Graphite, kita mutusaké kanggo njupuk tindakan!

Aku pengin nampa ing ngisor iki:

nyuda panggunaan subsistem disk saka 30% dadi 5%;
nyuda jumlah papan sing dikuwasani saka 1TB dadi 100GB;
bisa nampa 100 yuta metrik saben menit menyang server;
replikasi data lan toleransi fault metu saka kothak;
ora njagong ing proyek iki kanggo setahun lan nggawe transisi ing wektu cukup;
ngalih tanpa downtime.

Cukup ambisius, ta?

Grafit+ClickHouse. Komponen

Kanggo nampa data liwat protokol Graphite lan banjur ngrekam ing ClickHouse, aku milih karbon-clickhouse (golang).

Rilis paling anyar saka ClickHouse, versi stabil 1.1.54253, dipilih minangka basis data kanggo nyimpen seri wektu. Ana masalah nalika nggarap: gunung kesalahan diwutahake menyang log, lan iku ora tanggung cetha apa apa karo wong-wong mau. Ing rembugan karo Roman Lomonosov (penulis carbon-clickhouse, graphite-clickhouse lan akeh liyane) sing luwih lawas dipilih release 1.1.54236. Kesalahan ilang - kabeh wiwit bisa digunakake.

Dipilih kanggo maca data saka ClickHouse grafit-сlickhouse (golang). Minangka API kanggo Grafit − karbonapi (golang). ClickHouse digunakake kanggo ngatur replikasi antarane tabel penjaga kebon binatang. Kanggo metrik routing, kita ninggalake kekasih kita karbon-c-relay (C) (ndeleng artikel sadurunge).

Grafit+ClickHouse. Struktur tabel

"grafit" minangka basis data sing digawe kanggo ngawasi tabel.

"graphite.metrics" - tabel kanthi mesin ReplicatedReplacingMergeTree (replicated NggantiMergeTree). Tabel iki nyimpen jeneng metrik lan path kanggo wong-wong mau.

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 kanthi mesin ReplicatedGraphiteMergeTree (replicated GraphiteMergeTree). Tabel iki nyimpen nilai metrik.

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" punika Tabel kapenuhan kondisi karo mesin ReplicatedReplacingMergeTree. Tabel iki nyathet jeneng kabeh metrik sing ditemoni ing wayah awan. Alasan kanggo nggawe diterangake ing bagean "Masalah" ing pungkasan artikel iki.

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 sing diisi miturut kondisi, kanthi mesin ReplicatedAggregatingMergeTree (replicated AggregatingMergeTree). Tabel iki nyathet jumlah metrik sing mlebu, dipérang dadi 4 tingkat nesting.

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

Grafit+ClickHouse. Diagram interaksi komponen

Grafit+ClickHouse. Migrasi data

Minangka kita elinga saka pangarepan saka proyek iki, transisi menyang ClickHouse kudu tanpa downtimes; patut, kita kudu piye wae ngalih kabeh sistem ngawasi kanggo panyimpenan anyar minangka transparan sabisa kanggo kita kedhaftar.
Iki carane kita nindakake iku.

A aturan wis ditambahaké kanggo karbon-c-relay kanggo ngirim stream tambahan saka metrik kanggo karbon-clickhouse salah siji saka server melu replikasi tabel ClickHouse.
Kita nulis skrip cilik ing python, sing nggunakake perpustakaan whisper-dump, maca kabeh file .wsp saka panyimpenan lan ngirim data iki menyang carbon-clickhouse sing diterangake ing ndhuwur ing 24 benang. Jumlah nilai metrik sing ditampa ing carbon-clickhouse tekan 125 yuta / min, lan ClickHouse malah ora kringet.
Kita nggawe DataSource kapisah ing Grafana kanggo debug fungsi sing digunakake ing dashboard sing wis ana. Kita nemtokake dhaptar fungsi sing digunakake, nanging ora ditindakake ing carbonapi. Kita nambahake fungsi kasebut lan ngirim PR menyang penulis carbonapi (thanks khusus kanggo wong-wong mau).
Kanggo ngalih beban maca ing setelan balancer, kita ngganti titik pungkasan saka grafit-api (antarmuka API kanggo Graphite + Whisper) dadi carbonapi.

Grafit+ClickHouse. asil

nyuda panggunaan subsistem disk saka 30% dadi 1%;
nyuda jumlah papan sing dikuwasani saka 1 TB dadi 300 GB;
kita duwe kemampuan kanggo nampa 125 yuta metrik saben menit menyang server (puncak nalika migrasi);
ditransfer kabeh metrik menyang interval panyimpenan telung puluh detik;
nampa replikasi data lan toleransi fault;
ngalih tanpa downtime;
Butuh udakara 7 minggu kanggo ngrampungake kabeh.

Grafit+ClickHouse. Masalah

Ing kasus kita, ana sawetara pitfalls. Iki sing ditemoni sawise transisi.

ClickHouse ora tansah maca ulang konfigurasi kanthi cepet; kadhangkala kudu diwiwiti maneh. Contone, ing cilik saka gambaran kluster zookeeper ing ClickHouse config, iki ora digunakake nganti clickhouse-server iki rebooted.
Panjaluk ClickHouse gedhe ora ditindakake, mula ing graphite-clickhouse string sambungan ClickHouse kita katon kaya iki:
```
url = "http://localhost:8123/?max_query_size=268435456&max_ast_elements=1000000"
```
ClickHouse kerep ngeculake versi anyar saka rilis stabil; bisa uga ana kejutan: ati-ati.
Wadhah sing digawe kanthi dinamis ing kubernetes ngirim akeh metrik kanthi umur sing cendhak lan acak. Ora ana akeh poin kanggo metrik kasebut, lan ora ana masalah karo papan. Nanging nalika nggawe pitakon, ClickHouse njupuk akeh metrik sing padha saka tabel 'metrik'. Ing 90% kasus, ora ana data ing njaba jendhela (24 jam). Nanging wektu dibuwang kanggo nggoleki data iki ing tabel 'data', lan pungkasane dadi entek. Kanggo ngatasi masalah iki, kita wiwit njaga tampilan sing kapisah karo informasi babagan metrik sing ditemoni ing wayah awan. Dadi, nalika nggawe laporan (grafik) kanggo wadhah sing digawe kanthi dinamis, kita mung takon metrik sing ditemoni ing jendela tartamtu, lan ora kanggo kabeh wektu, sing nyepetake pambangunan laporan kasebut. Kanggo solusi sing diterangake ing ndhuwur, aku ngumpulake graphite-clickhouse (garpu), sing kalebu implementasine nggarap tabel date_metrics.

Grafit+ClickHouse. Tag

Kanthi versi 1.1.0 Graphite dadi resmi tag dhukungan. Lan kita aktif mikir babagan apa lan kepiye carane ndhukung inisiatif iki ing tumpukan grafit + clickhouse.

Grafit+ClickHouse. Detektor anomali

Adhedhasar prasarana kasebut ing ndhuwur, kita wis ngetrapake prototipe detektor anomali, lan kerjane! Nanging luwih akeh babagan dheweke ing artikel sabanjure.

Langganan, pencet panah munggah lan seneng!

Source: www.habr.com

Panyimpenan metrik: kepiye kita ngalih saka Graphite+Whisper menyang Graphite+ClickHouse