Spotify needed to replace its legacy in-house time series database to overcome stability and performance limitations, which would bring about query delays and timeouts. The Spotify observability team chose VictoriaMetrics to support efficient metric ingestion, querying, and alerting at scale.
When evaluating, instant vectors provide current snapshots, while range vectors give you multiple values over a period of time. But how do they work?
Metrics come in different types: counters that only increase, gauges that fluctuate, histograms that show value distributions, and summaries that pre-calculate statistics.
OpenTelemetry, Prometheus 2.x, Prometheus 3.x, and vmagent are put together for comparison in scraping and pushing data to remote storage.
I have already recorded metrics in the application, why can’t I see my metrics on Grafana?
Monitoring Proxmox hypervisor via VictoriaMetrics and Proxmox’s built-in metric server
One of the latest benchmarks we made was ‘VictoriaMetrics: scaling to 100 million metrics per second’. While the fact of such scale for VictoriaMetrics is noteworthy on its own, the benchmark tool used to generate that load is usually overlooked. In this blog post I’ll explain in more details the challenge of running such benchmarks.
Benchmarking VictoriaMetrics and Grafana Mimir on the same hardware
VictoriaMetrics has new production ready builds for ARM