В 2026 вопрос «куда складывать метрики» снова стал инженерным, а не вкусовым. Почти в каждом продакшене появились обязательные требования: долговременное хранение, предсказуемая стоимость, высокая доступность и понятная история с мульти-тенантностью (когда метрики обслуживают несколько команд или клиентов).
При этом стек «Prometheus как сборщик + TSDB для долгого хранения» раскололся на три самые популярные стратегии:
- VictoriaMetrics (single или cluster) как относительно цельная TSDB с упором на эффективность и простую эксплуатацию.
- Prometheus + Thanos как эволюционный путь: оставляем привычный Prometheus, добавляем объектное хранилище и глобальные запросы.
- Grafana Mimir как распределённый backend для «Prometheus-as-a-Service» с жёсткой мульти-тенантностью и лимитами.
Ниже — разбор по темам, которые чаще всего болят в эксплуатации: ingestion и remote_write, retention, compaction, downsampling, HA-схемы и итоговый TCO.
Базовая модель данных и запросов: PromQL есть у всех, но нюансы разные
В Grafana всё действительно выглядит «похоже»: вы пишете PromQL (или совместимый диалект), строите панели и алерты. Отличия начинают проявляться в двух местах: как система принимает поток (ingestion) и как организованы хранение/индексация/дедупликация.
Prometheus исторически ориентирован на локальную TSDB и pull-модель (scrape). Thanosremote_write. MimirVictoriaMetricsremote_write или совместимые ingestion API.
«PromQL-совместимо» не означает «поведение идентично». На миграциях чаще всего удивляют лимиты на запросы, дедупликация, обработка частичных данных и то, как меняются результаты при больших диапазонах и крупном шаге.
Ingestion и remote_write: где упираются в CPU, сеть и очереди
Prometheus + Thanos: sidecar или receive — это разные компромиссы
В продакшене обычно встречаются две базовые архитектуры:
- Sidecar-схема: Prometheus пишет локальные блоки, Thanos Sidecar отгружает их в объектное хранилище; Thanos Query/Store дают глобальные запросы.
- Receiver-схема: Prometheus (или агент) отправляет данные по
remote_writeв Thanos Receive; дальше данные попадают в объектное хранилище и становятся доступны через Query.
Sidecar обычно проще внедрить «в существующий мир Prometheus», но вы платите локальным диском на каждом Prometheus и усложняете HA: при двойном scrape появляется дубль данных. Receive централизует ingestion, но требует аккуратно проектировать шардинг и устойчивость принимающей части, чтобы не получить «горячие» инстансы и переполненные очереди.
VictoriaMetrics: ставка на remote_write и эффективность хранения
Для VictoriaMetrics типовая схема — сборщики (Prometheus или агенты) скрейпят и отправляют в backend по remote_write. За счёт сжатия и оптимизации индекса часто удаётся снизить требования к диску и CPU на запись, особенно на «обычных» инфраструктурных метриках.
Но «бутылочное горлышко» в метриках почти всегда одно и то же: кардинальность. Если у вас тысячи таргетов, частые релизы и взрывные лейблы (request_id, url с параметрами, user_id), то проблемы будут у любого backend: вы упрётесь в сеть, CPU на ingestion, размер индекса и стоимость хранения.
Grafana Mimir: ingestion как распределённый сервис с политиками
Mimir проектировался как масштабируемый backend для платформенного мониторинга. Сильная сторона — горизонтальное масштабирование записи и запросов при строгой мульти-тенантности. Обратная сторона — больше компонентов и необходимость дисциплины по лимитам на тенанта: иначе один «шумный» проект легко испортит жизнь всем.
Если нужно жёстко разделять команды/клиентов, Mimir часто выигрывает управляемостью: квоты, ограничения на ingestion и запросы, изоляция и прозрачная модель «кто и чем нагрузил кластер».
Long-term storage: retention, compaction и жизненный цикл данных
Долговременное хранение — это не только «слить в объектное». Это ответы на вопросы: сколько храним, в каком виде, как чистим, как восстанавливаемся после сбоев и сколько стоит компакция на больших объёмах.
Retention: локально, в объектном и «сквозной» TTL
Prometheus удобен как локальный буфер (например, 12–48 часов для оперативной диагностики). Дальше варианты:
- В Thanos
- В VictoriaMetrics
- В Mimir
Самый частый операционный фейл: держать «слишком длинный retention без стратегии агрегации или downsampling» и потом удивляться стоимости хранения и времени запросов по году данных.
Compaction: скрытый потребитель ресурсов и источник сюрпризов
Compaction — это не «мелкая фоновая задача». Он напрямую влияет на стоимость и стабильность:
- CPU и IO на выполнение compaction/merge;
- latency запросов (насколько эффективно читаются данные из блоков/сегментов);
- восстановление после сбоев (сколько времени потребуется «догнать» корректное состояние).
В Thanos
В Mimir
В VictoriaMetrics
Downsampling и «длинные» запросы: почему откладывают и как подойти без боли
Downsampling — снижение разрешения исторических данных (условно: 5 секунд за неделю, 1 минута за квартал, 5 минут за год). Идея простая: резко сокращаете стоимость хранения и ускоряете запросы на больших диапазонах.
Чаще всего downsampling откладывают по двум причинам: страшно «потерять детализацию навсегда» и непонятно, какие запросы реально ходят из Grafana. В итоге годовой retention остаётся «сырым», а счёт за диски и объектное растёт быстрее, чем польза.
В стеке Prometheus + Thanos
В MimirVictoriaMetrics
Если у вас нет формализованных требований «какая точность нужна через 90/180/365 дней», downsampling превращается в бесконечный спор и в итоге проигрывает бюджету.
High availability: что именно считается HA для метрик в 2026
Термин «HA» для мониторинга обычно означает сразу три независимые цели:
- Сбор не останавливается: падение одной ноды/пода не прекращает поступление метрик.
- Запросы работают: Grafana и алерты не «слепнут» полностью.
- Дубль данных контролируем: иначе растёт стоимость и тяжелеют запросы.
В Prometheus
Thanos
Mimir
VictoriaMetricsremote_write» (два независимых backend) или через кластерный вариант с репликацией. Практически важно заранее решить, где вы хотите решать проблему дубля: на записи или на чтении.
Thanos: где выигрывает, а где усложняет жизнь
Если свести Thanos comparison к практическим наблюдениям, Thanos выигрывает, когда:
- у вас уже большой Prometheus-ландшафт и его менять нельзя;
- хочется дешёвое object storage как основу long-term;
- нужен глобальный запрос по множеству кластеров/регионов;
- важен поэтапный рост: начать с sidecar и дорости до более сложной схемы.
Thanos усложняет эксплуатацию, когда:
- команда не готова «мониторить мониторинг»: компонентов много, состояний деградации много;
- требуются строгие SLO по latency запросов, а нагрузка на Query растёт;
- HA сделан через двойной scrape, и дубль становится заметной статьёй расходов;
- объектное хранилище нестабильно по латентности/лимитам, и это бьёт по запросам на длинных диапазонах.
Grafana Mimir vs Thanos: что выбирать для платформы метрик
Запрос «Grafana Mimir vs Thanos» обычно появляется, когда Prometheus становится платформой для нескольких команд. Разница концептуальная:
- Thanos — надстройка вокруг Prometheus: сохраняет его модель и добавляет long-term и глобальный query.
- Mimir — самостоятельный распределённый backend, который остаётся Prometheus-совместимым по API и PromQL, но живёт по законам распределённой системы: шардинг, репликация, квоты, frontend запросов.
Если вам нужна жёсткая мульти-тенантность, ограничения на запросы, контроль «кто съел ресурсы» и масштабирование ingestion без зоопарка Prometheus, Mimir обычно прямее. Если же важнее использовать существующие Prometheus-инсталляции и сохранить локальные буферы «как есть», Thanos даёт эволюционный путь.
Практический нюанс: в Thanos «границы» часто соответствуют инстансам Prometheus и их блокам. В Mimir границы — это тенанты и политика платформы. Это влияет на алертинг, RBAC, лимиты и финансовую модель.
Если вы планируете алерты по проверкам доступности (HTTP/TCP/ICMP) и хотите держать их максимально простыми, пригодится отдельная схема с Blackbox Exporter и понятной маршрутизацией алертов. См. настройку проверок HTTP/TCP/ICMP через Blackbox Exporter.
VictoriaMetrics vs Prometheus: когда «просто TSDB» лучше, чем комбайн
Сравнение «VictoriaMetrics vs Prometheus» некорректно, если считать Prometheus только TSDB: это ещё и discovery, правила, экосистема и привычный путь алертинга с Alertmanager. Но если фокус именно на хранении и запросах, то VictoriaMetrics часто выбирают, когда нужно:
- минимум компонентов при наличии long-term;
- простая настройка retention без множества сервисов вокруг;
- умеренные требования к железу при хорошем сжатии;
- быстро получить рабочий результат без глубокого погружения в распределённую архитектуру.
Типичная схема 2026: Prometheus (или агент) как сборщик и «короткая память», а VictoriaMetrics как backend для всего длинного через remote_write.
Стоимость владения (TCO): что считать, кроме дисков
В мониторинге почти всегда ошибаются, считая только диски и object storage. Реальный TCO складывается из:
- CPU и RAM на ingestion (особенно при высокой кардинальности);
- IO на compaction/merge;
- сети: межкомпонентный трафик, отгрузка блоков, запросы к объектному;
- человеко-часов: сопровождение компонентов, расследование деградаций, обновления;
- стоимости ошибок: «слепые зоны» при сбоях, шумные алерты, пропуски данных.
Если команда небольшая и нет отдельного инженера под мониторинг, стек с множеством компонентов может оказаться дороже даже при дешёвом объектном. И наоборот: если вы строите платформу для многих команд, чрезмерная простота часто оборачивается неуправляемостью: один проект «вынесет» запросами весь кластер.
Размещать monitoring backend имеет смысл на предсказуемых по ресурсам серверах, где вы контролируете диск, сеть и IOPS. Под такие задачи обычно выбирают VDS, чтобы не упираться в ограничения shared-среды при росте объёма метрик.
Практические сценарии выбора
Сценарий A: 1–3 кластера, одна команда, нужен год хранения
Чаще выигрывает подход с меньшим числом компонентов: Prometheus для алертов + удалённое хранилище через remote_write (например, VictoriaMetrics) или аккуратный Thanos sidecar, если у вас уже есть объектное хранилище и опыт эксплуатации.
Сценарий B: много команд/тенантов, нужны лимиты и «справедливость»
Здесь сильнее смотрится Mimir: мульти-тенантность, квоты, предсказуемый ingestion и масштабирование. Thanos тоже возможен, но придётся больше «достраивать» процессы вокруг того, как разные Prometheus влияют друг на друга через Query и общее object storage.
Сценарий C: требование к HA и минимуму потерь данных при сбоях
Решите, где вы обеспечиваете HA: на стороне сбора (двойной scrape), на стороне ingestion (распределённая запись), на стороне хранения (репликация) или на стороне запросов (несколько querier). Самый частый компромисс: HA на ingestion/хранении и простой сбор агентом, чтобы не удваивать «сырьё».
Чеклист перед миграцией: чтобы сравнение не осталось теорией
- Профиль кардинальности: топ метрик по количеству series, «взрывные» лейблы, сезонность.
- SLO на запросы: какие дашборды должны открываться за 1–2 секунды, а какие могут быть медленнее.
- Retention по типам метрик: инфраструктурные, бизнес-метрики, детализация по endpoint.
- Политика агрегатов: где нужны recording rules, какие агрегаты хранить дольше сырья.
- План деградаций: что будет при недоступности object storage, при лаге compaction, при частичных данных.
- Модель HA: дубль на запись или дедуп на чтение; где «источник истины».
Практика: отдельно проверьте алерты, связанные с сертификатами и сроками действия, чтобы миграция хранилища метрик не превратилась в «мы не заметили, что истёк сертификат». См. алерты на истечение SSL-сертификатов и сценарии продления.
Итог: что выбрать в 2026
Если нужен вывод без лозунгов:
- Prometheus + Thanos — отличный путь, когда вы уже живёте в Prometheus-экосистеме и хотите «добавить долгую память», сохранив привычные паттерны. Цена — больше компонентов и больше внимания к object storage и compaction.
- Grafana Mimir — вариант, когда мониторинг становится платформой: много команд, строгая мульти-тенантность, квоты, масштабирование ingestion/queries. Цена — сложность распределённой системы и дисциплина конфигов.
- VictoriaMetrics — прагматичный выбор, когда хочется снизить операционную сложность и стоимость long-term, особенно при ставке на
remote_write. Цена — меньшая «модульность» и большая зависимость от конкретной реализации.
Сравнивайте не «по фичам», а по вашим сценариям запросов, retention-политикам, ограничениям по кардинальности и цене человеческого сопровождения. В мониторинге почти всегда дороже всего стоит не диск, а время инженеров и риск «ослепнуть» в критический момент.
