VictoriaMetrics: замена Prometheus для больших объёмов метрик

Prometheus — де-факто стандарт для сбора метрик. Но стоит нагрузке вырасти, и начинается: память жрёт всё подряд, долгосрочное хранение превращается в боль, про нативную кластеризацию вообще молчим. Мы через это прошли. VictoriaMetrics закрывает все три проблемы разом.

Что реально даёт VictoriaMetrics — по пунктам:

• Потребление памяти в 7-10 раз ниже, чем у Prometheus при том же объёме данных
• Сжатие данных на диске — до 70x по сравнению с Prometheus TSDB
• Полная совместимость с PromQL — плюс расширенный язык запросов MetricsQL с дополнительными функциями
• Долгосрочное хранение — годами держит данные без деградации производительности. Не месяцами — годами
• Кластерная версия — горизонтальное масштабирование прямо из коробки, без танцев с бубном
• Поддержка множества протоколов — Prometheus, InfluxDB, OpenTSDB, Graphite, DataDog. Всё это без дополнительных прослоек

VictoriaMetrics существует в двух вариантах. Single-node — один процесс, который закрывает потребности большинства инсталляций. Cluster — для петабайтных объёмов, когда single-node уже не справляется. На практике single-node тянет до миллиона метрик в секунду на одном сервере — этого хватает с запасом для 95% наших клиентов.

Ставим VictoriaMetrics single-node на Ubuntu 22.04. Если у вас до 10 миллионов активных таймсерий — этот вариант закроет все задачи, кластер не нужен.

