VictoriaMetrics vs Prometheus untuk Metrik Jangka Panjang

Prometheus adalah sistem monitoring pertama yang dipakai hampir setiap tim yang menjalankan Kubernetes atau sekumpulan server Linux. Ia melakukan scrape terhadap target, menyimpan sampel di basis data time series lokal, dan menjawab kueri PromQL dengan cepat. Masalah muncul saat ada yang bertanya hal sederhana: seperti apa metrik ini enam bulan lalu? Prometheus dirancang untuk monitoring operasional jangka pendek yang andal, bukan untuk menyimpan riwayat bertahun-tahun di disk murah.

VictoriaMetrics adalah basis data time series yang dibangun khusus untuk menutup celah itu. Ia berbicara protokol remote write Prometheus, menyerap data scrape yang sama, menjawab superset dari PromQL, dan menyimpan metrik yang sama dengan disk dan memori yang jauh lebih hemat. Artikel ini menelusuri perbedaan konkret yang penting untuk retensi jangka panjang, dan memberi jalur migrasi yang tetap mempertahankan Prometheus sampai Anda memercayai backend baru.

Mengapa Prometheus kesulitan dengan retensi panjang

Prometheus menyimpan data secara lokal dalam format TSDB miliknya sendiri. Dokumentasi penyimpanan resminya jelas menyatakan bahwa penyimpanan lokal tidak dimaksudkan sebagai penyimpanan jangka panjang yang tahan lama: dokumentasi itu menyarankan retensi yang moderat dan mendelegasikan riwayat jangka panjang ke sistem remote melalui API remote write. Tidak ada clustering bawaan, tidak ada replikasi, dan jejak on-disk tumbuh cepat begitu Anda memperpanjang retensi lebih dari beberapa minggu pada konfigurasi kardinalitas tinggi.

Mode kegagalan praktisnya adalah memori, bukan disk. Saat jumlah series aktif naik, penggunaan RAM Prometheus ikut naik, karena ia menyimpan chunk terbaru dan struktur indeks di memori. Tim yang mencoba menyimpan data setahun pada satu node Prometheus biasanya mengalami restart karena kehabisan memori jauh sebelum kehabisan disk. Itulah tembok yang dirancang untuk dihilangkan oleh VictoriaMetrics.

• Penyimpanan lokal Prometheus diposisikan untuk monitoring operasional, bukan arsip yang tahan lama, sesuai dokumentasi resmi.
• Riwayat jangka panjang diharapkan berada di sistem remote yang dijangkau melalui API remote write.
• Jumlah series aktif yang tinggi mendorong memori Prometheus naik, yang biasanya menjadi hal pertama yang rusak saat skala membesar.

Adu langsung pada hal-hal yang penting

Kedua sistem sangat mirip pada pengalaman hari pertama dan berbeda tajam begitu retensi dan kardinalitas tumbuh. Tabel ini merangkum perbedaan yang menentukan apakah Anda sebaiknya menyimpan semuanya di Prometheus atau menambahkan VictoriaMetrics sebagai penyimpan jangka panjang.

MetricsQL: PromQL dengan sudut tajam yang dihaluskan

VictoriaMetrics tidak memaksa Anda mempelajari bahasa baru. Ia mengimplementasikan MetricsQL, yang oleh dokumentasi digambarkan kompatibel mundur dengan PromQL untuk sebagian besar kueri sambil memperbaiki beberapa hal yang mengganggu. Dashboard Grafana dan aturan alert yang ada umumnya tetap berfungsi saat Anda mengarahkannya ke VictoriaMetrics menggunakan sumber data Prometheus standar.

MetricsQL menambahkan fitur kemudahan di atas PromQL. Anda mendapat jendela lookbehind default yang masuk akal sehingga bisa menghilangkan rentang eksplisit pada ekspresi rate umum, fungsi rollup yang mengembalikan beberapa agregasi dalam satu jalan, dan template WITH untuk menamai dan menggunakan ulang subekspresi. Ia bukan superset ketat, jadi segelintir perilaku PromQL kasus tepi berbeda, tetapi mayoritas dashboard nyata bermigrasi tanpa perubahan.

# PromQL: rate over a fixed window, verbose to read
rate(http_requests_total[5m])

# MetricsQL: same intent, plus conveniences PromQL lacks
# - default step interval, so [5m] can be omitted
rate(http_requests_total)

# - rollup functions return min/max/avg in one call
rollup_rate(http_requests_total[5m])

# - WITH templates let you name and reuse expressions
WITH (
  err = rate(http_requests_total{code=~"5.."})
)
err / rate(http_requests_total) * 100

Penggunaan sumber daya dan kardinalitas

Angka utama dari FAQ VictoriaMetrics adalah bahwa ia memakai kira-kira sepuluh kali lebih sedikit RAM dan menyimpan data dengan kompresi jauh lebih baik daripada Prometheus untuk beban setara. Angka itu bergantung pada bentuk data Anda, tetapi arahnya konsisten di berbagai benchmark independen: untuk series yang diserap sama, VictoriaMetrics menahan resident set lebih kecil dan menulis blok lebih kecil ke disk. Kompresinya berasal dari encoding berorientasi kolom dan teknik delta yang disetel untuk bentuk data monitoring sesungguhnya, tempat sebagian besar sampel nyaris tidak berubah dari satu scrape ke scrape berikutnya, sehingga biaya on-disk untuk riwayat setahun tetap terkendali bahkan pada server yang sederhana.

Kardinalitas adalah sumbu lainnya. Kumpulan label kardinalitas tinggi, seperti ID per-permintaan atau label per-container yang terus berganti, menghukum memori Prometheus dengan keras. VictoriaMetrics menangani series yang berganti-ganti dan kardinalitas tinggi dengan lebih anggun, yang membuatnya menjadi pilihan umum untuk armada Kubernetes besar tempat nama pod dan tag image menciptakan jutaan series berumur pendek.

Jalur migrasi yang aman

Migrasi paling minim risiko tetap menjalankan Prometheus dan menambahkan VictoriaMetrics di sampingnya sebagai penyimpan jangka panjang. Anda mencerminkan data langsung dengan remote write, mengisi riwayat dengan vmctl, dan baru memindahkan Grafana setelah memastikan backend baru menjawab dengan benar.

# prometheus.yml — send a live copy to VictoriaMetrics
remote_write:
  - url: http://victoriametrics:8428/api/v1/write

# Backfill historical Prometheus TSDB blocks with vmctl
vmctl prometheus \
  --prom-snapshot=/path/to/snapshot \
  --vm-addr=http://victoriametrics:8428

# Point Grafana at VictoriaMetrics using the Prometheus data source
# URL: http://victoriametrics:8428

1. Tambahkan blok remote_write ke prometheus.yml yang menunjuk ke endpoint tulis VictoriaMetrics, sehingga setiap sampel baru mendarat di kedua penyimpan sekaligus.
2. Isi riwayat yang ada dengan mengambil snapshot TSDB Prometheus dan mengimpornya menggunakan alat migrasi vmctl, sehingga VictoriaMetrics memegang seluruh linimasa, bukan hanya data sejak tanggal pemindahan.
3. Tambahkan VictoriaMetrics ke Grafana sebagai sumber data tipe Prometheus dan bangun ulang atau klon dashboard Anda terhadapnya, sambil memeriksa panel dan alert cocok dengan versi asli Prometheus.
4. Begitu angkanya sepakat, perpendek retensi lokal Prometheus menjadi beberapa hari dan biarkan VictoriaMetrics memiliki riwayat jangka panjang secara permanen.

Kapan Prometheus polos tetap pilihan yang tepat

VictoriaMetrics bukan pemutakhiran wajib. Bagi banyak tim, Prometheus biasa tetap pilihan yang lebih sederhana dan lebih baik, dan menambahkan komponen bergerak lain tidak sepadan.

• Anda hanya butuh retensi beberapa hari atau minggu dan satu node menampungnya dengan nyaman.
• Jumlah series dan kardinalitas Anda moderat, sehingga tekanan memori bukan masalah yang benar-benar Anda miliki.
• Anda lebih menghargai satu komponen yang terdokumentasi luas daripada memeras penghematan penyimpanan dan RAM yang belum Anda perlukan.

Intinya

Prometheus dan VictoriaMetrics sebenarnya bukan pesaing di titik pengumpulan; keduanya saling melengkapi. Prometheus tetap scraper dan penyimpan jangka pendek yang sangat baik, dan VictoriaMetrics masuk di belakangnya sebagai rumah yang tahan lama dan efisien untuk metrik jangka panjang. Karena ia berbicara remote write dan superset PromQL, peralihan bersifat menambah, bukan menulis ulang.

Jika tumpukan monitoring Anda mulai membentur batas memori, tagihan disk yang membengkak, atau penolakan tegas untuk menyimpan lebih dari beberapa minggu riwayat, VictoriaMetrics adalah langkah berikutnya yang pragmatis. Jalankan berdampingan, verifikasi MetricsQL terhadap dashboard nyata Anda, dan pindahkan hanya saat angkanya cocok. Biarkan pintu rollback tetap terbuka sampai Anda menyaksikan satu siklus retensi penuh berlalu dengan kedua backend sepakat. Begitulah cara mendapatkan metrik jangka panjang tanpa mempertaruhkan seluruh tumpukan observability pada satu migrasi.