Ограничения Prometheus

Ограничения по производительности

• Высокое потребление памяти/CPU: Если Prometheus использует десятки гигабайт памяти или сильно грузит CPU, он может упереться в лимиты вертикального масштабирования. 
• Медленные запросы: Запросы за длительные периоды (недели/месяцы) могут вызывать ошибки из-за нехватки памяти. 
• Уникальный лейблы: Метрики с уникальными лейблами (например, user ID) или слишком большим числом временных рядов замедляют работу Prometheus. 

Ограничения по хранению и надежности

• Короткий срок хранения: По умолчанию Prometheus хранит данные 15 дней. Можно увеличить этот срок, но удерживать данные на одном узле долго — рискованно: линейный рост использования диска, отсутствие репликации и риск потери данных при сбое.
• Требования к надежности: В средах, где метрики должны пережить сбои узлов или храниться вне площадки (например, для аудита), Prometheus без внешнего хранилища — недостаточен. WAL лишь частично помогает при сбоях.

Масштабируемость и распределённые среды

• Множество кластеров: Если вы запускаете несколько Prometheus, и хотите единый взгляд на всё — Prometheus сам по себе не справится. Federation или «зонтичный» сервер превращаются в узкие места.
• Пробелы в доступности: Один Prometheus на кластер — это риск временной потери мониторинга. Пара серверов в HA может помочь, но объединение дублирующих потоков данных — нетривиальная задача.
• Мультиарендность: Prometheus не поддерживает мультиарендность «из коробки». Все данные хранятся вместе. В среде с несколькими командами или проектами это неудобно.

Обзор решений для долгосрочного хранения метрик

Чтобы преодолеть его ограничения, существует несколько open-source решений, которые обеспечивают:

• долгосрочное хранение данных;
• горизонтальное масштабирование;
• высокую доступность.

---

1. Thanos

• Развёртывается рядом с существующими Prometheus-инстансами (через Sidecar).
• Интегрирован в kubernetes prometheus operator, поддерживает добавление в текущую инсталляцию prometheus через kube-prometheus-stack helm chart.
• Минимально инвазивен, ориентирован на долговечность и глобальную агрегацию.
• Не заменяет полностью TSDB Prometheus, а дополняет его.

---

2. Cortex

• Проект CNCF, с недавнего времени — основа для Prometheus Native Histograms.
• Микросервисная архитектура (отдельные компоненты для ingestion, хранения, запросов и т.д);
• Масштабируемое, мультиарендное хранилище;
• Prometheus отправляет данные через remote_write;
• Хранит данные в блоках или чанках, используя object storage или NoSQL.

---

3. Grafana Mimir

• Относительно новый проект (опенсорс с 2022 года), форк Cortex.
• Полностью мультиарендный, используется Grafana Cloud.

---

4. VictoriaMetrics (VM)

• Высокопроизводительная TSDB, которая может использоваться как удалённое хранилище для Prometheus, или полностью заменить его.

• Поддерживает Single-node version (для простых случаев) и кластерный режим (для масштабируемости).

Как выбрать подходящее решение 

Thanos — просто, надёжно, недорого

Thanos расширяет уже работающий Prometheus, не требуя перестройки архитектуры.

• Хранение: горячие данные остаются в Prometheus, холодные — в S3.

• Производительность: быстрые запросы за счёт даунсемплинга.

• Надёжность: object storage + stateless-компоненты, легко масштабировать.
  Отличный выбор для тех, кто хочет добавить долговременное хранение без усложнения инфраструктуры.

Cortex и Mimir — для масштаба и мультиарендности

Эти решения подходят для крупных команд и SaaS-нагрузок.

• Архитектура: десятки микросервисов, кэши, полная мультиарендность.

• Хранение: S3 и репликация до 3 копий — устойчивость к сбоям.

• Особенности: Mimir проще в настройке (Helm-чарты), Cortex стабильнее на больших объёмах.
  Выбор для тех, кому нужна высокая доступность и изоляция команд.

VictoriaMetrics — быстрая, экономная, но с нюансами

VM можно использовать как TSDB или удалённое хранилище.

• Хранение: данные на локальных дисках — моментальный доступ.

• Экономия: лучшее сжатие, не нужно платить за чтение, как в S3.

