ITSumma 26 мая в 20:47

Какие есть альтернативы Prometheus, если для метрик его стало недостаточно

Средний

17 мин

4.9K

Блог компании ITSummaБазы данных*Серверная оптимизация*Серверное администрирование*Системное администрирование*

Туториал

Prometheus прекрасно подходит для краткосрочного мониторинга, но у этого решения есть свои ограничения по масштабу, и если вы столкнулись с высоким потреблением памяти/CPU, снижением скорости запросов или вам требуются уникальные лейблы вида user ID, то стоит подумать над внедрением альтернатив. На наш взгляд следующими после Prometheus в линейке стоят Thanos, Cortex, Mimir или VictoriaMetrics. Объективное, насколько это возможно, сравнение характеристик этих решений мы и проведем ниже.

СОДЕРЖАНИЕ

0. В каких случаях нужно задуматься о замене Prometheus
1. Обзор решений для долгосрочного хранения метрик
2. Сравнение решений: Thanos, Cortex, Mimir и VictoriaMetrics
3. Как выбрать подходящее решение

3.1. Что важнее: простота или масштаб?
3.2. Стоимость
3.3. Надёжность и высокая доступность
3.4. Насколько подходит по задачам?

4. Миграция с Prometheus на долгосрочное хранилище
5. Сохранение алертов и дашбордов
6. Как избежать потери данных при миграции

6.1. Параллельный запуск и проверка
6.2. Мониторинг очередей remote_write
6.3. Аккуратное отключение Prometheus
6.4. Резервное копирование
6.5. Тестирование

7. Лучшие практики эксплуатации долгосрочного хранилища метрик
8. Высокая доступность и избыточность
9. Мониторинг состояния хранилища метрик
10. Обработка долгосрочных запросов и типовые ошибки

10.1 Используйте recording rules для тяжёлых агрегаций
10.2 Не злоупотребляйте лейблами с высокой кардинальностью
10.3 Downsample старые точки данных
10.4 Осторожно с федерацией Prometheus

11. Обслуживание и обновления (Maintenance & Upgrades)
12. Итого. Как жить с продакшн-наблюдением

Прежде чем перейти к анализу четырех предлагаемых нами решений, стоит четко проговорить сценарии и точки, в которых Prometheus показывает себя хуже конкурентов. Список ниже можно использовать как чек-лист проверки актуальности использования Prometheus на вашем проекте, и если вы обнаружите пересечения в важных для себя точках — вам следует задуматься об обновлении. Ниже — содержание нашего туториала, который включает в себя все этапы, от обзора решений и до рекомендаций по обслуживанию и обновлениям новой системы.

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

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

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

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

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

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

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

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

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

Четыре самых популярных вариантов мы уже упоминали в начале текста. Это Thanos, Cortex, Mimir или VictoriaMetrics, именно о них пойдет речь далее.

1. Thanos

Расширение для Prometheus, добавляющее:

global view — единая точка входа для запросов к множеству изолированных серверов prometheus;
неограниченное хранение исторических данных (путём выгрузки в object storage);
опциональное сжатие и понижение детализации (downsampling) исторических данных.

Развёртывается рядом с существующими 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.
Улучшения по сравнению с Cortex:

лучшая масштабируемость,
более простая настройка (есть Helm-чарты),
оптимизированный движок запросов.

Полностью мультиарендный, используется Grafana Cloud.

4. VictoriaMetrics (VM)

Высокопроизводительная TSDB, которая может:

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

Поддерживает:

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

Особенности:

собственный формат хранения и компрессия для эффективности,
совместимость с PromQL (плюс расширения через MetricsQL),
поддержка различных протоколов получения данных (в т.ч. remote write и vmagent).

Сравнение решений: Thanos, Cortex, Mimir и VictoriaMetrics

