# VictoriaMetrics — Fast Cost-Effective Time Series Database

> VictoriaMetrics is a fast, cost-effective, and scalable monitoring solution and time series database. Drop-in Prometheus replacement with 7x better compression and scale to billions of metrics.

## Install

Save as a script file and run:

## Quick Use

```bash
# Single-node (all-in-one)
docker run -d --name victoriametrics 
  -p 8428:8428 
  -v vm-data:/victoria-metrics-data 
  victoriametrics/victoria-metrics:latest
```

Open `http://localhost:8428` — Prometheus-compatible API ready at /api/v1/query.

## Intro

**VictoriaMetrics** is a fast, cost-effective, and scalable open-source time series database and monitoring solution. Designed as a drop-in replacement for Prometheus, it offers significantly better performance, compression (7-10x), and horizontal scalability — handling billions of active time series on a single node.

With 16.7K+ GitHub stars and Apache-2.0 license, VictoriaMetrics has become a popular choice for teams that have outgrown Prometheus' single-node limitations or need more cost-efficient long-term metrics storage.

## What VictoriaMetrics Does

- **TSDB**: High-performance time series database optimized for metrics
- **Prometheus Compatible**: Drop-in replacement, supports PromQL + MetricsQL extensions
- **High Compression**: 7-10x better than Prometheus, uses Gorilla-like compression
- **Horizontal Scaling**: Cluster mode with sharding and replication
- **Long-term Storage**: Designed for years of metrics retention
- **Ingest Formats**: Prometheus, InfluxDB, Graphite, OpenTSDB, DataDog, JSON
- **vmagent**: Lightweight metrics collector and relay
- **vmalert**: Alerting evaluator compatible with Prometheus alert rules
- **Grafana Integration**: Works seamlessly as Prometheus data source

## Architecture

### Single Node

```
┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│  Prometheus  │     │ VictoriaMet  │     │  Local       │
│  /vmagent/   │────▶│ single-node  │────▶│  Storage     │
│  OTel        │     │  (VMSingle)  │     │  (SSD/HDD)   │
└──────────────┘     └──────────────┘     └──────────────┘
```

### Cluster (HA + Scale)

```
┌──────────────┐
│  vminsert    │ ← Load balance writes
│  (Router)    │
└──────┬───────┘
       │ Consistent Hashing
       │
   ┌───┴──────────────┐
   │                  │
┌──┴────┐  ┌────┐  ┌─┴───┐
│vmstorage│  │... │  │vmstorage│  ← Horizontally scaled
└─────────┘  └────┘  └────────┘
   │                  │
   └──────┬───────────┘
          │
   ┌──────┴───────┐
   │  vmselect    │ ← Query engine
   │  (Reader)    │
   └──────────────┘
```

## Self-Hosting

### Single Node Docker

```yaml
services:
  victoriametrics:
    image: victoriametrics/victoria-metrics:latest
    ports:
      - "8428:8428"
    volumes:
      - vm-data:/victoria-metrics-data
    command:
      - "--storageDataPath=/victoria-metrics-data"
      - "--retentionPeriod=12"  # months
      - "--httpListenAddr=:8428"
    restart: unless-stopped

volumes:
  vm-data:
```

### Cluster Mode

```yaml
services:
  vminsert-1:
    image: victoriametrics/vminsert:latest
    ports:
      - "8480:8480"
    command:
      - "--storageNode=vmstorage-1:8400"
      - "--storageNode=vmstorage-2:8400"
      - "--storageNode=vmstorage-3:8400"

  vmstorage-1:
    image: victoriametrics/vmstorage:latest
    volumes:
      - vm-storage-1:/storage
    command:
      - "--storageDataPath=/storage"

  vmstorage-2:
    image: victoriametrics/vmstorage:latest
    volumes:
      - vm-storage-2:/storage
    command:
      - "--storageDataPath=/storage"

  vmstorage-3:
    image: victoriametrics/vmstorage:latest
    volumes:
      - vm-storage-3:/storage
    command:
      - "--storageDataPath=/storage"

  vmselect:
    image: victoriametrics/vmselect:latest
    ports:
      - "8481:8481"
    command:
      - "--storageNode=vmstorage-1:8401"
      - "--storageNode=vmstorage-2:8401"
      - "--storageNode=vmstorage-3:8401"

volumes:
  vm-storage-1:
  vm-storage-2:
  vm-storage-3:
```

