Halo semua! Di miliknya artikel terakhir Saya menulis tentang pengorganisasian sistem pemantauan modular untuk arsitektur layanan mikro. Tidak ada yang berhenti, proyek kami terus berkembang, begitu pula jumlah metrik yang disimpan. Bagaimana kami mengatur transisi dari Graphite+Whisper ke Graphite+ClickHouse dalam kondisi beban tinggi, baca tentang ekspektasi darinya dan hasil migrasi dalam pemotongan.

Sebelum saya memberi tahu Anda bagaimana kami mengatur transisi dari penyimpanan metrik di Graphite+Whisper ke Graphite+ClickHouse, saya ingin memberikan informasi tentang alasan pengambilan keputusan seperti itu dan tentang kelemahan Whisper yang sudah lama kami alami.

Masalah Grafit+Bisikan

1. Beban tinggi pada subsistem disk

Pada saat transisi, sekitar 1.5 juta metrik dikirimkan kepada kami setiap menitnya. Dengan aliran seperti itu, pemanfaatan disk di server adalah ~30%. Secara umum, ini cukup dapat diterima - semuanya bekerja dengan stabil, ditulis dengan cepat, dibaca dengan cepat... Sampai salah satu tim pengembangan meluncurkan fitur baru dan mulai mengirimi kami 10 juta metrik per menit. Saat itulah subsistem disk diperketat, dan kami melihat pemanfaatan 100%. Masalahnya cepat terselesaikan, namun masih ada sisa.

2. Kurangnya replikasi dan konsistensi

Kemungkinan besar, seperti semua orang yang menggunakan/menggunakan Graphite+Whisper, kami menuangkan aliran metrik yang sama ke beberapa server Graphite sekaligus untuk menciptakan toleransi kesalahan. Dan tidak ada masalah khusus dengan ini - sampai salah satu server mogok karena alasan tertentu. Terkadang kami berhasil mengambil server yang mogok dengan cukup cepat, dan carbon-c-relay berhasil memuat metrik dari cache ke dalamnya, namun terkadang tidak. Dan kemudian ada lubang di metrik, yang kami isi dengan rsync. Prosedurnya cukup panjang. Satu-satunya anugrah adalah hal ini sangat jarang terjadi. Kami juga secara berkala mengambil serangkaian metrik acak dan membandingkannya dengan metrik lain yang sejenis pada node tetangga dalam cluster. Pada sekitar 5% kasus, ada beberapa nilai yang berbeda, yang membuat kami tidak terlalu senang.

3. Jejak kaki yang besar

Karena kami menulis di Grafit tidak hanya infrastruktur, tetapi juga metrik bisnis (dan sekarang juga metrik dari Kubernetes), kami cukup sering mendapatkan situasi di mana metrik hanya berisi beberapa nilai, dan file .wsp dibuat dengan mempertimbangkan semua retensi. periode, dan memakan jumlah ruang yang telah dialokasikan sebelumnya, yang bagi kami setara dengan ~2MB. Masalahnya semakin diperburuk oleh kenyataan bahwa banyak file serupa muncul seiring waktu, dan ketika membuat laporan berdasarkan file tersebut, membaca poin kosong membutuhkan banyak waktu dan sumber daya.

Saya ingin segera mencatat bahwa masalah yang dijelaskan di atas dapat diatasi dengan menggunakan berbagai metode dan dengan tingkat efektivitas yang berbeda-beda, namun semakin banyak data yang Anda terima, semakin parah masalah tersebut.

Memiliki semua hal di atas (dengan mempertimbangkan yang sebelumnya Artikel), serta peningkatan konstan dalam jumlah metrik yang diterima, keinginan untuk mentransfer semua metrik ke interval penyimpanan 30 detik. (hingga 10 detik jika perlu), kami memutuskan untuk mencoba Graphite+ClickHouse sebagai alternatif yang menjanjikan untuk Whisper.

