Prometheus давно стал стандартом для сбора метрик в распределённых системах. В этой статье разберём, как организовать мониторинг, какие есть подводные камни и как строить понятные дашборды и оповещения.

Что такое Prometheus и почему он удобен

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

Ключевые преимущества — простота формата метрик, гибкий язык запросов PromQL и богатая экосистема экспортеров. Эти свойства делают систему удобной для быстрых итераций при поиске причин инцидентов.

Основные понятия

Метрики и их типы

В Prometheus метрики бывают четырёх видов: counter, gauge, histogram и summary. Counter накапливает только возрастает, gauge отражает значение, которое может как расти, так и падать.

Histogram и summary используются для сбора распределений времени и размеров. Histogram аггрегируется по корзинам (buckets), это полезно для построения SLO и расчёта p95, p99.

Экспозиция и формат

Приложение экспортирует метрики в текстовом формате по HTTP на /metrics. Важно соблюдать соглашения: имена метрик, единицы измерения и метки должны быть понятными и стабильными.

Небольшая ошибка в формате — лишняя точка или неверная метка — может помешать Prometheus корректно распарсить данные и привести к пропущенным метрикам.

Архитектура и компоненты

Prometheus server

Сервер периодически скрейпит конечные точки, хранит временные ряды в локальной TSDB и обрабатывает запросы PromQL. По умолчанию он хранит данные недолго; стоимость хранения растёт с картиной меток.

TSDB оптимизирована для быстрых вставок и сжатия данных, но при больших объёмах стоит рассмотреть remote_write в облачные хранилища.

Exporters и клиентские библиотеки

Exporters превращают вспомогательные системы в понятный Prometheus-формат: node_exporter для хоста, mysqld_exporter для БД, blackbox_exporter для проверки доступности. Для приложений используют клиентские библиотеки на Go, Java, Python и других языках.

Выбирая exporter, убедитесь, что метки ограничены и имена метрик соответствуют стилю вашего проекта.

Alertmanager и интеграции

Alertmanager собирает алерты из Prometheus, дедуплицирует их и отправляет уведомления в Slack, e-mail, PagerDuty и другие каналы. Правила алёртов пишутся в Prometheus и зависят от выражений PromQL.

Важно настроить маршрутизацию так, чтобы критические инциденты шли в быстрые каналы оповещения, а менее важные — в накопительные.

Как организовать метрики: правила и хорошие практики

Структура метрик во многом определяет удобство диагностики. Начинайте с базовых показателей: задержки, ошибки, загрузка CPU и память, пропускная способность.

Держите имена метрик читаемыми и описательными, используйте единицы измерения в суффиксах (например, requests_total, request_duration_seconds). Это облегчает понимание при чтении дашбордов и написании алёртов.

Избегайте взрыва кардинальности

Частая ошибка — добавлять в качестве меток значения с высокой уникальностью (идентификаторы пользователей, сессий). Это приводит к росту числа временных рядов и быстрому расходованию памяти.

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

PromQL: что важно знать

PromQL — мощный инструмент для выборки и агрегации метрик. С его помощью можно рассчитывать скорости, строить скользящие окна и вычислять процентные показатели.

Несколько полезных приёмов: функция rate() для счётчиков, histogram_quantile() для гистограмм, recording rules для сокращения тяжёлых вычислений. Recording rules сохраняют результаты запросов как новые временные ряды.

Примеры запросов

Простейшие выражения помогают быстро получить нужную картину: rate(http_requests_total[5m]) даст скорость запросов в секунду за последние 5 минут. Для p95 задержек можно использовать histogram_quantile(0.95, sum(rate(request_duration_seconds_bucket[5m])) by (le)).

Такие выражения удобно хранить и тестировать, прежде чем включать в алёрты или дашборды.

Хранение и масштабирование

По умолчанию Prometheus рассчитан на одиночный инстанс с локальным хранением. При росте нагрузки применяют горизонтальную федерацию и remote_write в специализированные бэкенды: Cortex, Thanos, VictoriaMetrics.

Федерация полезна для агрегации метрик с множества региональных инстансов, а remote_write позволяет хранить долгосрочные архивы и делать глобальные запросы по большому объёму данных.

Визуализация и дашборды

Grafana — стандартный инструмент для визуализации метрик Prometheus. Он позволяет собирать панели, использовать шаблоны и переменные для универсальных дашбордов.

Хороший дашборд фокусируется на трёх вещах: показатели работоспособности, признаки деградации и бизнес-метрики. Дополняйте графики аннотациями из CI/CD, чтобы связывать события релизов с изменениями метрик.

Настройка алертов: как сделать их полезными

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

Например, вместо алёрта на CPU > 90% используйте сочетание загрузки и ошибок в приложении, чтобы отличить пик нагрузки от деградации сервиса.

Отладка и типичные ошибки

Частые причины неправильных метрик — ошибки в экспозиции, неверные метки и часы на серверах. Начните с curl на /metrics, проверьте формат и корректность значений.

Если Prometheus выдает Out Of Memory или слишком медленно отвечает, проверьте кардинальность меток, частоту скрейпов и параметры compact/retention. Иногда достаточно убрать редкие метки или увеличить интервал скрепа.

Контроль качества метрик — чеклист

  • Проверьте имена и единицы измерения
  • Оцените кардинальность меток
  • Проведите нагрузочное тестирование при увеличении частоты скрейпов
  • Используйте recording rules для тяжёлых агрегаций

Личный опыт: несколько практических заметок

В одном проекте я столкнулся с тем, что дашборды постоянно тормозили. После анализа выяснилось, что в метках хранились session_id и user_id. Мы ввели агрегацию на стороне приложения и значительно снизили нагрузку на TSDB.

Ещё пример: для расчёта p99 мы сначала собирали summary, но столкнулись с рассинхронизацией. Перешли на histogram с фиксированными bucket, это дало воспроизводимые результаты и упростило алёртинг.

Короткое сравнение подходов масштабирования

Подход Плюсы Минусы
Федерация Простая агрегация региональных данных Ограниченная гибкость и сложная маршрутизация
Remote_write + Thanos/Cortex Горизонтальная масштабируемость и долгосрочное хранение Сложнее в настройке и требует дополнительных ресурсов
Вертикальное масштабирование Prometheus Минимальные изменения в архитектуре Ограничено ресурсами одного узла

Заключительные мысли

Prometheus даёт ясный, контрольный набор инструментов для мониторинга: простой экспорт метрик, мощная PromQL и богатая экосистема интеграций. Однако удобство приходит вместе с дисциплиной — нужно тщательно проектировать метрики и заботиться о кардинальности.

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

Используйте хранение recording rules, разумно настраивайте retention и не бойтесь переводить тяжёлые вычисления в remote backend, когда система растёт. Это позволит сохранить скорость отклика Prometheus и качество мониторинга при увеличении нагрузки.