Hai semua! Dalam dia artikel terakhir Saya menulis tentang menganjurkan sistem pemantauan modular untuk seni bina perkhidmatan mikro. Tiada apa-apa yang berhenti, projek kami sentiasa berkembang, dan begitu juga bilangan metrik yang disimpan. Cara kami mengatur peralihan daripada Graphite+Whisper kepada Graphite+ClickHouse dalam keadaan muatan tinggi, baca tentang jangkaan daripadanya dan hasil penghijrahan di bawah potongan.

Sebelum saya memberitahu anda cara kami mengatur peralihan daripada menyimpan metrik dalam Graphite+Whisper kepada Graphite+ClickHouse, saya ingin memberikan maklumat tentang sebab membuat keputusan sedemikian dan tentang keburukan Whisper yang telah lama kami jalani.

Masalah grafit+Bisikan

1. Beban tinggi pada subsistem cakera

Pada masa peralihan, kira-kira 1.5 juta metrik tiba kepada kami seminit. Dengan aliran sedemikian, penggunaan cakera pada pelayan ialah ~30%. Secara umum, ini agak boleh diterima - semuanya berfungsi dengan stabil, ditulis dengan cepat, baca dengan cepat... Sehingga salah satu pasukan pembangunan melancarkan ciri baharu dan mula menghantar kepada kami 10 juta metrik seminit. Pada masa itulah subsistem cakera mengetatkan, dan kami melihat penggunaan 100%. Masalahnya telah diselesaikan dengan cepat, tetapi sisanya kekal.

2. Kurang replikasi dan konsistensi

Kemungkinan besar, seperti semua orang yang menggunakan/menggunakan Graphite+Whisper, kami menuangkan aliran metrik yang sama ke beberapa pelayan Graphite sekaligus untuk mewujudkan toleransi kesalahan. Dan tidak ada masalah khusus dengan ini - sehingga saat salah satu pelayan terhempas atas sebab tertentu. Kadangkala kami berjaya mengambil pelayan yang jatuh dengan cukup cepat, dan relay karbon-c berjaya memuatkan metrik daripada cachenya ke dalamnya, tetapi kadangkala tidak. Dan kemudian terdapat lubang dalam metrik, yang kami isi dengan rsync. Prosedurnya agak panjang. Satu-satunya rahmat yang menyelamatkan adalah bahawa ini berlaku sangat jarang. Kami juga secara berkala mengambil set metrik rawak dan membandingkannya dengan metrik lain yang sama pada nod jiran kluster. Dalam kira-kira 5% kes, beberapa nilai adalah berbeza, yang kami tidak begitu gembira.

3. Jejak yang besar

Memandangkan kami menulis dalam Graphite bukan sahaja infrastruktur, tetapi juga metrik perniagaan (dan kini juga metrik daripada Kubernetes), kami sering mendapat situasi di mana metrik mengandungi hanya beberapa nilai dan fail .wsp dibuat dengan mengambil kira semua pengekalan tempoh, dan menggunakan jumlah ruang yang telah diperuntukkan sebelumnya, yang bagi kami ialah ~2MB. Masalahnya diburukkan lagi oleh fakta bahawa banyak fail serupa muncul dari semasa ke semasa, dan apabila membina laporan mengenainya, membaca mata kosong memerlukan banyak masa dan sumber.

Saya ingin segera ambil perhatian bahawa masalah yang diterangkan di atas boleh ditangani dengan menggunakan pelbagai kaedah dan dengan tahap keberkesanan yang berbeza-beza, tetapi semakin banyak data yang anda mula terima, semakin bertambah teruk.

Mempunyai semua perkara di atas (dengan mengambil kira yang sebelumnya Perkara), serta peningkatan berterusan dalam bilangan metrik yang diterima, keinginan untuk memindahkan semua metrik ke selang storan selama 30 saat. (sehingga 10 saat jika perlu), kami memutuskan untuk mencuba Graphite+ClickHouse sebagai alternatif yang menjanjikan kepada Whisper.

