2026-05-18 20:24 UTC
Replies (3)
-
@sushee@ohai.social 2026-05-18 20:26
@sean@scoat.es it's a full prometheus replacement, we migrated over 900 prometheus instances into back then 24 victoria clusters. it's painless because victoria understands prometheus config 1:1 and speaks promql fully so you keep practically everything as is
-
@sushee@ohai.social 2026-05-18 20:30
@sean@scoat.es you can also indeed use it (and we did in my previous job) as storage backend (remoteWrite) only and keep Prometheus as "frontend". Then you'll just deploy vminsert, vmselect and vmstorage and leave out vmagent architecture of victoria logs and victoria traces is almost the same ('but with logs" ;)) and all three come with v*alert.
-
@aln@floss.social 2026-05-20 09:45
@sean@scoat.es @sushee@ohai.social Not technically an alternative because Prometheus is not designed for long-term storage. The ideal time range is a few days, If you have auditing needs (30+ days), most shops will, you have to implement something else alongside Prometheus. Victoria Metrics and Grafana Mimir are designed specifically for long-term storage. I found Mimir to be great, especially if you have other Grafana stack tools running: Alloy, Loki, etc. Curious about IRL differences between VM and Mimir.