• Надёжность: через шардинг и replication factor, но требует настройки.
  Идеально, если запросов много и важна эффективность работы.

Миграция с Prometheus на долгосрочное хранилище 

Thanos

Интеграция Thanos начинается с того, что Prometheus остаётся в системе и не заменяется. Рядом с каждым экземпляром Prometheus устанавливается компонент Thanos Sidecar, который начинает выгружать двухчасовые блоки TSDB в объектное хранилище, такое как S3. Чтобы получить глобальный доступ к данным, можно добавить компонент Thanos Querier и направить Grafana на него. Исторические данные, уже накопленные Prometheus (например, за последние 15 дней), также выгружаются в хранилище, и при этом нет необходимости перезапускать Prometheus. Он продолжает использоваться для сбора и анализа данных в реальном времени, тогда как Thanos обеспечивает доступ к долгосрочной истории.

Дашборды и алерты продолжают работать на старом Prometheus до тех пор, пока вы не решите перенести их. Во многих случаях Prometheus можно заменить на Thanos как основной источник данных в Grafana, поскольку Thanos обеспечивает доступ и к метрикам в реальном времени, и к историческим данным. Для дашбордов, где источник данных не вынесен в переменную, удобно использовать экспорт и импорт при обновлении. Thanos также поддерживает компонент Ruler, который позволяет выполнять правила алертинга на глобальных данных. При этом Alertmanager может остаться без изменений.

Чтобы избежать потерь данных при миграции, важно работать параллельно — не отключайте Prometheus до завершения выгрузки всех блоков. Убедитесь, что Thanos Sidecar корректно выгружает данные; при необходимости можно вручную инициировать создание снапшота. Проверьте, что Grafana отображает полный диапазон данных и не теряет окна времени. Рекомендуется создать снапшот Prometheus на случай сбоя — Thanos сможет использовать его как дополнительный источник через store-компонент. Перед полноценным переходом проведите тестовую миграцию на стенде, чтобы убедиться в корректной работе алертов, запросов и визуализаций.

---

Cortex / Mimir

Интеграция с Cortex или Mimir начинается с развёртывания нового кластера и настройки remote_write в Prometheus — после этого он начинает отправлять метрики в новое хранилище. Prometheus можно оставить в текущем виде для локальных запросов и алертов или перевести в облегчённый режим. Как правило, миграция происходит без переноса исторических данных — начинается запись с нуля. Однако если перенос истории необходим, можно использовать инструмент thanosconvert для преобразования TSDB-блоков и загрузки их в object storage, подключённый к Cortex. Этот процесс требует ручной подготовки и копирования файлов. На практике Prometheus продолжает работать параллельно, пока в нём не отпадает необходимость.

Переход на Cortex или Mimir проходит относительно безболезненно с точки зрения дашбордов и алертов, поскольку оба решения полностью совместимы с PromQL. Дашборды в Grafana можно просто переключить на новый источник данных. При этом важно учесть настройки external_labels, если они используются, а в многопользовательской среде — корректно настроить tenant ID. Хорошей практикой считается временное подключение обоих источников в Grafana для параллельного тестирования. Оба решения включают собственные ruler-сервисы, работающие в режиме высокой доступности, что позволяет перенести алерт-правила. Alertmanager при этом может остаться без изменений, если новый источник поддерживает PromQL.

Чтобы избежать потерь при переходе на Cortex или Mimir, не отключайте Prometheus до тех пор, пока новое хранилище не накопит достаточный объём истории. При включении remote_write важно внимательно следить за метриками очередей — особенно за remote_write_pending_samples, который указывает на возможные задержки. Для надёжной передачи данных настройте стабильное сетевое соединение, оптимальный размер партий, корректные окна доставки и, по возможности, выполняйте миграцию в периоды низкой нагрузки. Перед отключением Prometheus сделайте его снапшот на случай отката. Завершите процесс тестированием всей цепочки на стенде: проверьте приём метрик, отображение в Grafana, срабатывание алертов и корректность прав доступа.

---

VictoriaMetrics

Интеграция с VictoriaMetrics начинается с развёртывания кластера и настройки remote_write в Prometheus. При необходимости Prometheus можно полностью заменить на vmagent, который выполняет сбор и отправку метрик. В большинстве случаев исторические данные не переносятся — Prometheus продолжают использовать до окончания срока хранения метрик (retention). Если же требуется сохранить историю, можно воспользоваться инструментом vmctl, который позволяет загрузить данные из снапшота Prometheus в VictoriaMetrics. Такая конфигурация также позволяет использовать VM как удалённое хранилище, а Prometheus — для алертинга. Grafana без проблем переключается на VictoriaMetrics, поскольку она поддерживает PromQL.

Благодаря полной поддержке PromQL дашборды в Grafana продолжают работать без изменений после перехода на VictoriaMetrics. Если в конфигурации ранее использовались external_labels, их потребуется учесть при настройке нового источника. Алерты можно либо оставить в Prometheus, либо вручную перенести на новую систему. В enterprise-версии VictoriaMetrics доступны ruler-компоненты и встроенные механизмы для выполнения алерт-правил и агрегации. При этом Alertmanager можно использовать тот же, без необходимости изменений.

Чтобы избежать потерь при переходе на VictoriaMetrics, важно обеспечить параллельную работу Prometheus и нового хранилища: Prometheus продолжает обслуживать live-запросы, тогда как VictoriaMetrics аккумулирует долгосрочные данные. Не отключайте Prometheus, пока не убедитесь, что данные успешно передаются и история сохраняется в полном объёме. Обязательно проверьте состояние очередей remote_write, чтобы избежать потерь метрик. Создайте снапшот Prometheus на случай необходимости отката. Перед полноценной миграцией проведите тест на отдельном окружении с типовыми дашбордами и алертами, чтобы убедиться в стабильности и корректности работы всей цепочки.

Лучшие практики эксплуатации долгосрочного хранилища метрик

Политики хранения и downsampling

Сроки хранения метрик стоит настраивать разумно, и не хранить их «просто потому что можете».

Вот пример хорошей политики хранения:

• 13 месяцев — для сравнения год к году;
• 3 месяца — для сезонных анализов.

Все решения позволяют задать retention:

• Thanos — через Compactor (например, raw данные — 30 дней, downsample — 2 года).
• Cortex / Mimir — глобально или на уровне арендатора.
• VictoriaMetrics — флаг -retentionPeriod (можно отдельно для каждого источника/тенанта).

Особенно важно ограничивать retention в мультиарендных системах, чтобы один клиент не занимал всё хранилище.

---

Downsampling — это хранение старых данных с меньшим разрешением (например, 1 точка в 1 час).

Преимущества его использования:

• экономия диска;
• ускорение долгосрочных запросов.

Thanos поддерживает автоматический downsampling (по возрасту блоков).

Cortex / Mimir — пока не поддерживают автоматический downsampling, но можно использовать recording rules.

VictoriaMetrics — только в enterprise-версии.

Пример: метрики старше 30 дней можно агрегировать в daily average через правила записи.

---

Все решения используют сжатие, но убедитесь, что оно включено:

• Prometheus: флаг --storage.tsdb.wal-compression.
• Cortex / Mimir: используют LZ4/Zstd (по умолчанию).
• VictoriaMetrics: автоматически сжимает данные — следите за актуальностью версии для лучших алгоритмов.

Если компрессия резко ухудшилась — это может сигнализировать о всплеске кардинальности.

---

Высокая доступность и избыточность

Дублируйте компоненты

Thanos:

• Используйте 2 Prometheus-инстанса с разными --external-label.
• Thanos Querier автоматически их дедуплицирует.
• Компоненты Thanos (Store, Querier и т.п.) — stateless, можно дублировать (например, 2 Querier за load balancer).

Cortex / Mimir:

• Обязательно указывайте коэффициент репликации для ingestion (рекомендуется 3).
• Запускайте по 2+ инстанса всех компонентов: distributor, querier, frontend и т.д.
• Размещайте их в разных зонах отказа (например, разные AZ или узлы).

VictoriaMetrics:

• В одиночном режиме — нет отказоустойчивости.
• В кластерном — можно настраивать репликацию, но автоматического перезаполнения после потери узла нет.
• Лучше заранее иметь процедуры восстановления или просто запускать 2 VM-сервера и делать дедупликацию вручную (как с Prometheus).

Мониторинг состояния хранилища метрик

Мониторьте систему наблюдения

Каждое из решений экспортирует свои метрики — не забывайте мониторить само хранилище метрик:

Для Thanos:

• thanos_sidecar_upload_duration_seconds — если подскакивает, загрузка блоков тормозит.
• thanos_store_series — отслеживает объём данных в object storage.
• Метрики компактора — важны для следящих за downsampling и очисткой устаревших блоков.

Для Cortex / Mimir:

• Метрики очередей, задержек, использования памяти инжесторов.
• Примеры:

• если WAL слишком «отстаёт», это знак перегрузки;
• дистрибьюторы могут отклонять слишком много метрик — тоже повод тревожиться.

Всё это нужно подключить в Alertmanager — например, алерт «distributor отклонил слишком много sample'ов за последние 5 минут».

---

Проверка доступности данных

• Введите синтетические метрики — например, каждый Prometheus пишет heartbeat-метрику (up=1 раз в минуту).
• Затем с бэкенда проверяйте: если нет данных >5 минут — значит, проблема remote_write или сетью.

Также:

• В Thanos — алерт на отсутствие загрузки данных с sidecar.
• В Mimir / Cortex — проверка, что store-компоненты на месте и отвечают.

---

Аудит роста объёма хранилища

Следите, как быстро растёт количество временных рядов и объём данных. Внезапный всплеск — возможен из-за «взрыва кардинальности», например:

• кто-то добавил лейбл request_id (он уникален почти всегда),
• или метрика внезапно стала собирать миллионы новых комбинаций лейблов.

Используйте:

• В Cortex — экспорт кардинальности,
• В VictoriaMetrics — API по количеству рядов на метрику.

---

Мониторинг производительности запросов

Даже мощные кластеры могут тормозить на тяжёлых запросах.

Мониторьте:

• задержки запросов,
• нагрузку на CPU/память у компонентов querier.

Если много медленных запросов, возможно:

• они сканируют огромные блоки,
• лучше применить recording rules или включить кэширование.

Оптимизация запросов:

• Mimir / Cortex: используют query frontend — разбивает запросы по времени и кэширует результаты.
• Thanos: тоже имеет query frontend, можно использовать с Memcached.
• VictoriaMetrics: поддерживает агрегации, но требует настройки вручную.

Обслуживание и обновления (Maintenance & Upgrades)

Компактация и очистка старых данных

Thanos / Cortex:

Убедитесь, что компонент compactor запущен и работает стабильно.

Его задачи:

• downsampling;
• удаление устаревших блоков;
• объединение мелких блоков в более крупные.

Если compactor «завис», object storage может захламиться маленькими/старыми файлами. Настройте алерты на метрики компактора: длительность, отставание, ошибки.

---

Стратегия обновлений

Следите за релизами и release notes:

• Cortex / Mimir: порядок обновления компонентов может иметь значение.
• Thanos: обычно обратно совместим, но иногда API Store может поменяться.
• VictoriaMetrics: одиночный бинарник обновляется просто, в кластере — по типам компонентов: vminsert, затем vmstorage, затем vmselect.

Не обновляйте всё одновременно в проде — протестируйте на staging.
Прикатайте фиксированную версию после тестирования.

---

Бэкапы критичных данных

Prometheus / VictoriaMetrics (локальное хранилище):

• Настройте периодические снапшоты на S3 или в другое внешнее хранилище.
• VM умеет снимать снимки встроенно (vmbackup / vmrestore).

Thanos / Cortex (object storage):

• Обычно полагаются на устойчивость S3, GCS и т.д.
• Но иногда стоит включить версионирование bucket’ов или делать копии в другое хранилище (если метрики — критичные).

Если метрики используются в ML, для SLA или аудита — относитесь к ним как к боевым данным.

---

Выводы

Стартуйте с простой и надёжной конфигурации.

По мере роста нагрузки:

• внедряйте retention,
• пишите агрегированные правила,
• включайте HA-компоненты,
• не забывайте мониторить саму систему наблюдения.

Помните: хранилище метрик — это тоже продакшн-сервис.
Профилируйте запросы, кэшируйте, следите за расходами, обучайте команду писать экономные PromQL-запросы.