Медленный dashboard: когда выносить PromQL в recording rules

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

Recording rule периодически вычисляет PromQL и записывает результат как новые временные серии. Панель затем читает готовую метрику. Это переносит стоимость на регулярное вычисление и хранение, поэтому правило выбирают для устойчиво повторяющейся задачи, а не для любого однажды медленного запроса.

Сначала измерим повторение

Откройте инспектор медленной панели, запишите выражение, диапазон времени и шаг. Сравните с соседними панелями. Если они расходятся только фильтром cluster, а основная агрегация одна, есть кандидат для правила. Если задержка связана с гигантским диапазоном или лишними высококардинальными labels, сначала исправьте сам запрос.

Предположим, всем панелям нужна скорость запросов по cluster, service и status. Исходные серии дополнительно содержат instance и route. Сохраним только измерения, которые нужны будущим потребителям:

groups:
  - name: api-traffic
    interval: 30s
    rules:
      - record: service:http_requests:rate5m
        expr: sum by (cluster, service, status) (rate(http_requests_total[5m]))

Расчёт скорости выполняется до суммирования, чтобы сбросы счётчиков оставались различимы по исходным сериям. Имя результата сообщает, что внутри уже скорость и пятиминутное окно. После загрузки правила панель использует:

service:http_requests:rate5m{cluster="prod"}

Что теряется при предварительном расчёте

Label route отсутствует в сохранённом результате. Фильтрацию по отдельному маршруту придётся выполнять по исходным данным либо проектировать другое правило. Удаление labels уменьшает число записываемых серий, но одновременно фиксирует доступную детализацию. Сохранение всех исходных измерений может почти не уменьшить объём работы и добавить заметные расходы хранения.

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

Запись начинается после включения правила. Старый часовой участок автоматически не заполняется тем же результатом. Поэтому сразу после изменения dashboard длинный исторический диапазон может показать короткую линию. Сохраняйте возможность сравнить с исходным выражением на пересечении доступной истории.

Проверим правило и нагрузку

promtool check rules api-rules.yml

Команда проверяет файл правил, но не измеряет ускорение dashboard. После штатного подключения файла через rule_files посмотрите группу в интерфейсе Prometheus: есть ли ошибки оценки, сколько длится вычисление и успевает ли группа завершаться до следующего интервала. Правила одной группы выполняются последовательно; тяжёлое вычисление способно задержать следующие.

На одном времени сравните готовую серию с исходным выражением. Учитывайте момент оценки правила: произвольный instant-запрос «сейчас» может вычисляться на другом timestamp и немного отличаться. Для содержательного сравнения выберите время сохранённой точки, одинаковые labels и одинаковую выборку источников.

Затем повторите запрос dashboard на прежнем диапазоне. Сравните длительность, число возвращаемых серий и стоимость регулярного вычисления. Recording rule экономит повторную работу пользователей, но оплачивается даже тогда, когда dashboard никто не открывает. Редкий разовый анализ зачастую выгоднее оставить запросом к исходным метрикам.

Как сопровождать результат

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

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

Ещё по теме

• Many-to-many matching not allowed в PromQL: как сопоставить серии
• Scrape timeout в Prometheus: как различить медленный exporter и проблему сети

Продолжить изучение

Хотите построить мониторинг, который помогает находить причины сбоев? Метрики, дашборды и оповещения входят в программу «Prometheus и Grafana: мониторинг и observability».