Prometheus recording rules
Мониторинг · Prometheus
Проблема
Дашборды в Grafana открываются по 8–15 секунд. При инциденте команда ждёт, пока график прогрузится, вместо того чтобы его смотреть. Причина — тяжёлые histogram_quantile + rate() + sum by пересчитываются каждый раз при каждом обновлении для каждого пользователя.
Решение
Вынести тяжёлые PromQL-запросы в recording rules. Prometheus пересчитывает их в фоне на заданном интервале и хранит как обычные метрики. Дашборд обращается к готовой серии — миллисекунды вместо секунд.
Пример
prometheus/rules/http.yaml:
groups:
- name: http-golden-signals
interval: 30s
rules:
- record: job:http_request_duration_seconds:p95_5m
expr: |
histogram_quantile(0.95,
sum by (job, le) (rate(http_request_duration_seconds_bucket[5m])))
- record: job:http_requests:rate_5m
expr: sum by (job) (rate(http_requests_total[5m]))
- record: job:http_errors:ratio_5m
expr: |
sum by (job) (rate(http_requests_total{status=~"5.."}[5m]))
/
sum by (job) (rate(http_requests_total[5m]))
Подключение в prometheus.yml:
rule_files:
- /etc/prometheus/rules/*.yaml
В Grafana теперь вместо большого выражения — одна строка:
job:http_request_duration_seconds:p95_5m{job="api"}
Нейминг — по официальной конвенции: level:metric:operations. Видно, что это recording rule, не «сырая» метрика.
Когда применять
- Дашборды, которые открывают больше одного человека одновременно.
- Алерты на сложные PromQL — рекордируй и алертируй на готовую серию, иначе алерт-менеджер будет считать заново.
- Формулы, которые появляются в 2+ дашбордах — один раз в recording, дальше используют все.
Источник
- dastergon/awesome-sre — раздел Monitoring
- bregman-arie/devops-resources
- Prometheus docs — Rules
Как применить у себя
- Найти в Grafana 3 самых медленных дашборда, посмотреть их PromQL-запросы.
- Вынести общие выражения в
rules/*.yaml. - Переписать панели дашбордов на готовые серии с префиксом
job:.... - Замерить время открытия до/после — должно быть в разы быстрее. Когда разница ощутима при инциденте — статус Изучено.