VictoriaMetrics adalah DBMS yang cepat dan terukur untuk menyimpan dan memproses data dalam bentuk deret waktu (catatan terdiri dari waktu dan sekumpulan nilai yang sesuai dengan waktu ini, misalnya, diperoleh melalui polling berkala terhadap status sensor atau kumpulan metrik).
Nama saya Kolobaev Pavel. DevOps, SRE, LeroyMerlin, semuanya seperti kode - semuanya tentang kita: tentang saya dan tentang karyawan LeroyMerlin lainnya.
Ada cloud berdasarkan OpenStack. Ada tautan kecil ke radar teknis.
Itu dibangun pada perangkat keras Kubernetes, serta pada semua layanan terkait untuk OpenStack dan logging.
Ini adalah skema yang kami miliki dalam pengembangan. Saat kami mengembangkan semua ini, kami memiliki operator Prometheus yang menyimpan data di dalam cluster K8s itu sendiri. Dia secara otomatis menemukan apa yang perlu dibersihkan dan meletakkannya di bawah kakinya, secara kasar.
Kita perlu memindahkan semua data ke luar cluster Kubernetes, karena jika terjadi sesuatu, kita perlu memahami apa dan di mana.
Solusi pertama adalah kita menggunakan federasi ketika kita memiliki Prometheus pihak ketiga, ketika kita masuk ke cluster Kubernetes melalui mekanisme federasi.
Namun ada beberapa masalah kecil di sini. Dalam kasus kami, masalahnya dimulai ketika kami memiliki 250 metrik, dan ketika ada 000 metrik, kami menyadari bahwa kami tidak dapat bekerja seperti itu. Kami meningkatkan scrape_timeout menjadi 400 detik.
Mengapa kami harus melakukan ini? Prometheus mulai menghitung waktu tunggu dari awal pagar. Tidak masalah datanya masih mengalir. Jika selama jangka waktu yang ditentukan data tidak digabungkan dan sesi tidak ditutup melalui http, maka sesi dianggap gagal dan data tidak masuk ke Prometheus sendiri.
Semua orang familiar dengan grafik yang kita dapatkan ketika beberapa data hilang. Jadwalnya rusak dan kami tidak senang dengan ini.
Opsi selanjutnya adalah sharding berdasarkan dua Prometheus berbeda melalui mekanisme federasi yang sama.
Misalnya, ambil saja dan pecahkan berdasarkan namanya. Ini juga bisa digunakan, tapi kami memutuskan untuk melanjutkan.
Kami sekarang harus memproses pecahan ini. Anda dapat mengambil promxy, yang masuk ke area shard dan mengalikan data. Ia bekerja dengan dua pecahan sebagai satu titik masuk. Hal ini dapat diimplementasikan melalui promxy, namun masih terlalu sulit.
Opsi pertama adalah kita ingin meninggalkan mekanisme federasi karena sangat lambat.
Pengembang Prometheus dengan jelas mengatakan, "Teman-teman, gunakan TimescaleDB yang berbeda karena kami tidak akan mendukung penyimpanan metrik jangka panjang." Ini bukan tugas mereka.
Kami menuliskan di selembar kertas bahwa kami masih perlu membongkarnya di luar, agar tidak menyimpan semuanya di satu tempat.
Kelemahan kedua adalah konsumsi memori. Ya, saya mengerti bahwa banyak orang akan mengatakan bahwa pada tahun 2020 beberapa gigabyte memori berharga satu sen, tapi tetap saja.
Sekarang kami memiliki lingkungan pengembangan dan produksi. Di dev, ukurannya sekitar 9 gigabyte untuk 350 metrik. Dalam produksinya berukuran 000 gigabyte dan lebih dari 14 metrik. Sementara waktu retensi kami hanya 780 menit. Ini buruk. Dan sekarang saya akan menjelaskan alasannya.
Kami membuat perhitungan, yaitu dengan satu setengah juta metrik, dan kami sudah mendekatinya, pada tahap desain kami mendapatkan memori 35-37 gigabyte. Namun 4 juta metrik sudah memerlukan sekitar 90 gigabyte memori. Artinya, dihitung menggunakan rumus yang disediakan oleh pengembang Prometheus. Kami melihat korelasinya dan menyadari bahwa kami tidak ingin membayar beberapa juta untuk sebuah server hanya untuk pemantauan.
Kami tidak hanya menambah jumlah mesin, kami juga memantau mesin virtual itu sendiri. Oleh karena itu, semakin banyak mesin virtual, semakin banyak berbagai jenis metrik, dll. Kami akan memiliki pertumbuhan khusus dalam cluster kami dalam hal metrik.
Dengan ruang disk, tidak semuanya buruk di sini, tapi saya ingin memperbaikinya. Kami menerima total 15 gigabyte dalam 120 hari, 100 di antaranya adalah data terkompresi, 20 data tidak terkompresi, namun kami selalu menginginkan lebih sedikit.
Oleh karena itu, kami menuliskan satu hal lagi - ini adalah konsumsi sumber daya yang besar, yang masih ingin kami hemat, karena kami tidak ingin cluster pemantauan kami mengkonsumsi lebih banyak sumber daya daripada cluster kami, yang mengelola OpenStack.
Ada satu lagi kelemahan Prometheus, yang telah kami identifikasi sendiri, ini setidaknya semacam keterbatasan memori. Dengan Prometheus, semuanya jauh lebih buruk di sini, karena tidak ada perubahan sama sekali. Menggunakan batasan di buruh pelabuhan juga bukan suatu pilihan. Kalau tiba-tiba RAF anda turun dan ada 20-30 gigabyte, maka butuh waktu lama untuk naik.
Ini adalah alasan lain mengapa Prometheus tidak cocok untuk kita, yaitu kita tidak dapat membatasi konsumsi memori.
Skema seperti itu bisa saja dibuat. Kami membutuhkan skema ini untuk mengatur cluster HA. Kami ingin metrik kami selalu tersedia dan di mana saja, bahkan jika server yang menyimpan metrik ini mengalami gangguan. Oleh karena itu, kita harus membangun skema seperti itu.
Skema ini mengatakan bahwa kita akan mengalami duplikasi pecahan, dan karenanya, duplikasi biaya sumber daya yang dikonsumsi. Hal ini dapat ditingkatkan hampir secara horizontal, namun konsumsi sumber dayanya akan sangat besar.
Kekurangannya diurutkan dalam bentuk yang kami tulis sendiri:
- Memerlukan pengunggahan metrik secara eksternal.
- Konsumsi sumber daya yang tinggi.
- Tidak ada cara untuk membatasi konsumsi memori.
- Implementasi HA yang kompleks dan intensif sumber daya.
Bagi kami sendiri, kami memutuskan untuk beralih dari Prometheus sebagai fasilitas penyimpanan.
Kami telah mengidentifikasi persyaratan tambahan untuk diri kami sendiri yang kami perlukan. Ini:
- Ini adalah dukungan promql, karena banyak hal telah ditulis untuk Prometheus: pertanyaan, peringatan.
- Dan kemudian kita memiliki Grafana, yang sudah ditulis dengan cara yang persis sama untuk Prometheus sebagai backend. Saya tidak ingin menulis ulang dasbor.
- Kami ingin membangun arsitektur HA yang normal.
- Kami ingin mengurangi konsumsi sumber daya apa pun.
- Ada nuansa kecil lainnya. Kami tidak dapat menggunakan berbagai jenis sistem pengumpulan metrik cloud. Kami belum tahu apa saja yang termasuk dalam metrik ini. Dan karena apa pun bisa terbang ke sana, kami harus membatasi diri pada penempatan lokal.
Hanya ada sedikit pilihan. Kami mengumpulkan semua pengalaman yang kami miliki. Kami melihat halaman Prometheus di bagian integrasi, membaca banyak artikel, dan melihat apa yang ada di luar sana. Dan bagi kami sendiri, kami memilih VictoriaMetrics sebagai pengganti Prometheus.
Mengapa? Karena:
- Tahu promql.
- Ada arsitektur modular.
- Tidak memerlukan perubahan pada Grafana.
- Dan yang paling penting, kami mungkin akan menyediakan penyimpanan metrik dalam perusahaan kami sebagai sebuah layanan, jadi kami melihat terlebih dahulu berbagai jenis pembatasan sehingga pengguna dapat menggunakan semua sumber daya cluster dengan cara yang terbatas, karena ada kemungkinan bahwa itu akan multitenancy.
Mari kita buat perbandingan pertama. Kami mengambil Prometheus yang sama di dalam cluster, Prometheus eksternal masuk ke dalamnya. Tambahkan melalui remoteWrite VictoriaMetrics.
Saya akan segera membuat reservasi bahwa di sini kami melihat sedikit peningkatan konsumsi CPU dari VictoriaMetrics. Wiki VictoriaMetrics memberi tahu Anda parameter mana yang terbaik. Kami memeriksanya. Mereka telah mengurangi konsumsi CPU dengan sangat baik.
Dalam kasus kami, konsumsi memori Prometheus, yang terletak di cluster Kubernetes, tidak meningkat secara signifikan.
Kami membandingkan dua sumber data dari data yang sama. Di Prometheus kami melihat data hilang yang sama. Semuanya baik-baik saja di VictoriaMetrics.
Hasil tes ruang disk. Kami di Prometheus menerima total 120 gigabyte. Di VictoriaMetrics kami sudah menerima 4 gigabyte per hari. Ada mekanisme yang sedikit berbeda dari yang biasa kita lihat di Prometheus. Artinya, data sudah terkompresi cukup baik dalam sehari, dalam waktu setengah jam. Sudah dituai dengan baik dalam sehari, dalam waktu setengah jam, meski nanti datanya masih hilang. Hasilnya, kami menghemat ruang disk.
Kami juga menghemat konsumsi sumber daya memori. Pada saat pengujian, kami menerapkan Prometheus pada mesin virtual - 8 core, 24 gigabyte. Prometheus makan hampir semuanya. Dia jatuh pada OOM Killer. Pada saat yang sama, hanya 900 metrik aktif yang dimasukkan ke dalamnya. Ini adalah sekitar 000-25 metrik per detik.
Kami menjalankan VictoriaMetrics pada mesin virtual dual-core dengan RAM 8 gigabyte. Kami berhasil membuat VictoriaMetrics berfungsi dengan baik dengan mengutak-atik beberapa hal pada mesin 8GB. Pada akhirnya, kami menyimpannya hingga 7 gigabyte. Pada saat yang sama, kecepatan pengiriman konten, yaitu metrik, bahkan lebih tinggi daripada Prometheus.
CPU menjadi jauh lebih baik dibandingkan dengan Prometheus. Di sini Prometheus menggunakan 2,5 core, dan VictoriaMetrics hanya menggunakan 0,25 core. Pada awalnya - 0,5 core. Saat menyatu, ia mencapai satu inti, tetapi ini sangat, sangat jarang terjadi.
Dalam kasus kami, pilihan jatuh pada VictoriaMetrics karena alasan yang jelas; kami ingin menghemat uang dan kami melakukannya.
Mari kita coret dua poin sekaligus - pengunggahan metrik dan konsumsi sumber daya yang tinggi. Dan kami hanya perlu memutuskan dua poin yang masih tersisa untuk diri kami sendiri.
Di sini saya akan segera melakukan reservasi, kami menganggap VictoriaMetrics sebagai penyimpanan metrik. Namun karena kemungkinan besar kami akan menyediakan VictoriaMetrics sebagai penyimpanan untuk seluruh Leroy, kami perlu membatasi mereka yang akan menggunakan cluster ini agar mereka tidak memberikannya kepada kami.
Ada parameter luar biasa yang memungkinkan Anda membatasi berdasarkan waktu, volume data, dan waktu eksekusi.
Ada juga opsi luar biasa yang memungkinkan kita membatasi konsumsi memori, sehingga kita dapat menemukan keseimbangan yang memungkinkan kita mendapatkan kecepatan pengoperasian normal dan konsumsi sumber daya yang memadai.
Minus satu poin lagi, yaitu coret poinnya - Anda tidak dapat membatasi konsumsi memori.
Pada iterasi pertama, kami menguji VictoriaMetrics Single Node. Selanjutnya kita beralih ke Versi Cluster VictoriaMetrics.
Di sini kami mempunyai kebebasan untuk memisahkan berbagai layanan di VictoriaMetrics bergantung pada apa yang akan dijalankan dan sumber daya apa yang akan digunakan. Ini adalah solusi yang sangat fleksibel dan nyaman. Kami menggunakan ini pada diri kami sendiri.
Komponen utama Versi Cluster VictoriaMetrics adalah vmstsorage. Jumlahnya bisa sebanyak N. Dalam kasus kami sejauh ini ada 2 di antaranya.
Dan ada vminsert. Ini adalah server proxy yang memungkinkan kami untuk: mengatur sharding di antara semua penyimpanan yang kami ceritakan, dan juga memungkinkan replika, yaitu Anda akan memiliki sharding dan replika.
Vminsert mendukung protokol OpenTSDB, Graphite, InfluxDB dan remoteWrite dari Prometheus.
Ada juga vmselect. Tugas utamanya adalah pergi ke vmstorage, menerima data dari mereka, menghapus duplikat data ini dan memberikannya kepada klien.
Ada hal luar biasa yang disebut vmagent. Kami sangat menyukainya. Ini memungkinkan Anda untuk mengonfigurasi persis seperti Prometheus dan tetap melakukan semuanya persis seperti Prometheus. Artinya, ia mengumpulkan metrik dari berbagai entitas dan layanan dan mengirimkannya ke vminsert. Maka semuanya tergantung pada Anda.
Layanan hebat lainnya adalah vmalert, yang memungkinkan Anda menggunakan VictoriaMetrics sebagai backend, menerima data yang diproses dari vminsert dan mengirimkannya ke vmselect. Ini memproses peringatan itu sendiri, serta aturannya. Dalam hal peringatan, kami menerima peringatan melalui alertmanager.
Ada komponen wmauth. Kami mungkin atau mungkin tidak (kami belum memutuskan hal ini) menggunakannya sebagai sistem otorisasi untuk cluster versi multitenancy. Ini mendukung remoteWrite untuk Prometheus dan dapat mengotorisasi berdasarkan url, atau lebih tepatnya bagian kedua, di mana Anda bisa atau tidak bisa menulis.
Ada juga vmbackup, vmrestore. Ini pada dasarnya adalah pemulihan dan pencadangan semua data. Dapat melakukan S3, GCS, file.
Iterasi pertama cluster kami dilakukan selama karantina. Pada saat itu, belum ada replika, jadi iterasi kami terdiri dari dua cluster yang berbeda dan independen tempat kami menerima data melalui remoteWrite.
Di sini saya akan membuat reservasi bahwa ketika kita beralih dari VictoriaMetrics Single Node ke VictoriaMetrics Cluster Version, kita masih tetap menggunakan sumber daya yang sama, yaitu yang utama adalah memori. Ini kira-kira bagaimana data kami, yaitu konsumsi sumber daya, didistribusikan.
Replika telah ditambahkan di sini. Kami menggabungkan semua ini menjadi satu cluster yang relatif besar. Semua data kami dipecah dan direplikasi.
Seluruh cluster memiliki N titik masuk, yaitu Prometheus dapat menambahkan data melalui HAPROXY. Di sini kita memiliki titik masuk ini. Dan melalui entry point ini Anda dapat login dari Grafana.
Dalam kasus kami, HAPROXY adalah satu-satunya port yang memproksi pemilihan, penyisipan, dan layanan lain di dalam cluster ini. Dalam kasus kami, tidak mungkin membuat satu alamat; kami harus membuat beberapa titik masuk, karena mesin virtual tempat cluster VictoriaMetrics berjalan terletak di zona berbeda dari penyedia cloud yang sama, yaitu bukan di dalam cloud kami, tetapi di luar .
Kami telah memperingatkan. Kami menggunakannya. Kami menggunakan alertmanager dari Prometheus. Kami menggunakan Opsgenie dan Telegram sebagai saluran pengiriman peringatan. Di Telegram mereka masuk dari dev, mungkin sesuatu dari prod, tapi sebagian besar sesuatu yang bersifat statistik, dibutuhkan oleh para insinyur. Dan Opsgenie sangat penting. Ini adalah panggilan, manajemen insiden.
Pertanyaan abadi: “Siapa yang memantau pemantauan?” Dalam kasus kami, monitoring memantau pemantauan itu sendiri, karena kami menggunakan vmagent pada setiap node. Dan karena node kami didistribusikan ke berbagai pusat data dari penyedia yang sama, setiap pusat data memiliki salurannya sendiri, mereka independen, dan bahkan jika otak terpecah tiba, kami masih akan menerima peringatan. Ya, akan ada lebih banyak peringatan, tetapi lebih baik menerima lebih banyak peringatan daripada tidak sama sekali.
Kami mengakhiri daftar kami dengan implementasi HA.
Dan selanjutnya saya ingin mencatat pengalaman berkomunikasi dengan komunitas VictoriaMetrics. Ternyata sangat positif. Orang-orangnya responsif. Mereka mencoba mendalami setiap kasus yang ditawarkan.
Saya memulai masalah di GitHub. Masalah-masalah tersebut diselesaikan dengan sangat cepat. Ada beberapa masalah lagi yang belum sepenuhnya terselesaikan, tetapi saya sudah dapat melihat dari kode bahwa pekerjaan ke arah ini sedang berlangsung.
Masalah utama bagi saya selama iterasi adalah jika saya mematikan sebuah node, maka selama 30 detik pertama vminsert tidak dapat memahami bahwa tidak ada backend. Hal ini kini telah diputuskan. Dan dalam satu atau dua detik, data diambil dari semua node yang tersisa, dan permintaan berhenti menunggu node yang hilang tersebut.
Pada titik tertentu kami ingin VictoriaMetrics menjadi operator VictoriaMetrics. Kami menunggunya. Kami sekarang secara aktif membangun kerangka kerja bagi operator VictoriaMetrics untuk mengambil semua aturan pra-perhitungan, dll. Prometheus, karena kami cukup aktif menggunakan aturan yang disertakan dengan operator Prometheus.
Ada usulan untuk meningkatkan implementasi cluster. Saya menguraikannya di atas.
Dan saya benar-benar ingin melakukan downsample. Dalam kasus kami, downsampling diperlukan hanya untuk melihat tren. Secara kasar, satu metrik sudah cukup bagi saya sepanjang hari. Tren ini diperlukan untuk satu tahun, tiga, lima, sepuluh tahun. Dan satu nilai metrik sudah cukup.
- Kami telah merasakan rasa sakit, seperti halnya beberapa rekan kami, saat menggunakan Prometheus.
- Kami memilih VictoriaMetrics untuk diri kami sendiri.
- Skalanya cukup baik baik secara vertikal maupun horizontal.
- Kita dapat mendistribusikan komponen yang berbeda ke jumlah node yang berbeda di cluster, membatasinya berdasarkan memori, menambah memori, dll.
Kami akan menggunakan VictoriaMetrics di rumah karena kami sangat menyukainya. Inilah yang telah terjadi dan telah terjadi.
Beberapa kode QR untuk obrolan VictoriaMetrics, kontak saya, radar teknis LeroyMerlin.
Sumber: www.habr.com