Recording Rules: предрасчёт метрик — Prometheus и

Recording Rules: предрасчёт метрик для производительности

«Предрасчёт — это кэш для метрик»

#Проблема сложных запросов

Сложные PromQL запросы могут быть дорогими:

# Тяжёлый запрос: агрегация по всем инстансам и эндпоинтам
sum by (service, endpoint) (rate(http_requests_total[5m]))

Проблемы:

Выполняется каждый раз при запросе
Нагрузка на CPU Prometheus
Медленные дашборды в Grafana
При алертинге — вычисляется каждые 30 секунд

Решение: Recording Rules — предрасчёт результата и сохранение как новой метрики.

#Что такое Recording Rules

Recording Rule — предварительно вычисленный запрос, результат которого сохраняется как новая метрика.

# Конфигурация правила
- record: service:http_requests:rate5m
  expr: sum by (service) (rate(http_requests_total[5m]))

Что происходит:

Prometheus вычисляет выражение каждые 15 секунд (evaluation_interval)
Результат сохраняется как новая метрика service:http_requests:rate5m
Вы используете готовую метрику вместо сложного запроса

Преимущества:

⚡ Быстрые запросы (готовая метрика)
💾 Меньше CPU Prometheus
📊 Быстрые дашборды
🔔 Эффективный алертинг

#Синтаксис Recording Rules

#Базовая структура

groups:
  - name: recording_rules
    interval: 30s  # Как часто вычислять (по умолчанию = evaluation_interval)
    rules:
      - record: <имя_новой_метрики>
        expr: <PromQL выражение>
        labels:
          <дополнительные_лейблы>

#Именование метрик

Конвенция: уровень:метрика:агрегация

- record: job:http_requests:rate5m
  expr: sum by (job) (rate(http_requests_total[5m]))

- record: instance:node_cpu:avg_rate5m
  expr: avg by (instance) (rate(node_cpu_seconds_total[5m]))

- record: service:http_latency:p95
  expr: histogram_quantile(0.95, sum by (service, le) (rate(http_duration_bucket[5m])))

Уровни:

job — агрегация по job
instance — по инстансу
service — по сервису
cluster — по кластеру

#Практические примеры

#Пример 1: Агрегация запросов по сервисам

До:

# Запрос в Grafana (выполняется каждый раз)
sum by (service) (rate(http_requests_total[5m]))

После:

# recording_rules.yml
- record: service:http_requests:rate5m
  expr: sum by (service) (rate(http_requests_total[5m]))

# Запрос в Grafana (готовая метрика)
service:http_requests:rate5m

#Пример 2: Перцентили latency

До:

# Дорогой запрос: histogram_quantile + aggregation
histogram_quantile(0.95, 
  sum by (service, le) (rate(http_request_duration_seconds_bucket[5m]))
)

После:

- record: service:http_latency:p95
  expr: histogram_quantile(0.95, 
    sum by (service, le) (rate(http_request_duration_seconds_bucket[5m]))
  )

- record: service:http_latency:p99
  expr: histogram_quantile(0.99, 
    sum by (service, le) (rate(http_request_duration_seconds_bucket[5m]))
  )

# Быстрый запрос
service:http_latency:p95

#Пример 3: Error rate по сервисам

- record: service:http_errors:rate5m
  expr: sum by (service) (rate(http_requests_total{status=~"5.."}[5m]))

- record: service:http_requests:rate5m
  expr: sum by (service) (rate(http_requests_total[5m]))

- record: service:http_error_rate:ratio5m
  expr: service:http_errors:rate5m / service:http_requests:rate5m

Использование:

# Процент ошибок по сервисам
service:http_error_rate:ratio5m * 100

#Пример 4: CPU usage по кластерам

- record: cluster:node_cpu:avg_usage
  expr: |
    100 - avg by (cluster) (
      rate(node_cpu_seconds_total{mode="idle"}[5m])
    ) * 100

#Пример 5: Availability по сервисам

- record: service:availability:ratio5m
  expr: |
    avg by (service) (up{job=~"api|worker"}) 
    * 100

#Recording Rules для алертинга

#Алерт с Recording Rule

До:

- alert: HighErrorRate
  expr: |
    sum by (service) (rate(http_requests_total{status=~"5.."}[5m]))
    /
    sum by (service) (rate(http_requests_total[5m]))
    > 0.05

