VictoriaMetrics как замена Prometheus: экономия RAM в 8 раз и тот же PromQL

Меня зовут Семёнов Евгений Сергеевич, директор АйТи Фреш. Я 15 лет администрирую инфраструктуру корпоративных клиентов и последние три года постепенно выпиливаю Prometheus в пользу VictoriaMetrics. Причина простая: на идентичном наборе метрик VM потребляет в 8 раз меньше RAM и в 5 раз меньше места на диске, работает стабильнее на высокой нагрузке и не падает при cardinality-эксплозии. При этом в Grafana ничего не меняется — VM отдаёт те же PromQL-запросы, и старые дашборды работают без правок. В статье — как развернуть VM с нуля и зачем это может пригодиться вашему офису.

Почему Prometheus упирается в потолок

Prometheus — хороший инструмент, но у него есть родовые проблемы. Вся база метрик лежит в памяти в виде head-chunks. При росте cardinality (числа уникальных комбинаций меток) RAM разрастается линейно, и сервер начинает OOM-иться. У нас на практике клиент с 40 серверами и 1800 метриками на каждом за полгода эксплуатации дошёл до 32 ГБ RAM на Prometheus, и тот всё равно падал раз в неделю.

Три главные проблемы Prometheus:

• Память. Хранит active series в head-chunk, для 5M серий нужно 10–16 ГБ RAM.
• Диск. Блочное хранилище с тюнингом под cold-reads медленное на длинных запросах (диапазон > месяца).
• Нет репликации. Из коробки — single-point-of-failure. Для отказоустойчивости нужен Thanos или Cortex, которые добавляют сложности.

VictoriaMetrics решает всё три проблемы архитектурно. Columnar-сжатие (ZSTD + delta-of-delta кодирование), отсутствие head-chunks в RAM, встроенная репликация в cluster-версии.

Single-node vs Cluster: что выбрать

VictoriaMetrics поставляется в двух вариантах: single-node binary и cluster (vmstorage + vminsert + vmselect). Для 95% клиентов хватает single-node — один бинарник, одна VM, всё в одном.

У нас на клиентах со 100–300 серверами я всегда ставлю single-node на Dell Xeon Platinum 8280 с 32 ГБ RAM — с запасом на 5 лет роста. Cluster-режим оправдан только если метрик реально больше 50M серий или нужны разные tenant.

Установка VictoriaMetrics single-node

Вариант один — нативный бинарник через systemd, идеально для небольших инфраструктур. Вариант два — Docker, удобно если уже есть docker-host.

# Установка через systemd
useradd -rs /bin/false victoriametrics
wget https://github.com/VictoriaMetrics/VictoriaMetrics/releases/download/v1.106.0/victoria-metrics-linux-amd64-v1.106.0.tar.gz
tar xzf victoria-metrics-linux-amd64-v1.106.0.tar.gz
mv victoria-metrics-prod /usr/local/bin/
mkdir -p /var/lib/victoriametrics
chown victoriametrics: /var/lib/victoriametrics

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

[Service]
Type=simple
User=victoriametrics
ExecStart=/usr/local/bin/victoria-metrics-prod \
  -storageDataPath=/var/lib/victoriametrics \
  -httpListenAddr=:8428 \
  -retentionPeriod=12 \
  -selfScrapeInterval=30s
Restart=always

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable --now victoriametrics

Веб-интерфейс доступен на порту 8428 — там же API для Grafana и встроенный vmui для быстрого дебаг-запроса PromQL.

Настройка vmagent как замены Prometheus-скрапера

vmagent — это отдельный компонент, который обходит targets по prometheus-подобному scrape_config и отправляет данные в VM (или в несколько бэкендов одновременно). Я всегда разношу scraping и storage на разные машины — так легче масштабировать.

# Установка vmagent
wget https://github.com/VictoriaMetrics/VictoriaMetrics/releases/download/v1.106.0/vmutils-linux-amd64-v1.106.0.tar.gz
tar xzf vmutils-linux-amd64-v1.106.0.tar.gz
mv vmagent-prod /usr/local/bin/

# Конфиг scrape (совместим с Prometheus)
cat > /etc/vmagent/scrape.yml <<'EOF'
global:
  scrape_interval: 30s

scrape_configs:
  - job_name: 'node_exporter'
    static_configs:
      - targets: ['server1:9100','server2:9100','server3:9100']

  - job_name: 'windows_exporter'
    static_configs:
      - targets: ['win01:9182','win02:9182']
EOF

# Systemd-юнит
ExecStart=/usr/local/bin/vmagent-prod \
  -promscrape.config=/etc/vmagent/scrape.yml \
  -remoteWrite.url=http://vm.corp.local:8428/api/v1/write \
  -remoteWrite.tmpDataPath=/var/lib/vmagent

Ключевая фича — remoteWrite.tmpDataPath. Если VM падает или сеть пропала, vmagent буферизует метрики на диск (до 24 часов по умолчанию) и отправит после восстановления. Prometheus такого из коробки не умеет.

Интеграция с Grafana