Аспект	Thanos	Cortex	Grafana Mimir	VictoriaMetrics
Архитектура	Расширение к Prometheus. Sidecar рядом с каждым Prometheus. Данные выгружаются в object storage. Запросы агрегируются через Thanos Querier.	Микросервисный кластер. Prometheus шлёт данные через `remote_write`. Компоненты: дистрибьюторы, инжесторы, querier и т.д.	Почти идентично Cortex, но с улучшенной масштабируемостью и простотой. Готовые helm-чарты. Используется в Grafana Cloud.	Монолитный бинарник или кластерный режим. Поддерживает ingestion, storage, querying. Меньше компонентов, чем у Cortex/Mimir.
Сложность настройки	Умеренная. Начать можно с одного sidecar + querier. В продакшене потребуется 4–5 компонентов.	Высокая. Нужно развернуть 5–10 сервисов, кэш (Redis/Memcached), управлять масштабированием.	Высокая. Наследует сложность Cortex. Но Grafana помогает через helm-чарты и документацию.	Низкая (одиночный режим) / Умеренная (кластер). Один бинарник запускается просто. Кластер требует планирования, но компонентов мало.
Хранилище	Object storage (S3, GCS и т.д.). Прометеи хранят локально 2ч блоки, которые выгружаются в объектное хранилище.	Object storage или масштабируемая база. Использует block storage (как Thanos), иногда с индексами (DynamoDB и т.п.).	Только object storage (например, S3). Использует ту же блоковую схему, что и Cortex.	Локальный диск (HDD/SSD). Object storage — опционально (для бэкапов). Быстрые локальные чтения/записи, высокая компрессия.
Масштабируемость	Горизонтальное масштабирование через федерацию и offload в object storage. Прометеи могут быть шардированы.	Полностью горизонтальная. Нет bottleneck на Prometheus. Поддержка миллиардов метрик и мультиарендности.	Масштабируется как Cortex. Поддерживает огромные нагрузки, сотни миллионов метрик. Добавлен query scheduler.	Вертикальное и горизонтальное масштабирование. Один узел может обрабатывать миллионы точек. Кластерный режим — для масштабирования.
Высокая доступность	HA для Prometheus (пара инстансов) + deduplication в Thanos Querier. Компоненты Thanos можно дублировать.	Встроенная HA: репликация на ingestion (например, x3). Все сервисы могут масштабироваться и дублироваться.	То же, что у Cortex. Построен с учётом отказоустойчивости и дублирования всех компонентов.	В одиночном режиме — нет HA. В кластерном режиме — можно настроить репликацию, но нужно вручную восстанавливать при сбое.
Мультиарендность	Нет встроенной. Зависит от Prometheus (можно навесить `external_labels` для изоляции). Настоящей поддержки нет.	Есть из коробки. Каждой метрике приписывается tenant ID. Поддержка изоляции, политики, аутентификации.	Полная поддержка мультиарендности. Гибкая настройка — лимиты, политики, безопасная интеграция с Grafana.	Есть (AccountID/ProjectID), но продвинутые функции (лимиты, изоляция правил) — только в enterprise-версии. Есть метрики через tenant ID как в Cortex, выгрузка бекапов доступна в натив-формате. Поддерживает одиночный бинарник для простых случаев и кластерный режим для масштабируемости.

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

Обычно такие блоки выносят в конец подобных статей, давая размытый ответ вида «берите то, что вам больше подходит», но о выборе мы тоже поговорим более детально. Есть несколько параметров, на которые стоит обратить внимание в первую очередь. Это соответствие задачам по сложности и масштабу, стоимость и надежность.

Что важнее: простота или масштаб?

Если нужен минимум DevOps-обслуживания и умеренные объёмы данных, подойдут Thanos или VictoriaMetrics. Thanos расширяет уже существующий Prometheus без полной замены и не требует перестройки всей архитектуры. VictoriaMetrics проста в развёртывании (особенно в одиночном режиме) и чрезвычайно экономна по ресурсам — идеально, если нужна высокая производительность при малых издержках.

Если приоритет — масштабирование и мультиарендность, выбирайте Cortex или Mimir: Они поддерживают работу на уровне провайдера SaaS (миллиарды метрик, десятки команд), но требуют серьёзной инфраструктуры (десятки микросервисов, кэши и т.д.). Будьте внимательны, ведь это решение маленьким командам может быть избыточно, а это не тот случай, когда стоит жадничать.