Grafit+ClickHouse. Harapan

Setelah mengunjungi beberapa pertemuan orang-orang dari Yandex, setelah membaca beberapa artikel tentang Habré, setelah membaca dokumentasi dan menemukan komponen yang masuk akal untuk mengikat ClickHouse di bawah Graphite, kami memutuskan untuk mengambil tindakan!

Saya ingin menerima yang berikut ini:

mengurangi pemanfaatan subsistem disk dari 30% menjadi 5%;
mengurangi jumlah ruang yang digunakan dari 1TB menjadi 100GB;
dapat menerima 100 juta metrik per menit ke server;
replikasi data dan toleransi kesalahan secara langsung;
jangan menunda proyek ini selama satu tahun dan melakukan transisi dalam jangka waktu yang wajar;
beralih tanpa downtime.

Cukup ambisius, bukan?

Grafit+ClickHouse. Komponen

Untuk menerima data melalui protokol Graphite dan kemudian merekamnya di ClickHouse, saya memilih rumah klik karbon (golang).

Rilis terbaru ClickHouse, versi stabil 1.1.54253, dipilih sebagai database untuk menyimpan deret waktu. Ada masalah saat mengerjakannya: segunung kesalahan muncul di log, dan tidak sepenuhnya jelas apa yang harus dilakukan dengannya. Dalam diskusi dengan Romawi Lomonosov (penulis carbon-clickhouse, graphite-clickhouse dan masih banyak lagi) yang lebih tua dipilih rilis 1.1.54236. Kesalahannya hilang - semuanya mulai bekerja dengan baik.

Dipilih untuk membaca data dari ClickHouse grafit-сlickhouse (golang). Sebagai API untuk Grafit - carbonapi (golang). ClickHouse digunakan untuk mengatur replikasi antar tabel zookeeper. Untuk metrik perutean, kami meninggalkan kekasih kami karbon-c-relay (C) (lihat artikel sebelumnya).

Grafit+ClickHouse. Struktur tabel

"grafit" adalah database yang kami buat untuk tabel pemantauan.

"graphite.metrics" - tabel dengan mesin ReplicationdReplacingMergeTree (direplikasi Mengganti MergeTree). Tabel ini menyimpan nama metrik dan jalur ke metrik tersebut.

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 dengan mesin ReplicationGraphiteMergeTree (direplikasi Pohon Penggabungan Grafit). Tabel 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” adalah tabel yang diisi secara kondisional dengan mesin ReplicationdReplacingMergeTree. Tabel ini mencatat nama semua metrik yang ditemukan sepanjang hari. Alasan pembuatannya dijelaskan di bagian ini "Masalah" di 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” - tabel yang diisi berdasarkan kondisi, dengan mesin ReplicationAggregatingMergeTree (direplikasi Agregasi MergeTree). Tabel ini mencatat jumlah metrik masuk, yang dibagi menjadi 4 tingkat bertingkat.

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

Seperti yang kami ingat dari ekspektasi proyek ini, transisi ke ClickHouse harus tanpa downtime; oleh karena itu, kami harus mengalihkan seluruh sistem pemantauan kami ke penyimpanan baru setransparan mungkin bagi pengguna kami.
Beginilah cara kami melakukannya.

Sebuah aturan telah ditambahkan ke carbon-c-relay untuk mengirimkan aliran metrik tambahan ke carbon-clickhouse dari salah satu server yang berpartisipasi dalam replikasi tabel ClickHouse.
Kami menulis skrip kecil dengan python, yang, menggunakan perpustakaan Whisper-dump, membaca semua file .wsp dari penyimpanan kami dan mengirimkan data ini ke carbon-clickhouse yang dijelaskan di atas dalam 24 thread. Jumlah nilai metrik yang diterima di carbon-clickhouse mencapai 125 juta/menit, dan ClickHouse bahkan tidak mengeluarkan banyak keringat.
Kami membuat DataSource terpisah di Grafana untuk men-debug fungsi yang digunakan di dasbor yang ada. Kami mengidentifikasi daftar fungsi yang kami gunakan, tetapi fungsi tersebut tidak diterapkan di carbonapi. Kami menambahkan fungsi-fungsi ini dan mengirimkan PR ke penulis carbonapi (terima kasih khusus kepada mereka).
Untuk mengalihkan beban baca di pengaturan penyeimbang, kami mengubah titik akhir dari graphite-api (antarmuka API untuk Graphite+Whisper) menjadi carbonapi.