# Скачиваем последнюю версию
VERSION=$(curl -s https://api.github.com/repos/VictoriaMetrics/VictoriaMetrics/releases/latest | grep tag_name | cut -d'"' -f4)
wget https://github.com/VictoriaMetrics/VictoriaMetrics/releases/download/${VERSION}/victoria-metrics-linux-amd64-${VERSION}.tar.gz

# Распаковываем
tar xzf victoria-metrics-linux-amd64-*.tar.gz
sudo mv victoria-metrics-prod /usr/local/bin/

# Создаём пользователя и каталоги
sudo useradd -r -s /bin/false victoriametrics
sudo mkdir -p /var/lib/victoriametrics /etc/victoriametrics
sudo chown victoriametrics:victoriametrics /var/lib/victoriametrics

Создаём systemd-юнит /etc/systemd/system/victoriametrics.service:

[Unit]
Description=VictoriaMetrics
After=network.target

[Service]
User=victoriametrics
Group=victoriametrics
ExecStart=/usr/local/bin/victoria-metrics-prod \
  -storageDataPath=/var/lib/victoriametrics \
  -retentionPeriod=12 \
  -httpListenAddr=:8428 \
  -selfScrapeInterval=15s \
  -memory.allowedPercent=60
Restart=always
RestartSec=5
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now victoriametrics

# Проверяем
curl http://localhost:8428/health
# должен вернуть "OK"

Хорошая новость: VictoriaMetrics отлично работает параллельно с Prometheus. Не нужно резать по живому — мигрируем постепенно. Первый шаг — настраиваем remote_write, чтобы Prometheus начал дублировать данные в VictoriaMetrics.

В /etc/prometheus/prometheus.yml добавьте:

remote_write:
  - url: http://victoriametrics:8428/api/v1/write
    queue_config:
      max_samples_per_send: 10000
      capacity: 20000
      max_shards: 30

С этого момента все метрики Prometheus идут и туда, и туда. Переключаем Grafana на VictoriaMetrics как источник данных:

1. В Grafana перейдите в Configuration → Data Sources
2. Добавьте новый источник типа Prometheus — VictoriaMetrics полностью совместима с этим типом
3. URL: http://victoriametrics:8428
4. Сохраните и переключите дашборды на новый источник. Запросы работают без изменений

Убедились, что всё работает? Тогда можно идти дальше — убираем Prometheus из цепочки и ставим вместо него vmagent для скрапинга. Он легче, быстрее и потребляет в разы меньше памяти.

# vmagent полностью совместим с конфигурацией Prometheus
wget https://github.com/VictoriaMetrics/VictoriaMetrics/releases/download/${VERSION}/vmutils-linux-amd64-${VERSION}.tar.gz
tar xzf vmutils-linux-amd64-*.tar.gz
sudo mv vmagent-prod /usr/local/bin/

Systemd-юнит для vmagent:

[Unit]
Description=VictoriaMetrics Agent
After=network.target

[Service]
User=victoriametrics
ExecStart=/usr/local/bin/vmagent-prod \
  -promscrape.config=/etc/victoriametrics/scrape.yml \
  -remoteWrite.url=http://localhost:8428/api/v1/write \
  -remoteWrite.tmpDataPath=/var/lib/vmagent
Restart=always

[Install]
WantedBy=multi-user.target

Формат конфигурации vmagent полностью совместим с prometheus.yml — копируете почти без правок. Вот пример /etc/victoriametrics/scrape.yml для типичной инфраструктуры:

global:
  scrape_interval: 30s
  scrape_timeout: 10s

scrape_configs:
  - job_name: 'node-exporter'
    static_configs:
      - targets:
          - 'web-01:9100'
          - 'web-02:9100'
          - 'db-01:9100'
          - 'db-02:9100'
    relabel_configs:
      - source_labels: [__address__]
        regex: '(.+):.*'
        target_label: instance
        replacement: '$1'

  - job_name: 'mysql-exporter'
    static_configs:
      - targets: ['db-01:9104', 'db-02:9104']

  - job_name: 'nginx-exporter'
    static_configs:
      - targets: ['web-01:9113', 'web-02:9113']

  - job_name: 'blackbox-http'
    metrics_path: /probe
    params:
      module: [http_2xx]
    static_configs:
      - targets:
          - https://company.ru
          - https://api.company.ru
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: blackbox:9115

Service discovery для Kubernetes, Consul, EC2, DNS и других систем в vmagent настраивается точно так же, как в Prometheus. Если уже есть рабочий конфиг — просто переносите.

С алертами тоже всё продумано. В составе VictoriaMetrics есть vmalert — работает с правилами Prometheus без переписывания, уведомления шлёт через Alertmanager.

sudo mv vmalert-prod /usr/local/bin/

Конфигурация /etc/victoriametrics/alerts.yml:

groups:
  - name: infrastructure
    interval: 30s
    rules:
      - alert: HighCPUUsage
        expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 85
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "Высокая нагрузка CPU на {{ $labels.instance }}"
          description: "CPU загружен на {{ $value | printf \"%.1f\" }}% более 10 минут."

      - alert: DiskSpaceLow
        expr: (node_filesystem_avail_bytes{fstype!~"tmpfs|overlay"} / node_filesystem_size_bytes) * 100 < 10
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Мало места на диске {{ $labels.instance }}:{{ $labels.mountpoint }}"
          description: "Осталось {{ $value | printf \"%.1f\" }}% свободного места."

      - alert: ServiceDown
        expr: up == 0
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Сервис недоступен: {{ $labels.job }} на {{ $labels.instance }}"

Запуск vmalert:

/usr/local/bin/vmalert-prod \
  -datasource.url=http://localhost:8428 \
  -remoteRead.url=http://localhost:8428 \
  -remoteWrite.url=http://localhost:8428 \
  -notifier.url=http://alertmanager:9093 \
  -rule="/etc/victoriametrics/alerts.yml"

Когда активных таймсерий больше 10 миллионов — пора смотреть в сторону кластерной версии. Она состоит из трёх компонентов, каждый масштабируется независимо:

• vminsert — принимает входящие данные и раскидывает по шардам
• vmstorage — хранит данные на диске, ничего лишнего
• vmselect — обрабатывает запросы, собирая и агрегируя данные со всех шардов

Минимально жизнеспособный кластер — 3 ноды vmstorage с репликацией. Меньше не имеет смысла:

# На нодах хранения (storage-01, storage-02, storage-03)
/usr/local/bin/vmstorage-prod \
  -storageDataPath=/var/lib/vmstorage \
  -retentionPeriod=24 \
  -vminsertAddr=:8400 \
  -vmselectAddr=:8401

# На нодах vminsert (можно на тех же серверах)
/usr/local/bin/vminsert-prod \
  -httpListenAddr=:8480 \
  -storageNode=storage-01:8400,storage-02:8400,storage-03:8400 \
  -replicationFactor=2

# На нодах vmselect
/usr/local/bin/vmselect-prod \
  -httpListenAddr=:8481 \
  -storageNode=storage-01:8401,storage-02:8401,storage-03:8401 \
  -dedup.minScrapeInterval=30s

Параметр -replicationFactor=2 — каждая метрика пишется на 2 из 3 нод. Падает одна нода — данные никуда не деваются, читаем с оставшихся двух.

Grafana подключается к vmselect: http://vmselect:8481/select/0/prometheus.

VictoriaMetrics в обслуживании проста — если сравнивать с тем же Prometheus или Thanos, разница ощутимая. Но несколько настроек всё же существенно влияют на производительность, и лучше разобраться с ними заранее.

Мониторинг самой VictoriaMetrics — ключевые метрики для Grafana:

# Скорость приёма данных
rate(vm_rows_inserted_total[5m])

# Активные таймсерии
vm_cache_entries{type="storage/metricName"}

# Использование памяти
process_resident_memory_bytes / 1024 / 1024 / 1024

# Медленные запросы
vm_slow_queries_total

Рекомендации по ресурсам:

Резервное копирование делается через vmbackup:

# Полный бэкап в S3
vmbackup-prod \
  -storageDataPath=/var/lib/victoriametrics \
  -dst=s3://bucket/vm-backup/$(date +%Y%m%d) \
  -credsFilePath=/etc/victoriametrics/s3-creds.json

# Инкрементальный бэкап
vmbackup-prod \
  -storageDataPath=/var/lib/victoriametrics \
  -dst=s3://bucket/vm-backup/latest \
  -origin=s3://bucket/vm-backup/20260401