## Prometheus Migration

### Option 1: Drop-in Replacement

```yaml
# Change Prometheus remote_write to VictoriaMetrics
remote_write:
  - url: http://victoriametrics:8428/api/v1/write

# Or configure Grafana to use VictoriaMetrics as Prometheus datasource
# URL: http://victoriametrics:8428
```

### Option 2: Use vmagent Instead of Prometheus

vmagent is a lightweight metrics agent that replaces Prometheus:

```yaml
services:
  vmagent:
    image: victoriametrics/vmagent:latest
    ports:
      - "8429:8429"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - vmagent-data:/vmagent-remotewrite-data
    command:
      - "--promscrape.config=/etc/prometheus/prometheus.yml"
      - "--remoteWrite.url=http://victoriametrics:8428/api/v1/write"
```

vmagent uses 10x less RAM than Prometheus while providing the same scraping functionality.

## MetricsQL Extensions

VictoriaMetrics supports PromQL plus useful extensions:

```promql
# Prometheus PromQL (works as-is)
rate(http_requests_total[5m])

# MetricsQL extensions:

# Default value for missing metrics
default_rollup(http_requests_total[5m]) default 0

# Rollup functions (more powerful than PromQL)
rollup_rate(http_requests_total[5m])  # Returns min, max, avg

# Keep metric name through operations
keep_metric_names(rate(http_requests_total[5m]))

# Label filters with regex
http_requests_total{status=~"5..", path!~"^/health"}

# WITH templates for reusable queries
WITH (
  requests = rate(http_requests_total[5m]),
  errors = rate(http_requests_total{status=~"5.."}[5m])
)
errors / requests * 100
```

## Key Benefits

### Compression

```
100M active time series, 1-year retention:

Prometheus:
  - Disk usage: ~500GB
  - RAM usage: ~64GB

VictoriaMetrics:
  - Disk usage: ~50GB (10x less)
  - RAM usage: ~8GB (8x less)
```

### Query Performance

```
Query: 10M data points aggregation

Prometheus:  8-12 seconds
VictoriaMetrics: 0.5-2 seconds
```

### Scale

```
Single node VictoriaMetrics benchmarks:
- 10M+ active time series
- 1M+ data points/second ingestion
- Years of retention
- Used by Adidas, Cloudflare, Grammarly
```

## VictoriaMetrics vs Alternatives

| Feature | VictoriaMetrics | Prometheus | InfluxDB | TimescaleDB |
|---------|----------------|-----------|----------|-------------|
| Open Source | Yes (Apache-2.0) | Yes | Partial | Yes |
| PromQL | Yes + MetricsQL | Yes | InfluxQL/Flux | SQL |
| Compression | 7-10x | Baseline | Good | Good |
| Horizontal scale | Yes (cluster) | Federation | Enterprise | Distributed (paid) |
| Long-term storage | Native | Via Thanos/Cortex | Native | Native |
| Ingestion protocols | 6+ | Pull-based | HTTP API | SQL |
| Resource usage | Very low | Moderate | Moderate | PostgreSQL-based |

## 常见问题

**Q: VictoriaMetrics 能完全替代 Prometheus 吗？**
A: 作为存储后端可以完全替代，使用 vmagent 代替 Prometheus scraping，使用 vmalert 代替 Alertmanager。一些高级功能（如服务发现某些细节）仍建议用 Prometheus + 远程写入到 VictoriaMetrics。

**Q: 什么时候需要集群模式？**
A: 单节点已经可以处理 10M 活跃时间序列（数百台服务器的指标）。只有当需要 HA 或超过单节点容量时才需要集群模式。集群模式运维复杂度显著增加。

**Q: 和 Thanos/Cortex 相比？**
A: Thanos 和 Cortex 是为 Prometheus 添加长期存储和水平扩展的方案。VictoriaMetrics 是原生为这些场景设计的，性能更好、资源消耗更低、运维更简单。新项目推荐直接用 VictoriaMetrics。

## 来源与致谢

- GitHub: [VictoriaMetrics/VictoriaMetrics](https://github.com/VictoriaMetrics/VictoriaMetrics) — 16.7K+ ⭐ | Apache-2.0
- 官网: [victoriametrics.com](https://victoriametrics.com)

---
Source: https://tokrepo.com/en/workflows/ca380c82-353d-11f1-9bc6-00163e2b0d79
Author: Script Depot