Публикация была переведена автоматически. Исходный язык: Русский
Перед вами третья статья из серии материалов о том, как реанимировать систему мониторинга, когда Prometheus перестаёт справляться с объёмом данных и нагрузкой.
В первой части мы разобрали корневые причины проблем и типичные симптомы, во второй — изучили архитектурные варианты масштабирования и разгрузки Prometheus, в третьей - как организовать миграцию на долгосрочное хранилище так, чтобы не потерять данные и не нарушить работу алертов.
Первая часть находится здесь: https://astanahub.com/ru/blog/kak-spasti-monitoring-kogda-prometheus-zadykhaetsia-chast-1
Вторая часть находится здесь: https://astanahub.com/ru/blog/kak-spasti-monitoring-kogda-prometheus-zadykhaetsia-chast-2
Третья часть находится здесь: https://astanahub.com/ru/blog/kak-spasti-monitoring-kogda-prometheus-zadykhaetsia-chast-3.
Часть 4. Эксплуатация, устойчивость и оптимизация долгосрочного хранилища метрик
В этой заключительной части цикла мы разберём, как правильно сопровождать долгосрочное хранилище метрик в продакшне: от хранения и downsampling, до отказоустойчивости, контроля качества данных, алертинга и обновлений. Если предыдущие части помогали выбрать архитектуру и понять базовые принципы интеграции, то здесь мы сфокусируемся на практических рекомендациях, которые позволяют системе наблюдения жить долго, стабильно и предсказуемо.
Разумные политики хранения метрик и использование downsampling
Настройка сроков хранения
Хранить данные бесконечно — путь к необоснованным затратам и медленным запросам. Сроки retention должны быть продуманными и соответствовать целям анализа, например:
13 месяцев— чтобы сравнивать периоды год к году;
3 месяца— если нужны сезонные или циклические проверки.
Все популярные долгосрочные решения позволяют задавать retention:
Thanos — настройки Compactor (например, сырые данные — 30 дней, агрегаты — 2 года).
Cortex / Mimir — на уровне системы или конкретного арендатора.
VictoriaMetrics — флаг `-retentionPeriod`, можно указывать индивидуально.
В многоарендных системах ограничение retention критично, чтобы один тenant не занял весь диск.
Downsampling как инструмент оптимизации
Downsampling — это уменьшение разрешения старых метрик (например, одна точка в час). Он даёт:
- заметную экономию места;
- ускорение долгосрочных запросов.
Поддержка по решениям:
Thanos — автоматическая агрегация по возрасту блоков.
Cortex / Mimir — нет встроенного механизма, но можно заменить recording rules.
VictoriaMetrics — доступно только в enterprise-редакции.
Например, данные старше месяца можно преобразовывать в средние значения за сутки.
---
Компрессия данных и борьба с ростом объёмов
Все системы используют сжатие, но важно проверять, что оно включено и работает эффективно:
Prometheus: флаг `--storage.tsdb.wal-compression`.
Cortex / Mimir: встроенные LZ4/Zstd.
VictoriaMetrics: автоматическое сжатие (обновления улучшают алгоритмы).
Если степень сжатия резко ухудшилась — почти всегда это признак взрывной кардинальности.
---
Обеспечение высокой доступности компонентов
Дублирование в Thanos
* Используйте два Prometheus с разными `--external-label`, Querier сам произведёт дедупликацию.
* Все сервисы Thanos stateless, их легко масштабировать горизонтально через load balancer.
Повышение надёжности в Cortex / Mimir
* Репликация ingestion-компонентов (обычно 3).
* Минимум по два экземпляра distributor, querier, frontend.
* Разнос по разным зонам доступности.
VictoriaMetrics
* Одиночный режим не обеспечивает отказоустойчивость.
* В кластерном формате есть репликация, но нет автоматического восстановления после потери узла.
* Часто проще запускать два VM-сервера параллельно и выполнять дедупликацию.
---
Мониторинг состояния самого хранилища метрик
Важно контролировать не только сервисы, но и систему наблюдения.
Thanos
Следите за:
* длительностью загрузки блоков (`thanos_sidecar_upload_duration_seconds`);
* размером данных (`thanos_store_series`);
* состоянием Compactor (очистка и downsampling).
Cortex / Mimir
Ключевые сигналы:
* задержка ingestion;
* глубина очередей;
* memory pressure;
* высокий процент отвергнутых samples.
Настройте алерты вроде: *"distributor отклоняет слишком много метрик"*.
---
Проверка доступности данных
Ведите синтетические heartbeat-метрики — один раз в минуту.
Если в хранилище нет обновлений >5 минут — ищите проблемы в `remote_write` или сети.
Отдельно:
Thanos — следите за тем, что sidecar регулярно загружает блоки.
Mimir / Cortex— проверяйте доступность store-компонентов.
---
Контроль роста кардинальности
Взрыв количества временных рядов — самая частая причина роста затрат и тормозов.
Опасные случаи:
-добавили уникальные лейблы (например, `request_id`);
-изменилась структура метрик и появилось множество новых комбинаций.
Инструменты:
Cortex— экспорт уникальности временных рядов;
VictoriaMetrics — API для анализа количества рядов.
---
Производительность запросов
Даже мощные кластеры ограничены тяжёлыми запросами.
Следите за:
* latency запросов;
* CPU/Memory компонентов querier;
* количеством запросов, сканирующих весь storage.
Оптимизация:
* используйте recording rules для повторяющихся агрегатов;
* включайте query-frontend в Mimir / Cortex;
* применяйте кэш (например, Memcached для Thanos).
---
Recording rules и защита от тяжёлых запросов
Если вы часто делаете запрос вида:
```
sum(rate(http_requests_total[5m])) by (service)
```
на длительные промежутки — это перегружает хранилище.
Решение: переместить агрегацию в Ruler и сохранять значения заранее.
Поддержка:
Thanos— Thanos Ruler;
Cortex / Mimir — встроенные ruler-сервисы;
Prometheus — запись локально с последующей отправкой.
---
Борьба с высокой кардинальностью
Никогда не используйте метки:
- `session_uuid`,
-`request_id`,
-или любые timestamp-метки.
Это приводит к:
- ухудшению компрессии,
- росту диска,
- резкому замедлению запросов.
Что делать:
- хэшировать чувствительные лейблы;
- удалять ненужные через relabel_config;
- ограничивать количество рядов в Mimir / Cortex.
---
Downsampling старых данных и настройка шагов
Для старых данных достаточно крупного шага — например, 1 точка в 15 минут для диапазона в год.
- Thanos делает это автоматом;
- VM — только enterprise;
- Остальные — через recording rules.
Дополнительно: настройте `min step` в Grafana.
---
Осторожно: Prometheus Federation
Если вы используете Thanos / Cortex, то федерация нужна только для «живых» SLA-метрик.
Не стоит перетаскивать через федерацию весь объём данных — это дублирование и рост расходов.
---
Обслуживание и обновления
Компактация
Compactor в Thanos или Cortex отвечает за:
* downsampling;
* очистку старых блоков;
* объединение мелких блоков.
Если он стоит — object storage быстро захламляется.
Обновления версий
Следите за release notes.
Особенно аккуратно обновляйте:
* компоненты Cortex / Mimir (важен порядок);
* кластерную VictoriaMetrics (vminsert → vmstorage → vmselect).
Всегда тестируйте на staging.
Бэкапы
* Для Prometheus / VictoriaMetrics: снимайте snapshots (VM имеет встроенные инструменты).
* Для Thanos / Cortex: чаще всего достаточно надёжности S3/GCS, но версионирование bucket’ов крайне рекомендуется.
---
Итог: как жить с продакшн-наблюдением
Продакшн-мониторинг — это полноценный сервис. Чтобы он был стабильным:
1. Начинайте с простой архитектуры и увеличивайте её по мере нагрузки.
2. Настраивайте retention, чтобы данные не росли бесконтрольно.
3. Используйте recording rules и downsampling для тяжёлых запросов.
4. Разворачивайте HA-компоненты и следите за их работой.
5. Мониторьте саму систему мониторинга и не игнорируйте сигналы перегрузки.
6. Профилируйте запросы, включайте кэширование и бережно относитесь к PromQL.
---
В рамках всех четырёх материалов мы прошли путь от понимания проблем Prometheus до построения полноценной, долговечной и масштабируемой архитектуры наблюдения. Мы разобрали слабые места классического подхода, изучили варианты долговременного хранения и построили принципы грамотной эксплуатации. Теперь у вас есть целостное представление о том, как проектировать систему мониторинга, которая выдерживает рост нагрузки, сохраняет доступность данных и остаётся экономичной. Эти статьи дают фундамент, на который можно опираться при построении наблюдаемости в организациях любого размера. Главное — относиться к мониторингу как к продакшн-сервису и развивать его так же, как любой критичный продукт.
Перед вами третья статья из серии материалов о том, как реанимировать систему мониторинга, когда Prometheus перестаёт справляться с объёмом данных и нагрузкой.
В первой части мы разобрали корневые причины проблем и типичные симптомы, во второй — изучили архитектурные варианты масштабирования и разгрузки Prometheus, в третьей - как организовать миграцию на долгосрочное хранилище так, чтобы не потерять данные и не нарушить работу алертов.
Первая часть находится здесь: https://astanahub.com/ru/blog/kak-spasti-monitoring-kogda-prometheus-zadykhaetsia-chast-1
Вторая часть находится здесь: https://astanahub.com/ru/blog/kak-spasti-monitoring-kogda-prometheus-zadykhaetsia-chast-2
Третья часть находится здесь: https://astanahub.com/ru/blog/kak-spasti-monitoring-kogda-prometheus-zadykhaetsia-chast-3.
Часть 4. Эксплуатация, устойчивость и оптимизация долгосрочного хранилища метрик
В этой заключительной части цикла мы разберём, как правильно сопровождать долгосрочное хранилище метрик в продакшне: от хранения и downsampling, до отказоустойчивости, контроля качества данных, алертинга и обновлений. Если предыдущие части помогали выбрать архитектуру и понять базовые принципы интеграции, то здесь мы сфокусируемся на практических рекомендациях, которые позволяют системе наблюдения жить долго, стабильно и предсказуемо.
Разумные политики хранения метрик и использование downsampling
Настройка сроков хранения
Хранить данные бесконечно — путь к необоснованным затратам и медленным запросам. Сроки retention должны быть продуманными и соответствовать целям анализа, например:
13 месяцев— чтобы сравнивать периоды год к году;
3 месяца— если нужны сезонные или циклические проверки.
Все популярные долгосрочные решения позволяют задавать retention:
Thanos — настройки Compactor (например, сырые данные — 30 дней, агрегаты — 2 года).
Cortex / Mimir — на уровне системы или конкретного арендатора.
VictoriaMetrics — флаг `-retentionPeriod`, можно указывать индивидуально.
В многоарендных системах ограничение retention критично, чтобы один тenant не занял весь диск.
Downsampling как инструмент оптимизации
Downsampling — это уменьшение разрешения старых метрик (например, одна точка в час). Он даёт:
- заметную экономию места;
- ускорение долгосрочных запросов.
Поддержка по решениям:
Thanos — автоматическая агрегация по возрасту блоков.
Cortex / Mimir — нет встроенного механизма, но можно заменить recording rules.
VictoriaMetrics — доступно только в enterprise-редакции.
Например, данные старше месяца можно преобразовывать в средние значения за сутки.
---
Компрессия данных и борьба с ростом объёмов
Все системы используют сжатие, но важно проверять, что оно включено и работает эффективно:
Prometheus: флаг `--storage.tsdb.wal-compression`.
Cortex / Mimir: встроенные LZ4/Zstd.
VictoriaMetrics: автоматическое сжатие (обновления улучшают алгоритмы).
Если степень сжатия резко ухудшилась — почти всегда это признак взрывной кардинальности.
---
Обеспечение высокой доступности компонентов
Дублирование в Thanos
* Используйте два Prometheus с разными `--external-label`, Querier сам произведёт дедупликацию.
* Все сервисы Thanos stateless, их легко масштабировать горизонтально через load balancer.
Повышение надёжности в Cortex / Mimir
* Репликация ingestion-компонентов (обычно 3).
* Минимум по два экземпляра distributor, querier, frontend.
* Разнос по разным зонам доступности.
VictoriaMetrics
* Одиночный режим не обеспечивает отказоустойчивость.
* В кластерном формате есть репликация, но нет автоматического восстановления после потери узла.
* Часто проще запускать два VM-сервера параллельно и выполнять дедупликацию.
---
Мониторинг состояния самого хранилища метрик
Важно контролировать не только сервисы, но и систему наблюдения.
Thanos
Следите за:
* длительностью загрузки блоков (`thanos_sidecar_upload_duration_seconds`);
* размером данных (`thanos_store_series`);
* состоянием Compactor (очистка и downsampling).
Cortex / Mimir
Ключевые сигналы:
* задержка ingestion;
* глубина очередей;
* memory pressure;
* высокий процент отвергнутых samples.
Настройте алерты вроде: *"distributor отклоняет слишком много метрик"*.
---
Проверка доступности данных
Ведите синтетические heartbeat-метрики — один раз в минуту.
Если в хранилище нет обновлений >5 минут — ищите проблемы в `remote_write` или сети.
Отдельно:
Thanos — следите за тем, что sidecar регулярно загружает блоки.
Mimir / Cortex— проверяйте доступность store-компонентов.
---
Контроль роста кардинальности
Взрыв количества временных рядов — самая частая причина роста затрат и тормозов.
Опасные случаи:
-добавили уникальные лейблы (например, `request_id`);
-изменилась структура метрик и появилось множество новых комбинаций.
Инструменты:
Cortex— экспорт уникальности временных рядов;
VictoriaMetrics — API для анализа количества рядов.
---
Производительность запросов
Даже мощные кластеры ограничены тяжёлыми запросами.
Следите за:
* latency запросов;
* CPU/Memory компонентов querier;
* количеством запросов, сканирующих весь storage.
Оптимизация:
* используйте recording rules для повторяющихся агрегатов;
* включайте query-frontend в Mimir / Cortex;
* применяйте кэш (например, Memcached для Thanos).
---
Recording rules и защита от тяжёлых запросов
Если вы часто делаете запрос вида:
```
sum(rate(http_requests_total[5m])) by (service)
```
на длительные промежутки — это перегружает хранилище.
Решение: переместить агрегацию в Ruler и сохранять значения заранее.
Поддержка:
Thanos— Thanos Ruler;
Cortex / Mimir — встроенные ruler-сервисы;
Prometheus — запись локально с последующей отправкой.
---
Борьба с высокой кардинальностью
Никогда не используйте метки:
- `session_uuid`,
-`request_id`,
-или любые timestamp-метки.
Это приводит к:
- ухудшению компрессии,
- росту диска,
- резкому замедлению запросов.
Что делать:
- хэшировать чувствительные лейблы;
- удалять ненужные через relabel_config;
- ограничивать количество рядов в Mimir / Cortex.
---
Downsampling старых данных и настройка шагов
Для старых данных достаточно крупного шага — например, 1 точка в 15 минут для диапазона в год.
- Thanos делает это автоматом;
- VM — только enterprise;
- Остальные — через recording rules.
Дополнительно: настройте `min step` в Grafana.
---
Осторожно: Prometheus Federation
Если вы используете Thanos / Cortex, то федерация нужна только для «живых» SLA-метрик.
Не стоит перетаскивать через федерацию весь объём данных — это дублирование и рост расходов.
---
Обслуживание и обновления
Компактация
Compactor в Thanos или Cortex отвечает за:
* downsampling;
* очистку старых блоков;
* объединение мелких блоков.
Если он стоит — object storage быстро захламляется.
Обновления версий
Следите за release notes.
Особенно аккуратно обновляйте:
* компоненты Cortex / Mimir (важен порядок);
* кластерную VictoriaMetrics (vminsert → vmstorage → vmselect).
Всегда тестируйте на staging.
Бэкапы
* Для Prometheus / VictoriaMetrics: снимайте snapshots (VM имеет встроенные инструменты).
* Для Thanos / Cortex: чаще всего достаточно надёжности S3/GCS, но версионирование bucket’ов крайне рекомендуется.
---
Итог: как жить с продакшн-наблюдением
Продакшн-мониторинг — это полноценный сервис. Чтобы он был стабильным:
1. Начинайте с простой архитектуры и увеличивайте её по мере нагрузки.
2. Настраивайте retention, чтобы данные не росли бесконтрольно.
3. Используйте recording rules и downsampling для тяжёлых запросов.
4. Разворачивайте HA-компоненты и следите за их работой.
5. Мониторьте саму систему мониторинга и не игнорируйте сигналы перегрузки.
6. Профилируйте запросы, включайте кэширование и бережно относитесь к PromQL.
---
В рамках всех четырёх материалов мы прошли путь от понимания проблем Prometheus до построения полноценной, долговечной и масштабируемой архитектуры наблюдения. Мы разобрали слабые места классического подхода, изучили варианты долговременного хранения и построили принципы грамотной эксплуатации. Теперь у вас есть целостное представление о том, как проектировать систему мониторинга, которая выдерживает рост нагрузки, сохраняет доступность данных и остаётся экономичной. Эти статьи дают фундамент, на который можно опираться при построении наблюдаемости в организациях любого размера. Главное — относиться к мониторингу как к продакшн-сервису и развивать его так же, как любой критичный продукт.
Поделиться