Grafit+ClickHouse. Jangkaan

Setelah melawat beberapa pertemuan lelaki dari Yandex, setelah membaca beberapa artikel tentang Habré, setelah melalui dokumentasi dan menemui komponen yang waras untuk mengikat ClickHouse di bawah Graphite, kami memutuskan untuk mengambil tindakan!

Saya ingin menerima yang berikut:

mengurangkan penggunaan subsistem cakera daripada 30% kepada 5%;
mengurangkan jumlah ruang yang diduduki daripada 1TB kepada 100GB;
boleh menerima 100 juta metrik seminit ke dalam pelayan;
replikasi data dan toleransi kesalahan di luar kotak;
jangan duduk di projek ini selama setahun dan buat peralihan dalam tempoh masa yang munasabah;
bertukar tanpa masa henti.

Agak bercita-cita tinggi, bukan?

Grafit+ClickHouse. Komponen

Untuk menerima data melalui protokol Grafit dan seterusnya merekodkannya dalam ClickHouse, saya memilih rumah klik karbon (golang).

Keluaran terkini ClickHouse, versi stabil 1.1.54253, telah dipilih sebagai pangkalan data untuk menyimpan siri masa. Terdapat masalah semasa bekerja dengannya: segunung ralat dicurahkan ke dalam balak, dan ia tidak sepenuhnya jelas apa yang perlu dilakukan dengannya. Dalam perbincangan dengan Rom Lomonosov (pengarang carbon-clickhouse, graphite-clickhouse dan banyak lagi) yang lebih lama dipilih keluaran 1.1.54236. Kesilapan hilang - semuanya mula berfungsi dengan hebat.

Dipilih untuk membaca data daripada ClickHouse grafit-сlickhouse (golang). Sebagai API untuk Grafit − carbonapi (golang). ClickHouse digunakan untuk mengatur replikasi antara jadual penjaga zoo. Untuk metrik penghalaan, kami meninggalkan kekasih kami geganti karbon-c (DENGAN) (lihat artikel sebelum ini).

Grafit+ClickHouse. Struktur jadual

"grafit" ialah pangkalan data yang kami cipta untuk memantau jadual.

“graphite.metrics” - jadual dengan enjin ReplicatedReplacingMergeTree (direplikasi MenggantiMergeTree). Jadual ini menyimpan nama metrik dan laluan kepada mereka.

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” - jadual dengan enjin ReplicatedGraphiteMergeTree (replika GraphiteMergeTree). Jadual ini menyimpan 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” ialah jadual yang diisi bersyarat dengan enjin ReplicatedReplacingMergeTree. Jadual ini merekodkan nama semua metrik yang ditemui pada siang hari. Sebab-sebab penciptaannya diterangkan dalam bahagian "Masalah" pada akhir artikel ini.

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” - jadual yang diisi mengikut keadaan, dengan enjin ReplicatedAggregatingMergeTree (direplikasi MengagregatMergeTree). Jadual ini merekodkan bilangan metrik masuk, dipecahkan kepada 4 tahap bersarang.

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. Gambar rajah interaksi komponen

Grafit+ClickHouse. Penghijrahan data

Seperti yang kami ingat daripada jangkaan daripada projek ini, peralihan kepada ClickHouse sepatutnya tanpa masa henti; oleh itu, kami terpaksa menukar keseluruhan sistem pemantauan kami kepada storan baharu setelus mungkin untuk pengguna kami.
Ini adalah bagaimana kami melakukannya.

