Prometheus зависает при запросе данных за месяц, а RAM забита под завязку метриками с тысячами лейблов. Это не баг - это архитектурный предел. VictoriaMetrics решает эти проблемы на уровне ядра, сохраняя полную совместимость с PromQL и экосистемой Grafana. В этом материале - цифры, сценарии и прямой путь миграции без потери данных.
Когда Prometheus достигает предела: ключевые проблемы и сценарии
Prometheus - стандарт сбора метрик в Kubernetes и за его пределами. Он прост, надёжен и запускается одним бинарником. Проблемы начинаются при росте инфраструктуры: сотни микросервисов, тысячи подов, десятки тысяч метрик с уникальными комбинациями лейблов. В этот момент Prometheus перестаёт справляться.
Типичные симптомы: потребление RAM растёт быстрее объёма данных, запросы PromQL на диапазоне в 30 дней выполняются десятки секунд, а локальное хранилище упирается в retention по умолчанию - 15 дней. При 1 млн активных временных рядов Prometheus может потреблять более 10 ГБ RAM. VictoriaMetrics на том же наборе данных использует в 3-5 раз меньше памяти. Причина - в архитектуре хранения и индексации.
Prometheus проектировался для краткосрочного хранения и оперативных запросов. Он не рассчитан на аналитику за месяцы и не имеет встроенных механизмов downsampling. Когда инфраструктура перерастает эти рамки, начинается поиск альтернативы. VictoriaMetrics - прямой кандидат на замену, потому что поддерживает те же протоколы, но снимает ограничения по кардинальности, хранению и скорости.
Высокая кардинальность: как метрики с большим количеством лейблов убивают производительность
Кардинальность - это количество уникальных комбинаций имени метрики и её лейблов. Например, метрика http_requests_total с лейблами path, method, status и pod в Kubernetes-кластере на 200 подов генерирует десятки тысяч временных рядов. Каждый ряд - это отдельная структура в памяти Prometheus.
Prometheus хранит индекс временных рядов в оперативной памяти целиком. При росте кардинальности индекс раздувается, и сервер уходит в OOM (Out of Memory). Это не баг, а следствие архитектурного решения: быстрый доступ к данным ценой линейного роста потребления RAM. На практике это означает, что Prometheus на одной ноде редко тянет больше 1-2 млн активных рядов без риска падения.
VictoriaMetrics использует принципиально другой подход. Индекс хранится на диске с частичным кэшированием в памяти, а данные сжимаются поблочно. Это позволяет обрабатывать миллионы рядов без экспоненциального роста RAM. В тестах сообщества VictoriaMetrics держит 10 млн активных рядов на 16 ГБ RAM, тогда как Prometheus на том же железе падает. Для инженера, который отвечает за мониторинг продакшена, это разница между стабильной работой и ночным алертом о переполнении памяти.
Долгосрочное хранение: почему Prometheus не рассчитан на годы метрик
Prometheus по умолчанию хранит данные 15 дней. Это осознанное ограничение: локальный TSDB оптимизирован под быструю запись и чтение свежих данных, а не под архивирование. При увеличении retention до 30-60 дней производительность деградирует - растёт время compaction блоков, увеличивается нагрузка на диск, замедляются запросы.
Официальная рекомендация разработчиков Prometheus - использовать remote write для долгосрочного хранения. Данные пишутся во внешнюю систему, которая берёт на себя задачу долговременного архивирования. VictoriaMetrics - один из лучших приёмников для remote write. Она принимает метрики в нативном формате Prometheus, сжимает их и обеспечивает быстрый доступ к данным за любой период.
VictoriaMetrics поддерживает хранение метрик за годы без потери производительности запросов. Встроенный механизм downsampling автоматически снижает разрешение старых данных: например, метрики с шагом в 1 минуту через 30 дней агрегируются до 5-минутных интервалов. Это сохраняет тренды и экономит дисковое пространство. Prometheus такой возможности лишён - все данные хранятся в исходном разрешении, что делает долгосрочное хранение неоправданно дорогим.
Архитектурные различия: как устроены VictoriaMetrics и Prometheus изнутри
Разница в поведении под нагрузкой продиктована архитектурой. Prometheus - single-node решение с pull-моделью сбора, локальным TSDB и отсутствием встроенной кластеризации. VictoriaMetrics предлагает два режима: single-node для небольших и средних нагрузок и кластерный для крупных инсталляций. Оба режима совместимы на уровне протоколов, что упрощает миграцию при росте инфраструктуры.
Prometheus: простота и ограничения одиночного сервера
Prometheus запускается одним бинарником, не требует внешних зависимостей и конфигурируется через YAML. Это его главная сила. Pull-модель сбора означает, что Prometheus сам опрашивает цели по HTTP - не нужны очереди сообщений и агенты на каждом хосте. Для стартапа или небольшого проекта такая архитектура идеальна: минимум движущихся частей, предсказуемое поведение, огромное комьюнити.
Ограничения проявляются при масштабировании. Prometheus не поддерживает кластеризацию из коробки. Для горизонтального масштабирования приходится использовать федерацию (иерархический сбор метрик) или внешние решения вроде Thanos и Cortex. Это добавляет сложности: новые компоненты, новые точки отказа, дополнительная настройка. Thanos требует объектное хранилище, Cortex - собственную базу данных. Эксплуатационные расходы растут, а простота, за которую ценят Prometheus, теряется.
VictoriaMetrics: кластерная архитектура для высоких нагрузок
VictoriaMetrics разделяет приём, хранение и запросы на независимые компоненты: vminsert принимает данные по remote write или напрямую от vmagent, vmstorage хранит сжатые блоки на диске, vmselect обрабатывает PromQL-запросы. Каждый компонент масштабируется отдельно.
Это решает проблему «горячих точек». Если растёт поток записи, добавляются ноды vminsert. Если увеличивается количество дашбордов и алертов, масштабируется vmselect. Данные шардируются между нодами vmstorage с репликацией - отказ одной ноды не приводит к потере данных. Single-node версия VictoriaMetrics полностью совместима с кластерной: можно начать с одной ноды и перейти к кластеру, когда инфраструктура вырастет. Такой подход не требует переписывать конфигурацию сборщиков или дашборды - достаточно развернуть дополнительные компоненты.
Производительность и потребление ресурсов: цифры и бенчмарки
Официальные бенчмарки VictoriaMetrics показывают скорость приёма до 1 млн samples в секунду на ядро. Prometheus на том же железе обрабатывает 200-300 тысяч samples в секунду. Разница достигается за счёт оптимизированного хранилища и отсутствия блокировок при записи. На практике это означает, что VictoriaMetrics справляется с потоком метрик от крупного Kubernetes-кластера на одном сервере, тогда как Prometheus требует шардирования.
Потребление CPU при записи у VictoriaMetrics ниже на 30-50% по сравнению с Prometheus при одинаковом потоке метрик. RAM используется эффективнее: VictoriaMetrics держит в памяти только горячий кэш, остальное вытесняется на диск. Prometheus хранит индекс в памяти полностью, что приводит к линейному росту потребления с увеличением числа временных рядов.
Сжатие данных: почему VictoriaMetrics экономит до 90% дискового пространства
VictoriaMetrics применяет несколько уровней сжатия: дедупликация одинаковых сэмплов, дельта-кодирование (хранение разницы между соседними значениями, а не абсолютных величин) и алгоритм zstd для финального сжатия блоков. Результат - 1 ТБ данных в Prometheus занимает около 100 ГБ в VictoriaMetrics. Это не маркетинговое обещание, а воспроизводимый результат на реальных данных.
Сжатие влияет не только на стоимость дисков, но и на скорость запросов. Меньший объём данных означает меньше операций ввода-вывода при сканировании исторических диапазонов. Запрос rate(http_requests_total[5m]) за последние 30 дней в Prometheus читает с диска гигабайты несжатых данных. VictoriaMetrics читает сотни мегабайт сжатых блоков и распаковывает их на лету. Результат - время выполнения запроса сокращается с десятков секунд до долей секунды.
Скорость запросов PromQL: сравнение на реальных дашбордах
Типичный сценарий: дашборд Grafana с графиком latency за последние 7 дней и несколькими фильтрами по лейблам. Prometheus выполняет такой запрос за 5-15 секунд в зависимости от кардинальности. VictoriaMetrics - за 0.1-0.5 секунды. Для инженера, который расследует инцидент в три часа ночи, это разница между быстрой диагностикой и мучительным ожиданием.
VictoriaMetrics поддерживает PromQL без изменений. Дашборды и алерты, написанные для Prometheus, работают без модификации. Достаточно перенаправить источник данных в Grafana на VictoriaMetrics. Это снимает главный барьер для миграции - не нужно переписывать накопленные правила и запросы.
Долгосрочное хранение и работа с историческими данными
Хранение метрик за месяцы и годы - требование не только compliance, но и практической аналитики. Без исторических данных невозможно отследить тренды, спланировать capacity или провести post-mortem инцидента месячной давности. Prometheus для этого требует внешнее хранилище, VictoriaMetrics предоставляет его из коробки.
Downsampling и ретеншен: как сохранить метрики за годы и не разориться на дисках
VictoriaMetrics автоматически уменьшает разрешение данных старше заданного порога. Например, метрики с шагом 1 минута через 30 дней агрегируются до 5-минутных интервалов, через 90 дней - до 15-минутных. Тренды сохраняются, объём данных сокращается в разы. Это позволяет хранить метрики за 2-3 года на умеренном объёме дисков - сотни гигабайт вместо десятков терабайт.
Prometheus не имеет встроенного downsampling. Все данные хранятся в исходном разрешении до истечения retention. При попытке хранить данные больше 30 дней объём диска растёт линейно, а производительность запросов падает. Remote write в VictoriaMetrics решает эту проблему: Prometheus собирает свежие метрики и отправляет их в VictoriaMetrics, которая берёт на себя долгосрочное хранение и downsampling.
Совместимость и миграция: как перейти с Prometheus на VictoriaMetrics без боли
VictoriaMetrics полностью совместима с экосистемой Prometheus. Поддерживаются: PromQL, формат метрик, remote write/read, service discovery, алертинг через Alertmanager. Grafana работает с VictoriaMetrics как с обычным источником данных Prometheus. Миграция может быть выполнена постепенно, без остановки мониторинга.
Пошаговый план миграции: развернуть VictoriaMetrics параллельно с Prometheus, добавить секцию remote_write в конфигурацию Prometheus с адресом VictoriaMetrics, дождаться наполнения данными, переключить Grafana и алерты на VictoriaMetrics, остановить старый Prometheus. Весь процесс занимает часы, а не дни. Данные за период параллельной работы сохраняются в обеих системах, что исключает потерю метрик.
Использование vmagent вместо Prometheus: плюсы и минусы
Vmagent - облегчённый сборщик метрик от разработчиков VictoriaMetrics. Он потребляет в 2-3 раза меньше RAM и CPU, чем Prometheus, при том же объёме собираемых метрик. Поддерживает remote write не только в VictoriaMetrics, но и в Kafka, что удобно для построения ETL-пайплайнов. Встроенная релей-логика позволяет буферизовать данные при недоступности хранилища.
Минусы: vmagent не поддерживает запросы PromQL и алертинг - для этого нужен отдельный Prometheus или VictoriaMetrics. Экосистема exporters и service discovery у Prometheus шире и лучше документирована. Рекомендуемый гибридный подход: оставить Prometheus для сбора метрик с экспортёров и алертинга, а VictoriaMetrics использовать как центральное хранилище через remote write. Это даёт лучшее из двух миров: проверенную экосистему сбора и эффективное долгосрочное хранение.
Рекомендации по выбору: какая система подходит для вашей инфраструктуры в 2026
Выбор между Prometheus и VictoriaMetrics сводится к трём факторам: масштаб инфраструктуры, требования к хранению и бюджет на сопровождение. Ниже - конкретные сценарии с пороговыми значениями.
Сценарий 1: Стартап или небольшой проект - остаёмся на Prometheus
Условия: до 50-100 целей мониторинга, до 500 тысяч активных временных рядов, бюджет ограничен, нет жёстких требований к хранению дольше 30 дней. Prometheus - правильный выбор. Он прост в установке, имеет огромное комьюнити и покрывает 100% потребностей небольшой инфраструктуры. VictoriaMetrics будет избыточен: вы не получите заметного выигрыша, но добавите ещё один компонент в стек.
Практическое руководство по настройке Prometheus с нуля - в материале Системы мониторинга производительности 2026: от CLI-утилит до Prometheus и Grafana.
Сценарий 2: Растущая компания с Kubernetes - внедряем VictoriaMetrics
Типичная ситуация: Kubernetes-кластер, сотни микросервисов, 1-5 млн активных временных рядов. Prometheus начинает тормозить: запросы выполняются медленно, RAM забита, retention приходится урезать. VictoriaMetrics single-node решает эти проблемы без серьёзного усложнения инфраструктуры. Установка - один бинарник, совместимость с Grafana полная, PromQL работает без изменений.
При таком масштабе вы получаете: снижение потребления RAM в 3-5 раз, ускорение запросов в 10-50 раз, возможность хранить метрики за 6-12 месяцев без downsampling. Если ваша инфраструктура растёт, а мониторинг начинает отставать - это сигнал к переходу. Пошаговый план миграции описан в разделе выше.
Сценарий 3: Enterprise с жёсткими требованиями - VictoriaMetrics Cluster
Требования: хранение за 3-5 лет, отказоустойчивость, мультитенантность, десятки миллионов активных рядов. VictoriaMetrics Cluster с репликацией и шардированием - единственный вариант, который закрывает эти требования без костылей. Prometheus даже в связке с Thanos будет сложнее в эксплуатации: Thanos требует объектное хранилище, отдельный compactor и store gateway. VictoriaMetrics Cluster - это три типа компонентов (vminsert, vmstorage, vmselect), которые конфигурируются единообразно.
Для enterprise-сред критичны также требования к наблюдаемости всей платформы. Рекомендации по построению комплексной системы мониторинга для высоконагруженных систем - в статье Наблюдаемость для высоконагруженных систем: ключевые метрики и эффективные алерты в 2026 году.
Тренды 2026 года подтверждают движение в сторону VictoriaMetrics. Рост объёмов метрик из-за eBPF и OpenTelemetry, увеличение кардинальности в микросервисных архитектурах, требования к хранению данных за годы - Prometheus в одиночку не справляется с этими вызовами. VictoriaMetrics предлагает решение, которое не ломает привычный стек, но снимает его фундаментальные ограничения. Если вы проектируете систему мониторинга сейчас, закладывайте VictoriaMetrics как целевое хранилище - миграция в будущем обойдётся дороже, чем правильный выбор на старте.