После:

# Recording rules
- record: service:http_errors:rate5m
  expr: sum by (service) (rate(http_requests_total{status=~"5.."}[5m]))

- record: service:http_requests:rate5m
  expr: sum by (service) (rate(http_requests_total[5m]))

- record: service:http_error_rate:ratio5m
  expr: service:http_errors:rate5m / service:http_requests:rate5m

# Алерт
- alert: HighErrorRate
  expr: service:http_error_rate:ratio5m > 0.05

Преимущества:

Алерт вычисляется быстрее
Меньше нагрузка на Prometheus
Проще читать и отлаживать

#Иерархия Recording Rules

Создавайте многоуровневые правила:

groups:
  # Уровень 1: базовые агрегации
  - name: base_aggregations
    rules:
      - record: service:http_requests:rate5m
        expr: sum by (service) (rate(http_requests_total[5m]))
      
      - record: service:http_errors:rate5m
        expr: sum by (service) (rate(http_requests_total{status=~"5.."}[5m]))

  # Уровень 2: производные метрики
  - name: derived_metrics
    rules:
      - record: service:http_error_rate:ratio5m
        expr: service:http_errors:rate5m / service:http_requests:rate5m
      
      - record: service:http_requests:day_over_day
        expr: |
          service:http_requests:rate5m 
          / 
          service:http_requests:rate5m offset 1d

#Настройка Prometheus

#Добавление правил в конфигурацию

# prometheus.yml
global:
  scrape_interval: 15s
  evaluation_interval: 30s  # Как часто вычислять правила

rule_files:
  - "recording_rules/*.yml"
  - "alerting_rules/*.yml"

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

#Проверка правил

# Проверка синтаксиса
promtool check rules recording_rules.yml

# Загрузка в Prometheus (без перезапуска)
curl -X POST http://localhost:9090/-/reload

#Просмотр правил

В Prometheus UI:

Status → Rules
Видны все recording и alerting rules
Статус вычисления (последнее время, ошибки)

#Best practices

#1. Используйте осмысленные имена

# ПЛОХО
- record: http_aggregated
  expr: sum(rate(http_requests_total[5m]))

# ХОРОШО
- record: job:http_requests:rate5m
  expr: sum by (job) (rate(http_requests_total[5m]))

#2. Избегайте дублирования

Не создавайте правила для метрик, которые уже есть:

# ПЛОХО: дублирует существующую метрику
- record: http_requests_total
  expr: http_requests_total

#3. Группируйте по домену

# recording_rules/http.yml
- record: service:http_requests:rate5m
- record: service:http_latency:p95

# recording_rules/node.yml
- record: instance:node_cpu:avg
- record: instance:node_memory:usage

#4. Документируйте правила

- record: service:http_error_rate:ratio5m
  expr: service:http_errors:rate5m / service:http_requests:rate5m
  labels:
    description: "Error rate ratio by service"
    owner: "platform-team"

#5. Мониторьте сами правила

# Время вычисления правил
prometheus_rule_evaluation_duration_seconds

# Ошибки вычисления
prometheus_rule_evaluation_failures_total

# Последнее вычисление
prometheus_rule_last_evaluation_timestamp_seconds

#6. Не переусердствуйте

Создавайте правила только для:

Часто используемых запросов
Дорогих вычислений
Метрик для алертинга

Не нужно для:

Одноразовых запросов
Простых метрик (уже быстрых)

#Отладка проблем

#Проблема: правило не вычисляется

Причины:

Синтаксическая ошибка в выражении
Метрики не существуют
Неправильный путь к файлу правил

Решение:

# Проверка синтаксиса
promtool check rules recording_rules.yml

# Проверка в Prometheus UI
Status → Rules → ищите ошибки

#Проблема: метрика не появляется

Причины:

evaluation_interval слишком большой
Выражение возвращает пустой результат

Решение:

# Уменьшите интервал для группы
- name: recording_rules
  interval: 15s  # Вместо 30s
  rules:
    - record: ...

#Проблема: слишком много метрик

Recording Rules создают новые метрики — не злоупотребляйте.

Решение:

Удаляйте неиспользуемые правила
Агрегируйте на более высоком уровне (service вместо instance)

Recording Rules: предрасчёт метрик для производительности

«Предрасчёт — это кэш для метрик»

#Проблема сложных запросов

Сложные PromQL запросы могут быть дорогими:

# Тяжёлый запрос: агрегация по всем инстансам и эндпоинтам
sum by (service, endpoint) (rate(http_requests_total[5m]))

Проблемы:

Выполняется каждый раз при запросе
Нагрузка на CPU Prometheus
Медленные дашборды в Grafana
При алертинге — вычисляется каждые 30 секунд

Решение: Recording Rules — предрасчёт результата и сохранение как новой метрики.

#Что такое Recording Rules

Recording Rule — предварительно вычисленный запрос, результат которого сохраняется как новая метрика.

# Конфигурация правила
- record: service:http_requests:rate5m
  expr: sum by (service) (rate(http_requests_total[5m]))

Что происходит:

Prometheus вычисляет выражение каждые 15 секунд (evaluation_interval)
Результат сохраняется как новая метрика service:http_requests:rate5m
Вы используете готовую метрику вместо сложного запроса

Преимущества:

⚡ Быстрые запросы (готовая метрика)
💾 Меньше CPU Prometheus
📊 Быстрые дашборды
🔔 Эффективный алертинг

#Синтаксис Recording Rules

#Базовая структура

groups:
  - name: recording_rules
    interval: 30s  # Как часто вычислять (по умолчанию = evaluation_interval)
    rules:
      - record: <имя_новой_метрики>
        expr: <PromQL выражение>
        labels:
          <дополнительные_лейблы>

#Именование метрик

Конвенция: уровень:метрика:агрегация

- record: job:http_requests:rate5m
  expr: sum by (job) (rate(http_requests_total[5m]))

- record: instance:node_cpu:avg_rate5m
  expr: avg by (instance) (rate(node_cpu_seconds_total[5m]))

- record: service:http_latency:p95
  expr: histogram_quantile(0.95, sum by (service, le) (rate(http_duration_bucket[5m])))

Уровни:

job — агрегация по job
instance — по инстансу
service — по сервису
cluster — по кластеру

#Практические примеры

#Пример 1: Агрегация запросов по сервисам

До:

# Запрос в Grafana (выполняется каждый раз)
sum by (service) (rate(http_requests_total[5m]))

После:

# recording_rules.yml
- record: service:http_requests:rate5m
  expr: sum by (service) (rate(http_requests_total[5m]))

# Запрос в Grafana (готовая метрика)
service:http_requests:rate5m

#Пример 2: Перцентили latency

До:

# Дорогой запрос: histogram_quantile + aggregation
histogram_quantile(0.95, 
  sum by (service, le) (rate(http_request_duration_seconds_bucket[5m]))
)

После:

- record: service:http_latency:p95
  expr: histogram_quantile(0.95, 
    sum by (service, le) (rate(http_request_duration_seconds_bucket[5m]))
  )

- record: service:http_latency:p99
  expr: histogram_quantile(0.99, 
    sum by (service, le) (rate(http_request_duration_seconds_bucket[5m]))
  )

# Быстрый запрос
service:http_latency:p95

#Пример 3: Error rate по сервисам

- record: service:http_errors:rate5m
  expr: sum by (service) (rate(http_requests_total{status=~"5.."}[5m]))

- record: service:http_requests:rate5m
  expr: sum by (service) (rate(http_requests_total[5m]))

- record: service:http_error_rate:ratio5m
  expr: service:http_errors:rate5m / service:http_requests:rate5m

Использование:

# Процент ошибок по сервисам
service:http_error_rate:ratio5m * 100

#Пример 4: CPU usage по кластерам

- record: cluster:node_cpu:avg_usage
  expr: |
    100 - avg by (cluster) (
      rate(node_cpu_seconds_total{mode="idle"}[5m])
    ) * 100

#Пример 5: Availability по сервисам

- record: service:availability:ratio5m
  expr: |
    avg by (service) (up{job=~"api|worker"}) 
    * 100

#Recording Rules для алертинга

#Алерт с Recording Rule

До:

- alert: HighErrorRate
  expr: |
    sum by (service) (rate(http_requests_total{status=~"5.."}[5m]))
    /
    sum by (service) (rate(http_requests_total[5m]))
    > 0.05