Peraturan telah ditambahkan pada relay karbon-c untuk menghantar aliran metrik tambahan ke rumah klik karbon bagi salah satu pelayan yang mengambil bahagian dalam replikasi jadual ClickHouse.
Kami menulis skrip kecil dalam python, yang, menggunakan perpustakaan whisper-dump, membaca semua fail .wsp daripada storan kami dan menghantar data ini ke carbon-clickhouse yang diterangkan di atas dalam 24 utas. Bilangan nilai metrik yang diterima dalam carbon-clickhouse mencapai 125 juta/min, dan ClickHouse tidak berpeluh.
Kami mencipta DataSource yang berasingan dalam Grafana untuk menyahpepijat fungsi yang digunakan dalam papan pemuka sedia ada. Kami mengenal pasti senarai fungsi yang kami gunakan, tetapi ia tidak dilaksanakan dalam carbonapi. Kami menambahkan fungsi ini dan menghantar PR kepada pengarang carbonapi (terima kasih khas kepada mereka).
Untuk menukar beban bacaan dalam tetapan pengimbang, kami menukar titik akhir daripada grafit-api (antara muka API untuk Graphite+Whisper) kepada carbonapi.

Grafit+ClickHouse. keputusan

mengurangkan penggunaan subsistem cakera daripada 30% kepada 1%;
mengurangkan jumlah ruang yang diduduki daripada 1 TB kepada 300 GB;
kami mempunyai keupayaan untuk menerima 125 juta metrik seminit ke dalam pelayan (puncak pada masa penghijrahan);
memindahkan semua metrik ke selang storan tiga puluh saat;
menerima replikasi data dan toleransi kesalahan;
bertukar tanpa masa henti;
Ia mengambil masa kira-kira 7 minggu untuk menyelesaikan semuanya.

Grafit+ClickHouse. Masalah

Dalam kes kami, terdapat beberapa perangkap. Inilah yang kami temui selepas peralihan.

ClickHouse tidak selalu membaca semula konfigurasi dengan cepat; kadangkala ia perlu dibut semula. Sebagai contoh, dalam kes perihalan kluster penjaga zoo dalam konfigurasi ClickHouse, ia tidak digunakan sehingga pelayan clickhouse dibut semula.
Permintaan ClickHouse yang besar tidak berjaya, jadi dalam graphite-clickhouse rentetan sambungan ClickHouse kami kelihatan seperti ini:
```
url = "http://localhost:8123/?max_query_size=268435456&max_ast_elements=1000000"
```
ClickHouse agak kerap mengeluarkan versi baharu keluaran stabil; ia mungkin mengandungi kejutan: berhati-hati.
Bekas yang dibuat secara dinamik dalam kubernetes menghantar sejumlah besar metrik dengan jangka hayat yang singkat dan rawak. Tidak banyak mata untuk metrik sedemikian dan tiada masalah dengan ruang. Tetapi apabila membina pertanyaan, ClickHouse mengambil sejumlah besar metrik yang sama ini daripada jadual 'metrik'. Dalam 90% kes, tiada data mengenainya di luar tetingkap (24 jam). Tetapi masa dihabiskan untuk mencari data ini dalam jadual 'data', dan akhirnya tamat masa. Untuk menyelesaikan masalah ini, kami mula mengekalkan pandangan yang berasingan dengan maklumat tentang metrik yang ditemui pada siang hari. Oleh itu, apabila membina laporan (graf) untuk bekas yang dibuat secara dinamik, kami hanya menanyakan metrik yang ditemui dalam tetingkap tertentu dan bukan untuk sepanjang masa, yang mempercepatkan pembinaan laporan mengenainya dengan ketara. Untuk penyelesaian yang diterangkan di atas, saya kumpulkan graphite-clickhouse (garpu), yang termasuk pelaksanaan bekerja dengan jadual date_metrics.

Grafit+ClickHouse. Tag

Dengan versi 1.1.0 Grafit menjadi rasmi tag sokongan. Dan kami secara aktif memikirkan perkara dan cara untuk menyokong inisiatif ini dalam timbunan grafit+clickhouse.

Grafit+ClickHouse. Pengesan anomali

Berdasarkan infrastruktur yang diterangkan di atas, kami telah melaksanakan prototaip pengesan anomali, dan ia berfungsi! Tetapi lebih lanjut mengenai dia dalam artikel seterusnya.

Langgan, tekan anak panah ke atas dan gembira!

Sumber: www.habr.com

Storan metrik: cara kami bertukar daripada Graphite+Whisper kepada Graphite+ClickHouse