How to Install VictoriaMetrics as a Prometheus Alternative on RHEL 7

Prometheus has become the de-facto standard for metrics collection in Linux environments, but it is not the only option. VictoriaMetrics is a high-performance, cost-efficient time-series database that is fully compatible with PromQL, accepts Prometheus remote_write, and offers significant advantages in storage compression, ingestion throughput, and memory usage. A single-node VictoriaMetrics binary can replace or complement an existing Prometheus setup without requiring changes to your dashboards or alerting rules. This tutorial covers the full installation of single-node VictoriaMetrics on RHEL 7, migration of Prometheus scrape targets to vmagent, Grafana integration, and an overview of MetricsQL extensions.

Prerequisites

• RHEL 7 server with at least 2 GB RAM and 20 GB disk space for metrics storage
• Root or sudo access
• An existing Prometheus instance (optional, for remote_write migration)
• Grafana installed (for dashboard integration)
• Port 8428 available for VictoriaMetrics, port 8429 for vmagent

Step 1: Download the VictoriaMetrics Binary

VictoriaMetrics provides pre-built static binaries for Linux. Download the single-node release directly from GitHub:

cd /tmp
curl -LO https://github.com/VictoriaMetrics/VictoriaMetrics/releases/download/v1.101.0/victoria-metrics-linux-amd64-v1.101.0.tar.gz
tar xzf victoria-metrics-linux-amd64-v1.101.0.tar.gz

Install the binary and create the required directory structure:

cp victoria-metrics-prod /usr/local/bin/victoria-metrics
chmod 755 /usr/local/bin/victoria-metrics

useradd --no-create-home --shell /sbin/nologin victoriametrics

mkdir -p /etc/victoria-metrics
mkdir -p /var/lib/victoria-metrics/data
chown -R victoriametrics:victoriametrics /var/lib/victoria-metrics /etc/victoria-metrics

Step 2: Create the Systemd Service

Create a systemd unit file with recommended production flags for storage retention and memory limits:

cat > /etc/systemd/system/victoria-metrics.service << 'EOF'
[Unit]
Description=VictoriaMetrics Time Series Database
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
User=victoriametrics
Group=victoriametrics
ExecStart=/usr/local/bin/victoria-metrics 
  -storageDataPath=/var/lib/victoria-metrics/data 
  -retentionPeriod=12 
  -httpListenAddr=0.0.0.0:8428 
  -maxInsertRequestSize=32MB 
  -search.maxQueryDuration=60s 
  -search.maxConcurrentRequests=16
Restart=on-failure
RestartSec=5s
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target
EOF

The -retentionPeriod=12 flag sets 12-month retention. VictoriaMetrics uses far less disk than Prometheus for the same period due to its proprietary compression algorithm. Enable and start the service:

systemctl daemon-reload
systemctl enable victoria-metrics
systemctl start victoria-metrics
systemctl status victoria-metrics

Open the firewall port:

firewall-cmd --permanent --add-port=8428/tcp
firewall-cmd --reload

Step 3: Configure Prometheus remote_write

If you want to keep using Prometheus for scraping but store data in VictoriaMetrics, configure Prometheus to forward all scraped metrics via remote_write. Edit /etc/prometheus/prometheus.yml:

remote_write:
  - url: http://localhost:8428/api/v1/write
    queue_config:
      capacity: 10000
      max_samples_per_send: 5000
      batch_send_deadline: 5s
      max_shards: 10
      min_shards: 2
      max_retries: 3
    write_relabel_configs:
      - source_labels: [__name__]
        regex: 'go_.*'
        action: drop

Reload Prometheus:

curl -X POST http://localhost:9090/-/reload

Verify data is arriving in VictoriaMetrics by querying the built-in metrics endpoint:

curl http://localhost:8428/metrics | grep vm_rows_inserted_total

Step 4: Install vmagent as a Prometheus Replacement Scraper

The vmagent component replaces Prometheus entirely for scraping, offering lower memory usage and the ability to replicate metrics to multiple remote storage systems simultaneously. Download vmagent:

cd /tmp
curl -LO https://github.com/VictoriaMetrics/VictoriaMetrics/releases/download/v1.101.0/vmutils-linux-amd64-v1.101.0.tar.gz
tar xzf vmutils-linux-amd64-v1.101.0.tar.gz
cp vmagent-prod /usr/local/bin/vmagent
chmod 755 /usr/local/bin/vmagent

Create the vmagent systemd service. It reuses your existing Prometheus prometheus.yml scrape config:

cat > /etc/systemd/system/vmagent.service << 'EOF'
[Unit]
Description=VictoriaMetrics vmagent
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
User=victoriametrics
Group=victoriametrics
ExecStart=/usr/local/bin/vmagent 
  -promscrape.config=/etc/prometheus/prometheus.yml 
  -remoteWrite.url=http://localhost:8428/api/v1/write 
  -remoteWrite.tmpDataPath=/var/lib/victoria-metrics/vmagent-tmp 
  -httpListenAddr=0.0.0.0:8429
Restart=on-failure

[Install]
WantedBy=multi-user.target
EOF

mkdir -p /var/lib/victoria-metrics/vmagent-tmp
chown victoriametrics:victoriametrics /var/lib/victoria-metrics/vmagent-tmp

systemctl daemon-reload
systemctl enable vmagent
systemctl start vmagent

Step 5: Use vmui to Query Metrics

VictoriaMetrics ships with a built-in query UI called vmui. Access it at http://YOUR_SERVER:8428/vmui. vmui supports both PromQL and MetricsQL and provides query tracing, cardinality explorer, and metric explorer views.

From the command line, query using the standard Prometheus HTTP API endpoint that VictoriaMetrics fully implements:

# Instant query
curl 'http://localhost:8428/api/v1/query?query=up'

# Range query
curl 'http://localhost:8428/api/v1/query_range?query=rate(node_cpu_seconds_total[5m])&start=2h&end=now&step=60'

# Label names
curl 'http://localhost:8428/api/v1/labels'

Step 6: MetricsQL Differences from PromQL

MetricsQL is a superset of PromQL. All existing PromQL queries work unchanged. MetricsQL adds several useful extensions:

• Default rollup window: VictoriaMetrics automatically selects the window for rate() and similar functions based on the step interval, eliminating the need to manually specify [5m] or [1m] everywhere.
• keepLastValue: keep_last_value(metric) fills gaps with the last known value instead of returning NaN.
• Median aggregation: median(metric) works directly without the quantile(0.5, ...) workaround.
• WithTemplate: Reuse query fragments with WITH (alias = expr) alias * 2 to reduce duplication in complex queries.

# MetricsQL: no need to specify the window manually
rate(http_requests_total)

# Fill gaps in a metric
keep_last_value(up)

# Equivalent PromQL with explicit window required
rate(http_requests_total[5m])

Step 7: Add VictoriaMetrics as a Grafana Data Source

VictoriaMetrics exposes a fully Prometheus-compatible API, so configure it as a Prometheus data source in Grafana:

1. Open Grafana at http://YOUR_SERVER:3000
2. Go to Configuration → Data Sources → Add data source
3. Select Prometheus
4. Set URL to http://localhost:8428
5. Leave all other settings at defaults
6. Click Save & Test

All existing Grafana dashboards that used Prometheus will continue to work without modification.

Step 8: Storage Compression and Disk Usage

Check current storage usage and compression statistics:

# Storage metrics
curl -s http://localhost:8428/api/v1/query?query=vm_data_size_bytes | python -m json.tool

# Check the data directory size
du -sh /var/lib/victoria-metrics/data/

# View internal VictoriaMetrics metrics
curl http://localhost:8428/metrics | grep -E 'vm_rows|vm_data_size|vm_cache'

VictoriaMetrics typically achieves 5–10x better compression than Prometheus TSDB. A dataset that occupies 50 GB in Prometheus often fits in 6–10 GB in VictoriaMetrics under real-world conditions, primarily because VictoriaMetrics uses Gorilla-style delta-of-delta encoding combined with its own series index compression.

VictoriaMetrics is a compelling drop-in replacement for Prometheus in production RHEL 7 environments, offering substantially better storage efficiency, lower memory consumption, and a simpler operational profile. By forwarding Prometheus remote_write data or replacing the scraper entirely with vmagent, you can adopt VictoriaMetrics incrementally without breaking existing dashboards or alert rules. The vmui interface and MetricsQL extensions further enhance the querying experience. For small-to-medium environments a single node is sufficient; for larger scale the cluster edition adds horizontal scalability.