4 ms·
> given Prometheus’s widespread adoption and proven reliability in diverse environments. I have used Prometheus a lot. Reliable is not a word I would associat
by codeduck 6mo ago
> given Prometheus’s widespread adoption and proven reliability in diverse environments.
I have used Prometheus a lot. Reliable is not a word I would associate with it.
- hagen1778 6mo agoWhat do you use instead of Prometheus?
- codeduck 6mo agoGiven a choice, VictoriaMetrics. It has proven itself time and time again at scale, and requires a very low support investment.
- pahae 6mo agoI set up a fairly large Prom-based architecture which I later on migrated to VictoriaMetrics (VM) so I think I can chime in here. Both Prom and VM are exceptionally stable in my opinion, even on _very_ large scales. There were times when I had a single (Prom, later VM) and not-overly-large instances scrape 2Mio samples/s without any issues. In addition to fairly spiky query loads. However, if something does go wrong, the single most impactful difference between VM and Prom is simply the difference in startup time. Prometheus with 2TB of metrics takes _forever_ to start up. We're talking up to 2 hours on SSD while VM just... starts.
- Serhii-Set 6mo ago[dead]
- porridgeraisin 6mo agoYeah, at previous work we used both as well. The transition from prom to vm was "ongoing" and from the time I joined to the time I left we did parallel writes to both. Never faced issues with either. If I remember correctly, we wrote from services to a kafka queue first, and then a consumer took that and pushed it to (both) the metrics endpoint(s).
- Serhii-Set 6mo ago[dead]