Стоимость

Так как все упоминаемые решения опенсорсные, основную финансовую нагрузку создает инфраструктура, необходимая для их бесперебойной и эффективной работы. Конкретно нас интересуют типы хранилищ, необходимые для каждого из решений.

Thanos текущие запросы идут напрямую с прома, а исторические — с объектного хранилища (S3 и аналоги). Благодаря этому скорость работы увеличена, а обращения к S3 выполняются быстро за счет работы даунсемплинга.
Cortex / Mimir используют объектное хранилище (S3 и аналоги), которое в 2–8 раз дешевле на ГБ, чем SSD/блочное хранилище. Задержка доступа здесь выше, так как чтение S3 происходит медленнее, чем с диска, но для «редко читаемых» данных — подходит идеально.
VictoriaMetrics хранит данные на диске, что может быть дороже по хранилищу, но Сильно выигрывает в компрессии (в 2–10 раз лучше, чем TSDB Prometheus). При этом чтение с диска — моментальное и бесплатное (в отличие от чтения из S3, за которое нужно платить). Следовательно, если у вас часто выполняются запросы к метрикам, VM может быть дешевле в эксплуатации за счет экономии на оплате запросов к S3.

Промежуточный итог:

Для часто запрашиваемых метрик — VM с локальным диском может быть выгоднее, если запросов на самом деле много.
Для долгого хранения редко используемых данных — Thanos / Cortex / Mimir лучшее решение по цене.

Надёжность и высокая доступность

Пару слов стоит сказать о надежности и доступности. Конечно, немалую роль играет качество инфраструктуры и настройки, но есть и несколько неизменных факторов, о которых нужно упомянуть.

Все четыре варианта могут быть надёжными, но подходы к этой надёжности у них разные:

Thanos полагается на object storage (например, S3), который сам по себе надёжен — не нужно ничего реплицировать вручную.

Cortex / Mimir добавляют собственную репликацию данных поверх object storage (до трёх копий), повышая надёжность, но и потребление ресурсов.

VictoriaMetrics опирается на репликейшен факторы, хранилища шардируются между собой, а периодически запускается еще и процесс решардинга, чтобы уберечь вашу информацию. Если интересно, вот тут https://victoriametrics.com/blog/mimir-benchmark/ есть сравнение производительности VictoriaMetrics и Mimir.

Итого.

Если у вас сильная команда Kubernetes и нужны гарантии от потерь — берите Cortex / Mimir. Их работа через S3 и система репликации обеспечит наилучшую сохранность ваших данных.
Если хочется проще (и быстрее) — Thanos или VM с бэкапами достаточно (не забывайте про бекапы!).

Насколько подходит по задачам?

У вас много Prometheus по разным локациям и вы хотите объединённый взгляд — берите Thanos.
Нужно централизованное хранилище метрик для многих команд / клиентов — Cortex / Mimir.
Хотите снизить нагрузку на Prometheus или получить более эффективную TSDB — VictoriaMetrics может полностью заменить встроенное хранилище Prometheus (поддерживает PromQL и Grafana).

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

Определились, что будете использовать вместо Prometheus? Тогда этот блок о миграции поможет вам с планировкой переезда на каждое из упомянутых решений. Ну и самое важное в миграции — выполнить ее без потери данных и алертов.

Thanos

Самый простой способ интеграции:

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

Всё это работает без перезапуска Prometheus.
Dashboards и алерты остаются на старом Prometheus, пока вы не решите перенести их.
Можно продолжать использовать Prometheus для реального времени, а Thanos — для долгосрочных запросов.

Однако по нашему опыту тут есть небольшой нюанс. При использовании датасорса Thanos видны не только метрики долгосрочного хранилища, но и текущие метрики прома, то есть отдельный датасорс прома нам больше не нужен. Таким образом можно заменить его на Thanos, а в дашбордах, где он не вынесен в переменную, менять через экспорт-импорт. Оставлять дублирующие метрики или использовать только одну — решать уже вам.

Cortex / Mimir

Умеренная сложность:

Разворачивается новый кластер Cortex или Mimir.
Настраивается remote_write в Prometheus, и он начинает отправлять метрики в новый кластер.
Prometheus можно оставить как есть (для алертов и локальных запросов) или перевести в «облегчённый» режим.

Обычно Prometheus продолжает работать, пока новый кластер накапливает данные.
Миграция исторических данных — по желанию (можно не бэкапить старые данные).

Если необходимо перенести историю:

У Cortex есть инструмент thanosconvert, чтобы загружать старые TSDB-блоки Prometheus в object storage Cortex.
Это требует копирования файлов и больше усилий.

Часто выбирается подход «пусть данные со временем накопятся», а старый Prometheus работает в параллели, пока в нем окончательно не отпадет надобность.

VictoriaMetrics

Тоже умеренная сложность, но немного проще, чем Cortex/Mimir:

Разворачивается VM и настраивается remote_write с Prometheus.
Также можно полностью заменить Prometheus, используя vmagent, если хочется упростить систему.
Исторические данные переносить не обязательно, можно оставить Prometheus до истечения его retention.

Для миграции истории:

VictoriaMetrics предоставляет инструмент vmctl, который может загрузить данные из снапшота Prometheus.

Можно использовать VM только как удалённое хранилище, оставив Prometheus для алертов.
Можно переключить Grafana на VM — он поддерживает PromQL.

Главное правило при миграции: не выключайте Prometheus, пока не убедитесь, что данные и алерты перешли.
Обычно системы работают в параллели: Prometheus обрабатывает live-данные, новое хранилище — аккумулирует долгосрочные.

Сохранение алертов и дашбордов

Одно из главных преимуществ всех решений (Thanos, Cortex, Mimir, VictoriaMetrics) — поддержка PromQL, что позволяет переносить Grafana-дэшборды и алерты без изменений или с минимальной адаптацией.

Дашборды (Grafana)

Просто переключаете источник данных в Grafana с Prometheus на новый бэкенд (Thanos, Cortex, Mimir или VM).
Все панели должны работать без изменений, так как язык запросов тот же (PromQL), и имена метрик сохраняются.

Возможные нюансы:

Если вы используете внешние лейблы (external_labels), например, cluster=xyz, — их придётся учитывать в запросах или настройке источника в Grafana.
В многопользовательской среде может потребоваться учитывать tenant ID (в Cortex/Mimir).

Хорошая практика — запустить Grafana с двумя источниками данных и протестировать дашборды параллельно.

Алерты и правила агрегации (recording rules)

Пока Prometheus остаётся активным, он может продолжать оценивать алерты как раньше.
Большинство алертов основываются на коротких окнах (5–60 минут), поэтому можно не спешить с миграцией.

Если хотите перевести правила в новое хранилище:

Thanos имеет компонент Ruler, который может выполнять правила на глобальных данных.
Cortex / Mimir также имеют собственные Ruler-сервисы, которые работают в HA-режиме.
Вам нужно будет перенести Prometheus-правила в соответствующий формат в новое хранилище.

При миграции убедитесь, что выражения PromQL совместимы, особенно если использовались нестандартные функции Prometheus.

Alertmanager может остаться прежним — ему не важно, откуда приходят алерты, главное — PromQL-совместимый источник.

Перенос исторических данных (по необходимости)

Если вам обязательно нужно проанализировать старые метрики, заранее планируйте миграцию истории (с помощью vmctl, thanosconvert и т.д.). Часто достаточно просто сохранить старый Prometheus на время и постепенно переключить на новое хранилище.

Типичный подход в этой ситуации: «с этого дня мы начинаем сохранять данные надолго» — и этого хватает большинству команд и заказчиков.

Как избежать потери данных при миграции

Чтобы не потерять метрики при переходе на новое хранилище, следуйте этим рекомендациям:

Параллельный запуск и проверка

Запускайте новое хранилище вместе с Prometheus на протяжении какого-то времени — от пары часов до полного retention-периода (например, 15 дней).

Это даёт возможность:

проверить, что новое хранилище получает все данные;
обеспечить полное перекрытие временного окна (чтобы в Grafana не было «дыр»).