После:

# Recording rules
- record: service:http_errors:rate5m
  expr: sum by (service) (rate(http_requests_total{status=~"5.."}[5m]))

- record: service:http_requests:rate5m
  expr: sum by (service) (rate(http_requests_total[5m]))

- record: service:http_error_rate:ratio5m
  expr: service:http_errors:rate5m / service:http_requests:rate5m

# Алерт
- alert: HighErrorRate
  expr: service:http_error_rate:ratio5m > 0.05

Преимущества:

Алерт вычисляется быстрее
Меньше нагрузка на Prometheus
Проще читать и отлаживать

#Иерархия Recording Rules

Создавайте многоуровневые правила:

groups:
  # Уровень 1: базовые агрегации
  - name: base_aggregations
    rules:
      - record: service:http_requests:rate5m
        expr: sum by (service) (rate(http_requests_total[5m]))
      
      - record: service:http_errors:rate5m
        expr: sum by (service) (rate(http_requests_total{status=~"5.."}[5m]))

  # Уровень 2: производные метрики
  - name: derived_metrics
    rules:
      - record: service:http_error_rate:ratio5m
        expr: service:http_errors:rate5m / service:http_requests:rate5m
      
      - record: service:http_requests:day_over_day
        expr: |
          service:http_requests:rate5m 
          / 
          service:http_requests:rate5m offset 1d

#Настройка Prometheus

#Добавление правил в конфигурацию

# prometheus.yml
global:
  scrape_interval: 15s
  evaluation_interval: 30s  # Как часто вычислять правила

rule_files:
  - "recording_rules/*.yml"
  - "alerting_rules/*.yml"

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

#Проверка правил

# Проверка синтаксиса
promtool check rules recording_rules.yml

# Загрузка в Prometheus (без перезапуска)
curl -X POST http://localhost:9090/-/reload

#Просмотр правил

В Prometheus UI:

Status → Rules
Видны все recording и alerting rules
Статус вычисления (последнее время, ошибки)

#Best practices

#1. Используйте осмысленные имена

# ПЛОХО
- record: http_aggregated
  expr: sum(rate(http_requests_total[5m]))

# ХОРОШО
- record: job:http_requests:rate5m
  expr: sum by (job) (rate(http_requests_total[5m]))

#2. Избегайте дублирования

Не создавайте правила для метрик, которые уже есть:

# ПЛОХО: дублирует существующую метрику
- record: http_requests_total
  expr: http_requests_total

#3. Группируйте по домену

# recording_rules/http.yml
- record: service:http_requests:rate5m
- record: service:http_latency:p95

# recording_rules/node.yml
- record: instance:node_cpu:avg
- record: instance:node_memory:usage

#4. Документируйте правила

- record: service:http_error_rate:ratio5m
  expr: service:http_errors:rate5m / service:http_requests:rate5m
  labels:
    description: "Error rate ratio by service"
    owner: "platform-team"

#5. Мониторьте сами правила

# Время вычисления правил
prometheus_rule_evaluation_duration_seconds

# Ошибки вычисления
prometheus_rule_evaluation_failures_total

# Последнее вычисление
prometheus_rule_last_evaluation_timestamp_seconds

#6. Не переусердствуйте

Создавайте правила только для:

Часто используемых запросов
Дорогих вычислений
Метрик для алертинга

Не нужно для:

Одноразовых запросов
Простых метрик (уже быстрых)

#Отладка проблем

#Проблема: правило не вычисляется

Причины:

Синтаксическая ошибка в выражении
Метрики не существуют
Неправильный путь к файлу правил

Решение:

# Проверка синтаксиса
promtool check rules recording_rules.yml

# Проверка в Prometheus UI
Status → Rules → ищите ошибки

#Проблема: метрика не появляется

Причины:

evaluation_interval слишком большой
Выражение возвращает пустой результат

Решение:

# Уменьшите интервал для группы
- name: recording_rules
  interval: 15s  # Вместо 30s
  rules:
    - record: ...

#Проблема: слишком много метрик

Recording Rules создают новые метрики — не злоупотребляйте.

Решение:

Удаляйте неиспользуемые правила
Агрегируйте на более высоком уровне (service вместо instance)