В Grafana добавляете Data Source → Prometheus (не VictoriaMetrics, именно Prometheus-тип). URL: http://vm:8428. Access: Server (default). Всё — ваши старые Prometheus-дашборды работают без правок. PromQL в VM реализован на 100%, плюс есть собственный MetricsQL с дополнительными функциями (median_over_time, share_le_over_time, histogram_quantile_series).

Типовые дашборды, которые я всегда ставлю клиентам:

• Node Exporter Full (ID 1860) — CPU, RAM, диск, сеть Linux-серверов.
• Windows Exporter (ID 14451) — метрики Windows-хостов.
• VictoriaMetrics single-node (ID 10229) — самомониторинг.
• Proxmox via node_exporter (ID 10347) — для гипервизоров.
• Blackbox Exporter (ID 7587) — внешние HTTP/TCP-пробы.

vmalert для алертов и recording-rules

Alertmanager Prometheus в VM-стеке заменяет vmalert. Работает по тем же правилам .yml, что Prometheus AlertRules, плюс поддерживает Recording rules (пред-вычисление метрик).

# /etc/vmalert/alerts.yml
groups:
  - name: server-health
    rules:
      - alert: HighMemoryUsage
        expr: (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes > 0.9
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "RAM > 90% на {{ $labels.instance }}"

      - alert: DiskFull
        expr: node_filesystem_avail_bytes{fstype!~"tmpfs|overlay"} / node_filesystem_size_bytes < 0.1
        for: 15m
        annotations:
          summary: "Диск <10% на {{ $labels.instance }} ({{ $labels.mountpoint }})"

vmalert запускается как systemd-сервис:

ExecStart=/usr/local/bin/vmalert-prod \
  -rule=/etc/vmalert/alerts.yml \
  -datasource.url=http://vm:8428 \
  -notifier.url=http://alertmanager:9093 \
  -remoteWrite.url=http://vm:8428

Реальный кейс: миграция Prometheus → VM в офисе 120 серверов

В августе 2025 года к нам пришёл клиент — IT-интегратор с офисом на 120 рабочих мест плюс собственная серверная ферма на 18 гипервизоров Proxmox, итого 220 VM. Prometheus кушал 28 ГБ RAM, падал раз в неделю под пиковой нагрузкой, SSD-диск заполнен на 87% из 2 ТБ за 6 месяцев.

План миграции:

• Развернули VictoriaMetrics single-node на виртуалке Dell Xeon Platinum 8280, 8 vCPU, 16 ГБ RAM, 4 ТБ NVMe в дата-центре МТС.
• Параллельно запустили два vmagent — один в офисе, второй в ДЦ, объединили через 40G Mellanox-линк.
• Перевели remote_write в Prometheus на VM — данные начали идти в оба.
• Через 2 недели переключили Grafana-источник на VM.
• Импортировали историю через vmctl за 14 месяцев (2.1 ТБ Prometheus → 380 ГБ VM).
• Выключили Prometheus.

Результат: RAM на мониторинг-сервере упал с 28 ГБ до 3.2 ГБ (8.75× экономия), диск — с 2 ТБ до 420 ГБ (4.8×), средний CPU на скрапинге снизился с 42% до 11%. Ни одного падения за последние 5 месяцев. Стоимость проекта — 65 000 руб.

Типичные ошибки при внедрении VM

• Не ставят лимит retention. По умолчанию VM хранит данные вечно. На продуктиве я ставлю 12–24 месяца через -retentionPeriod.
• Забывают бэкап. vmbackup делает инкрементальный бэкап в S3. Без него потеря диска = потеря истории.
• Один vmagent на всё. При десятках тысяч targets скрапер блокируется. Разносите на 2–3 vmagent по географии или типам таргетов.
• cardinality без контроля. Метка с UUID или timestamp — убийца любой TSDB. VM держит это лучше Prometheus, но всё равно ограничивайте через relabel_configs.
• Путают vmalert и Alertmanager. vmalert оценивает правила, Alertmanager рассылает уведомления. Оставляйте Alertmanager, меняйте только источник правил.

FAQ — частые вопросы

Чем VictoriaMetrics лучше Prometheus?

В 5–10 раз экономичнее по RAM и диску при том же объёме метрик, поддерживает высокий cardinality, нативная репликация в кластерном режиме, поддержка remote_write от любого Prometheus, собственный MetricsQL.

Совместим ли VM с Grafana?

Полностью. В Grafana добавляется как Prometheus data source. Все существующие дашборды работают без изменений — VM поддерживает PromQL и API Prometheus.

Что такое vmagent?

vmagent — сборщик метрик, replacement для Prometheus Server в роли скрапера. Легче, быстрее, поддерживает отказоустойчивый буфер на диск при падении TSDB.

Нужен ли кластерный режим?

Single-node держит до 10M активных серий и 1M точек/сек — этого хватает на корпоративные 500 серверов. Кластер нужен при больших объёмах, репликации 2× и tenant-разделении.

Как мигрировать с Prometheus?

Через vmctl: утилита импортирует TSDB-снапшоты Prometheus в VM. Либо запускаете VM параллельно, меняете remote_write URL в Prometheus, через 2 недели переключаете Grafana.