Зачем нужны recording rules в Prometheus и как они помогают с производительностью тяжёлых дашбордов и алертов?

Короткий ответ

Recording rule — это заранее вычисляемое и сохраняемое в TSDB PromQL-выражение (новая метрика), которое Prometheus пересчитывает по расписанию (evaluation_interval), а не при каждом открытии дашборда; это ускоряет часто используемые тяжёлые запросы (с агрегацией по множеству рядов) и делает алерты более предсказуемыми по времени выполнения.

Как это работает подробнее

без recording rule каждое открытие дашборда с тяжёлым запросом (например, histogram_quantile по агрегации сотен рядов за несколько часов) заставляет Prometheus пересчитывать всё "на лету" из raw-данных. Recording rule выполняет такой расчёт один раз за evaluation_interval (например, раз в минуту) и сохраняет результат как новую простую метрику, которую дашборд или алерт читает почти мгновенно, как обычный временной ряд.

Пример кода

config.yamlКопировать

groups:
  - name: checkout_recording_rules
    interval: 1m
    rules:
      - record: job:http_requests_error_rate:ratio5m
        expr: |
          sum(rate(http_requests_total{status=~"5..", job="checkout"}[5m]))
          /
          sum(rate(http_requests_total{job="checkout"}[5m]))

Что использовать на практике

• Практика. recording rules особенно полезны, когда одно и то же тяжёлое выражение используется в нескольких местах (дашборд + алерт на основе того же SLI), чтобы не пересчитывать его независимо и не рисковать небольшими расхождениями формулы между местами использования. Конвенция именования (level:metric:operations, например job:http_requests:rate5m) помогает отличать "сырые" метрики от производных recording rules.
• Практика. После применения правила новая метрика job:http_requests_error_rate:ratio5m доступна как обычный ряд; дашборд и алерт теперь используют её напрямую (job:http_requests_error_rate:ratio5m > 0.01) вместо повторения сложной формулы, и время отклика панели дашборда заметно снижается по сравнению с прямым запросом тяжёлой агрегации.

Подводные камни

• Частые ошибки. пытаться оптимизировать абсолютно все запросы через recording rules без реальной необходимости, усложняя конфигурацию и добавляя задержку между реальным событием и появлением агрегированного значения (на величину evaluation_interval); дублировать логику формулы в нескольких местах (дашборд и алерт считают "среднюю latency" чуть по-разному), из-за чего числа в разных местах расходятся и подрывают доверие к дашбордам.