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
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
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
# 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:8428Option 2: Use vmagent Instead of Prometheus
vmagent is a lightweight metrics agent that replaces Prometheus:
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:
# 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 * 100Key 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 secondsScale
Single node VictoriaMetrics benchmarks:
- 10M+ active time series
- 1M+ data points/second ingestion
- Years of retention
- Used by Adidas, Cloudflare, GrammarlyVictoriaMetrics 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 — 16.7K+ ⭐ | Apache-2.0
- 官网: victoriametrics.com