Why VictoriaMetrics Is the Fast, Cost‑Effective Alternative to Prometheus for Time‑Series Monitoring

Introduction

Last time we switched from Docker to containerd as the CRI, and now we also replace the monitoring stack. Previously we used Prometheus for data collection, storage and query, Alertmanager for alerts, and Grafana for visualization. Now we choose OpenTelemetry and VictoriaMetrics; this article introduces VictoriaMetrics.

Note: VictoriaMetrics will be abbreviated as vm.

Overview

What is VM

From the official description:

<code>VictoriaMetrics is a fast, cost-effective and scalable monitoring solution 
and time series database</code>

In other words, vm is a fast, practical and scalable monitoring solution and time‑series database. Consider that Prometheus is also a time‑series database; how do they differ?

VM Features

VM has many features; here are a few examples:

Can serve as a long‑term storage solution for Prometheus, extending retention beyond the default 15‑day limit.

When using Grafana, the Prometheus data source can be replaced by vm because vm supports the Prometheus query API.

Implements MetricsQL, an enhanced version of PromQL.

Consumes less memory than Thanos or Prometheus when handling millions of series.

…

VM Components

What components does vm have and what does its (cluster) architecture look like?

Main components:

vmstorage stores time‑series data and provides queries.

vmselect retrieves data from vmstorage and serves it to clients, supporting PromQL.

vminsert writes data to vmstorage via the remote‑write API.

Other components:

vmui provides a UI for querying data and troubleshooting.

vmalert for alerting.

vmagent for data collection.

vmbackup for backups.

vmrestore for restoration.

…

VM Installation Considerations

vm can be installed via binary, Docker image, or source code. In Kubernetes you can use the operator. Below are key installation notes.

A minimal cluster must include:

One vmstorage node (specify -retentionPeriod and -storageDataPath).

One vminsert node (specify -storageNode=<vmstorage_host>).

One vmselect node (specify -storageNode=<vmstorage_host>).

Note: In high‑availability setups, each service should have at least two nodes.

Place a load balancer (e.g., vmauth, nginx) in front of vmselect and vminsert, ensuring:

Requests starting with /insert are routed to the vminsert node on port 8480.

Requests starting with /select are routed to the vmselect node on port 8481.

Ports can be set with -httpListenAddr.

Additional recommendations:

Install monitoring for the cluster.

When testing on a single host, ensure each of vminsert, vmselect, and vmstorage has unique -httpListenAddr values, and unique -storageDataPath, -vminsertAddr, -vmselectAddr.

If vmstorage’s -storageDataPath falls below the free‑disk threshold set by -storage.minFreeDiskSpaceBytes, it switches to read‑only mode; vminsert then stops sending data to that node and redirects to other available vmstorage nodes.