Grafit+ClickHouse. hasil

pengurangan pemanfaatan subsistem disk dari 30% menjadi 1%;
mengurangi jumlah ruang yang digunakan dari 1 TB menjadi 300 GB;
kami memiliki kemampuan untuk menerima 125 juta metrik per menit ke server (puncaknya pada saat migrasi);
mentransfer semua metrik ke interval penyimpanan tiga puluh detik;
menerima replikasi data dan toleransi kesalahan;
beralih tanpa downtime;
Butuh waktu sekitar 7 minggu untuk menyelesaikan semuanya.

Grafit+ClickHouse. Masalah

Dalam kasus kami, ada beberapa kendala. Inilah yang kami temui setelah transisi.

ClickHouse tidak selalu membaca ulang konfigurasi dengan cepat; terkadang perlu di-boot ulang. Misalnya, dalam kasus deskripsi cluster zookeeper di konfigurasi ClickHouse, itu tidak digunakan sampai server clickhouse di-boot ulang.
Permintaan ClickHouse yang besar tidak diproses, jadi di graphite-clickhouse, string koneksi ClickHouse kami terlihat seperti ini:
```
url = "http://localhost:8123/?max_query_size=268435456&max_ast_elements=1000000"
```
ClickHouse cukup sering merilis versi baru dari rilis stabil; mungkin ada kejutan di dalamnya: hati-hati.
Kontainer yang dibuat secara dinamis di kubernetes mengirimkan metrik dalam jumlah besar dengan masa pakai yang singkat dan acak. Tidak banyak poin untuk metrik tersebut, dan tidak ada masalah dengan ruang. Namun saat membuat kueri, ClickHouse mengambil sejumlah besar metrik yang sama dari tabel 'metrik'. Dalam 90% kasus, tidak ada data tentangnya di luar jendela (24 jam). Namun waktu dihabiskan untuk mencari data ini di tabel 'data', dan akhirnya mengalami batas waktu. Untuk mengatasi masalah ini, kami mulai mempertahankan pandangan terpisah dengan informasi tentang metrik yang ditemui sepanjang hari. Jadi, saat membuat laporan (grafik) untuk penampung yang dibuat secara dinamis, kami hanya menanyakan metrik yang ditemukan dalam jendela tertentu, dan tidak sepanjang waktu, yang secara signifikan mempercepat pembuatan laporan pada penampung tersebut. Untuk solusi yang dijelaskan di atas, saya kumpulkan grafit-clickhouse (garpu), yang mencakup implementasi bekerja dengan tabel date_metrics.

Grafit+ClickHouse. Tag

Dengan versi 1.1.0 Grafit menjadi resmi tag dukungan. Dan kami secara aktif memikirkan tentang apa dan bagaimana yang harus dilakukan untuk mendukung inisiatif di tumpukan grafit+clickhouse ini.

Grafit+ClickHouse. Detektor anomali

Berdasarkan infrastruktur yang dijelaskan di atas, kami telah menerapkan prototipe pendeteksi anomali, dan berhasil! Namun lebih banyak tentang dia di artikel berikutnya.

Berlangganan, tekan panah atas dan berbahagialah!

Sumber: www.habr.com

Penyimpanan metrik: cara kami beralih dari Graphite+Whisper ke Graphite+ClickHouse