Пример: если retention у Prometheus — 15 дней, а вы начали отправлять данные в Cortex сегодня, то через 15 дней Cortex будет содержать всё то же, что и Prometheus — и даже больше.

Мониторинг очередей `remote_write`

При включении remote_write, следите за метриками, вроде:

remote_write_pending_samples — сколько метрик в очереди на отправку.

Если новое хранилище не справляется с потоком (редко, но бывает при высокой нагрузке), очередь может переполниться и привести к потере данных.

Настройте:

размер партий;
надёжное сетевое соединение;
по возможности — проводите миграцию в часы низкой активности.

Аккуратное отключение Prometheus (при необходимости и условии что все данные переправлены в другое хранилище типа Cortex/Mimir/VM)

Если решите выключить Prometheus полностью:

Не спешите!

Убедитесь, что:

все блоки выгружены в Thanos (можно вручную вызвать снапшот),
все данные из памяти/WAL отправлены в Cortex/Mimir/VM.

Иначе можно потерять последние несколько минут данных, находящихся только в памяти.

Резервное копирование

Перед отключением Prometheus сделайте снапшот его данных.

В случае ошибки вы сможете:

запустить Prometheus со снапшотом,
или импортировать данные в Thanos/Cortex/VM.

Thanos, например, может подключить Prometheus-снапшот как источник (store), и вытащить нужные данные даже спустя неделю.

Тестирование

Перед тем как запускать миграцию в проде:

протестируйте процесс в стенде — развёртывание, отправку метрик, запросы, алерты.
Убедитесь, что алерты срабатывают, дашборды корректны.

Прогоны на staging'е помогут поймать:

ошибки конфигурации (auth, TLS, tenant ID);
несовместимости запросов или неполадки в Grafana.

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

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

Настраивайте срок хранения разумно

Не храните метрики вечно «просто потому что можете». Это увеличивает стоимость и замедляет запросы.

Установите осознанные сроки хранения, например:

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

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

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

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

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

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: поддерживает агрегации, но требует настройки вручную.

Обработка долгосрочных запросов и типовые ошибки

Используйте recording rules для тяжёлых агрегаций

Если вы регулярно делаете запрос вроде:

promql

CopyEdit

sum(rate(http_requests_total[5m])) by (service)

на 30 дней — это очень дорого.

Вместо этого настройте правило записи, которое будет заранее сохранять такие значения (например, раз в час).
Все решения это поддерживают:

Thanos: компонент Ruler.
Cortex / Mimir: встроенные Ruler-микросервисы.
Можно и оставить это в Prometheus — и передавать результат через remote_write.

Не злоупотребляйте лейблами с высокой кардинальностью

Пример плохого лейбла: request_id, session_uuid, timestamp=now ()

Даже если хранилище умеет «много», оно не волшебное — взрыв кардинальности (миллионы уникальных временных рядов) перегрузит всё.

Это:

ухудшит сжатие;
увеличит использование диска;
замедлит запросы;
и просто съест систему.

Решения:

Хэшируйте лейблы (если они нужны).
Удаляйте ненужные при relabel_config.
Ограничивайте их — в Mimir / Cortex можно выставить лимиты на число временных рядов на метрику или арендатора.

Downsample старые точки данных

Уже упоминалось выше, но важно: чем старше данные — тем реже их нужно хранить. Например, метрики за последний год — хватит 1 точки в 15 минут.

Thanos делает это автоматически.

Остальные — либо через enterprise-функции (VM), либо с помощью правил агрегации.

Альтернатива: настроить min step в Grafana, чтобы шаг увеличивался автоматически при больших временных диапазонах.

Осторожно с федерацией Prometheus

Если вы используете Thanos или Cortex, не стоит продолжать активно использовать federation. Федерация может пригодиться только для:

«живых» агрегированных метрик;
SLA-метрик в реальном времени.

Но не нужно тащить всё через федерацию, если уже есть глобальное хранилище — это удвоит объём данных и усложнит архитектуру.

Обслуживание и обновления (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-запросы.

Хабы: