VictoriaMetrics вместо Prometheus: когда есть смысл

MAATRIX

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

Что такое VictoriaMetrics и при чём тут совместимость с Prometheus

VictoriaMetrics — это система хранения и обработки временных рядов (time series database), которая изначально проектировалась как более экономная по ресурсам альтернатива классическому стеку Prometheus, но не как его полная замена архитектурно, а как совместимая замена на уровне протоколов и языка запросов.

Ключевое слово здесь — совместимая. VictoriaMetrics:

• понимает PromQL — тот же язык запросов, на котором у вас уже написаны алерты и панели Grafana;
• принимает данные по протоколу remote_write, которым Prometheus умеет писать метрики во внешнее хранилище;
• отдаёт данные через API, совместимый с Prometheus HTTP API, поэтому Grafana подключается к ней как к обычному источнику данных Prometheus (если у вас ещё нет базовой связки, вот пошаговая установка Grafana и Prometheus, с которой обычно и начинают);
• поддерживает те же экспортеры метрик (node_exporter, blackbox_exporter и любые другие, которые пишут в формате Prometheus) — им всё равно, кто читает их /metrics.

Практический вывод: переход на VictoriaMetrics в подавляющем большинстве случаев не требует переписывания накопленной инфраструктуры мониторинга. Дашборды в Grafana, которые вы годами допиливали, правила алертинга в Alertmanager, сами экспортеры на серверах — всё это остаётся. Меняется (или дополняется) только компонент хранения и обработки метрик.

Это принципиально отличает переход на VictoriaMetrics от перехода на Zabbix или Netdata, где пришлось бы переписывать и правила, и способ сбора метрик с нуля. Здесь же меняется движок под капотом при сохранении фасада.

Совместимость на практике: что меняется, а что нет

Разберём по компонентам, что происходит с типичной Prometheus-инсталляцией при переходе.

Слово «почти» в строке про правила алертинга не случайно: PromQL в VictoriaMetrics совместим с оригинальным на уровне подавляющего большинства функций, но у проекта есть и собственные MetricsQL-расширения сверху. Для стандартных правил (rate(), increase(), агрегации по label) проблем не возникает. Если у вас в правилах используются редкие или самописные функции — стоит явно прогнать их на тестовом стенде перед переносом в продакшен, а не полагаться на то, что «PromQL — это PromQL». Кстати, часть типичных проблем связки Grafana и Prometheus (не связанных с VictoriaMetrics напрямую, но полезных для сверки) разобрана в статье про частые ошибки Grafana и Prometheus на сервере.

Два варианта архитектуры перехода:

1. Prometheus остаётся как агент сбора, просто дописывает метрики через remote_write в VictoriaMetrics — минимальные изменения, Prometheus продолжает делать scrape, но хранит данные не у себя, а во внешней системе.
2. Prometheus заменяется на vmagent — это отдельный компонент, который занимается только сбором метрик (scrape) и их отправкой дальше, без собственного хранилища. Расход памяти и диска на самом сервере сбора становится меньше, потому что vmagent не хранит историю локально.

Для большинства инсталляций второй вариант логичнее, если цель — сократить нагрузку именно на сервер, который занимается сбором метрик.

Место на диске и память: где VictoriaMetrics обычно выигрывает

Здесь важно сразу отделить факты от маркетинга. VictoriaMetrics позиционируется разработчиками как система с более эффективным сжатием данных и меньшим потреблением памяти при хранении больших объёмов исторических метрик, за счёт другой внутренней структуры хранения (собственный движок на основе LSM-подобных структур, специально заточенный под метрики, а не универсальная база данных).

Мы намеренно не приводим здесь конкретных цифр вида «в N раз меньше места» — такие цифры кочуют по статьям без указания, на каком объёме данных, при какой кардинальности меток (number of unique label combinations) и при каком периоде хранения они были получены. На вашей конкретной нагрузке результат может отличаться в любую сторону: если у вас высокая кардинальность меток (много уникальных комбинаций label — например, по каждому клиенту или запросу), выигрыш в сжатии будет меньше, чем в тестах с типичными инфраструктурными метриками.

Что делать вместо того, чтобы верить цифрам из чужих бенчмарков:

1. Разверните VictoriaMetrics рядом с существующим Prometheus (на отдельном VPS или на том же сервере на другом порту).
2. Настройте remote_write из Prometheus в VictoriaMetrics, чтобы туда полился реальный поток ваших метрик, а не синтетический тест.
3. Через 1-2 недели сравните фактическое потребление диска (du -sh /var/lib/victoria-metrics-data) и памяти (docker stats) с показателями вашего текущего Prometheus за тот же период, а также прогоните типичные для вас запросы из дашбордов и алертов и сравните время ответа хотя бы на уровне «медленнее / так же / быстрее».

Это тот случай, когда единственный честный бенчмарк — ваш собственный, на вашем объёме данных и ваших запросах. Обещания «в разы эффективнее» без контекста нагрузки не значат ничего конкретного для вашего случая.

Если экономия на дисковом пространстве для вас не критична — то есть текущий Prometheus не подходит вплотную к лимиту диска на VPS и не создаёт проблем с производительностью — сам факт «более эффективного» хранения не должен быть причиной для миграции.

Долгосрочное хранение метрик: где Prometheus традиционно слабее

Второй практический повод присмотреться к VictoriaMetrics — не место на диске, а горизонт хранения истории.

Prometheus в его базовой конфигурации (то есть без дополнительных компонентов) исторически ориентирован на относительно недавнюю историю метрик — типичные настройки retention в реальных инсталляциях измеряются днями-неделями, а не месяцами-годами. Это не жёсткое архитектурное ограничение (retention можно увеличить флагом --storage.tsdb.retention.time), но при росте периода хранения растёт и нагрузка на локальный диск single-node инсталляции, и это быстро упирается в объём диска конкретного сервера.

Для действительно долгосрочного хранения (месяцы и годы истории — например, для сравнения нагрузки год к году или для compliance-требований) классический подход в мире Prometheus — добавить отдельный компонент поверх: Thanos, Cortex или Mimir. Каждый из них решает задачу, но ценой дополнительного сервиса в инфраструктуре (разворачивать, обновлять, мониторить отдельно), новых точек отказа и часто — необходимости объектного S3-совместимого хранилища под холодные данные.

VictoriaMetrics в этом смысле предлагает другой путь: единый инструмент, где долгосрочное хранение — не надстройка, а часть базовой архитектуры. Кластерная версия (VictoriaMetrics cluster) из коробки поддерживает и горячие, и холодные данные без отдельного Thanos/Cortex/Mimir поверх, а для не самых больших объёмов достаточно и single-node версии с retention в месяцы и годы без принципиальных архитектурных надстроек.

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

Когда переход, вероятно, не оправдан

Здесь стоит применить тот же принцип, что действует при выборе почти любого технического инструмента: не чините то, что не сломано.

Переход на VictoriaMetrics, скорее всего, не даст ощутимой практической выгоды, если у вас одновременно:

• скромный объём метрик — условно, несколько десятков хостов и стандартный набор экспортеров, без десятков тысяч уникальных временных рядов;
• текущий Prometheus работает без видимых проблем — диск не заканчивается, отклик Grafana устраивает, алерты срабатывают вовремя;
• retention в несколько недель вас полностью устраивает и запроса на историю за прошлый год не поступало;
• команда уже привыкла к операционным особенностям Prometheus (бэкапы snapshot'ов, обновления, мониторинг самого Prometheus) и не горит желанием осваивать новый инструмент.

В этой ситуации миграция добавляет реальные издержки — время на развёртывание нового компонента, изучение его эксплуатации, тестирование совместимости правил алертинга — а взамен даёт теоретическую экономию ресурсов, которую при скромном масштабе вы просто не почувствуете на глаз. Диск на VPS, заполненный на 20%, не станет заметно «свободнее» от более эффективного сжатия — экономия в процентах от небольшой базы остаётся небольшой в абсолютных числах.

Смена инструмента ради абстрактного «у них эффективнее» без конкретной измеримой проблемы — это дополнительная сложность без ощутимой отдачи. Технологию стоит менять под реальную задачу, а не под репутацию инструмента в статьях (в том числе в этой). Похожая логика разобрана в статье Zabbix или Prometheus: что выбрать для сервера — там тот же принцип применяется к выбору системы мониторинга целиком, а не только хранилища метрик.

Практический критерий: когда стоит рассмотреть переход всерьёз

Сведём сказанное к конкретному правилу. Рассматривайте переход на VictoriaMetrics, когда вы реально столкнулись, а не предвидите заранее, хотя бы с одним из ограничений текущей настройки Prometheus:

• место на диске — раздел с данными Prometheus регулярно приближается к лимиту, приходится либо расширять диск на VPS, либо сокращать retention, теряя историю, которая нужна;
• память — процесс Prometheus потребляет заметно больше RAM, чем закладывалось при планировании ресурсов сервера, и это стало ощутимой статьёй в апгрейде тарифа VPS;
• нужда в более длительной истории — бизнесу или команде реально потребовалось сравнение метрик за периоды длиннее, чем позволяет текущий retention, и вы уже думаете о Thanos/Cortex/Mimir как об альтернативе.

Если хотя бы один пункт фактический, а не гипотетический — вы уже получали алерт «мало места на диске» или увеличивали тариф VPS из-за памяти под мониторинг — тестирование VictoriaMetrics становится оправданным решением, а не экспериментом ради эксперимента.

Быстрый план пилота на отдельном VPS:

# Разворачиваем VictoriaMetrics single-node в Docker на тестовом сервере
docker run -d --name victoriametrics \
  -p 8428:8428 \
  -v vm-data:/victoria-metrics-data \
  victoriametrics/victoria-metrics:v1.102.0 \
  --storage.dataPath=/victoria-metrics-data \
  --retentionPeriod=12

# Добавляем remote_write в существующий prometheus.yml,
# ничего не удаляя из текущей конфигурации
remote_write:
  - url: "http://vm-host:8428/api/v1/write"

После этого в Grafana достаточно добавить новый источник данных типа Prometheus, указав URL VictoriaMetrics (http://vm-host:8428), и подключить к нему копию одного-двух рабочих дашбордов — не трогая продакшен-источник, пока не убедитесь, что графики и алерты ведут себя идентично.

Практический план миграции без даунтайма

Если после пилота решение принято, миграцию стоит проводить поэтапно, не выключая старый Prometheus до полной уверенности в новом хранилище.

Шаг 1. Двойная запись. Оставляем Prometheus как есть, добавляем remote_write в VictoriaMetrics. Обе системы получают одинаковый поток метрик параллельно — это самый безопасный период, откатиться можно в любой момент, просто убрав секцию remote_write.

Шаг 2. Перенос истории (опционально). Если нужна не только новая история, но и перенос уже накопленных данных, у VictoriaMetrics есть отдельная утилита vmctl, которая умеет читать данные напрямую из TSDB Prometheus и импортировать их:

vmctl prometheus \
  --prom-snapshot=/path/to/prometheus/snapshot \
  --vm-addr=http://vm-host:8428

Перед запуском стоит сделать снапшот Prometheus через API (POST /api/v1/admin/tsdb/snapshot), чтобы не мигрировать «живые» данные, а работать со стабильным срезом.

Шаг 3. Переключение дашбордов. Меняем источник данных в Grafana для одного некритичного дашборда — проверяем, что графики визуально идентичны прежним. Затем переключаем остальные дашборды.

Шаг 4. Перенос алертинга. Правила переносятся в vmalert (аналог правил Prometheus для VictoriaMetrics), либо алертингом продолжает заниматься прежний Prometheus, а VictoriaMetrics остаётся только хранилищем для дашбордов.

Шаг 5. Замена сборщика (опционально). Для снижения нагрузки на сервер сбора Prometheus заменяется на vmagent — его scrape_configs совместим по формату с prometheus.yml, менять придётся минимум.

Шаг 6. Отключение старого Prometheus. Только после того, как новый стек отработал стабильный период (минимум пару недель, включая пиковую нагрузку и хотя бы одно алертинговое событие).

Такой поэтапный подход снимает главный риск любой миграции мониторинга — остаться без метрик и алертов в момент, когда что-то реально сломается на проде.

Частые вопросы