Прямой ответ
Recording rule — предвычисленный PromQL-запрос, результат которого Prometheus периодически записывает как новую метрику (group evaluation раз в N секунд — тяжёлый запрос считается один раз, а не на каждое открытие дашборда/алерт-цикл — метрики-основы); три класса задач: (1) ускорение (дашборд с 10 панелями × сложный запрос (rate+histogram_quantile+агрегация по кластеру — 2 секунды на панель) — открытие 20 секунд (Grafana-боль) — recording rule считает раз в 30 с — панель читает готовое — миллисекунды — SLO-дашборд — 30d-запросы без rules вообще не открываются); (2) алерты на производных (burn rate/SLO-ratio — SLO — алерт-правило читает агрегат — проще/стабильнее/дешевле — алерты); (3) сохранение агрегатов при downsampling (детали живы 15 дней, агрегаты — год (Mimir-retention — «история трендов» из recording-метрик — VM-downsampling — агрегаты переживают сырьё); синтаксис/структура: groups: - name: slo-api; interval: 30s; rules: - record: job:http_success:ratio_rate5m; expr: sum(rate(http_requests_total{code!~"5.."}[5m])) by (job) / sum(rate(http_requests_total[5m])) by (job) — файл правил подключается в prometheus.yml (rule_files — reload по SIGHUP/API — конфигурация — hot-reload — graceful); конвенция имён (Prometheus-стандарт): level:metric:operations (job:http_requests:rate5m — уровень агрегации:метрика:операции — «что это за метрика» читается из имени — нейминг-культура — без конвенции — зоопарк — техдолг); когда НЕ нужны (ошибки начинающих): простые запросы (rate одной метрики — Prometheus и так быстр — rule добавляет задержку данных (свежесть = interval — «последние 30 секунд» отсутствуют — real-time-панели страдают — метрики-свежесть); всё подряд (каждый rule — CPU/ряды — кардинальность — агрегат с by (instance) на 10k рядов — rule дороже запроса — агрегировать вверх, не «переписать один в один»); замена переменных дашборда (rule фиксирует агрегацию — Grafana-переменные (job/route — Grafana) требуют per-значение рядов — агрегат без лейбла — переменная мертва — баланс: rule с by (job, route) — переменные работают, кардинальность ограничена — дизайн); тестирование (promtool — обязательная практика): promtool test rules — unit-тесты правил (тестовые series + ожидаемые значения — «rule даёт 0.99 на таких данных» — CI — github-actions — тесты-культура — правило без теста — «сломал дашборд правкой» — классика), promtool check rules (синтаксис/семантика — до деплоя — CI-гейт); отладка: Prometheus UI → Status → Rules (last evaluation/duration/ошибки — «rule не считается» — видно — health-метрики правил (self-мониторинг — prometheus_rule_evaluation_duration_seconds — тяжёлые правила — ёмкость).
Практика: паттерны правил и производительность
Паттерны (проверенные): (1) SLO-метрики (job:sli_error:ratio_rate5m + оконные варианты (rate5m/rate30m/rate1h — multiwindow — алерты+дашборд из одного источника — согласованность цифр — «дашборд 99.9, алерт говорит 99.5» — разные запросы — rules устраняют расхождение — метрики-консистентность); (2) гистограммные процентили (histogram_quantile на raw-бакетах — тяжело на больших объёмах (гистограммы) — rule job:http_duration:p95_5m — дашборд p95 — готовое — 10 панелей × парк сервисов — экономия кратная); (3) агрегаты парка (суммы по кластерам/регионам — «весь парк в одной панели» — Mimir-глобальность — кросс-кластерный агрегат — rule на гейтвее — ёмкость-обзор); (4) business-метрики (заказы/минуту из app-метрик — продукт-дашборд (Grafana) — «сколько денег в минуту» — A/B-контекст — бизнес видит метрики, не логи — структура); производительность правил: interval-баланс (30s — стандарт; 1m для часовых окон; 5s — только для критичных алертов — CPU растёт — метрики-стоимость), группировка (тяжёлые правила — отдельная группа (evaluation параллелен по группам — «одно тяжёлое правило тормозит алерты» — разнесение — ёмкость), частичные вычисления (rule на rate5m, дашборд — avg по нему — не rule на 30d — каскад правил (5m→30m→1h — каждый шаг дешёв — recording-цепочки — антипаттерн: один rule с [30d] — пересчёт месяца каждые 30 с — Prometheus ляжет — окна в rules — короткие, длинные — из агрегатов — гистограммы-урок); жизненный цикл (правила — код): git-репозиторий правил (IaC — PR+ревью — ревью-чеклист), promtool-тесты в CI (github-actions), деплой — reload (configmap+reloader (Operator-контекст) — «правила правили в UI» — drift — git единствен (VM/vmalert — те же файлы — VM — переносимость), ревизия ежеквартально (какие rules реально читаются (Grafana-usage/метрики чтения — техдолг-ревизия — мёртвые правила — CPU в никуда — удаление — зависимости-аналогия).
Практический сценарий: SLO-дашборд с 40 секундами открытия → 1 секунда
Контекст: SLO-дашборд парка (12 сервисов — SLO-практика): 20 панелей, каждая — тяжёлый запрос (histogram_quantile + ratio + 30d-окна на отдельных панелях); симптомы: открытие 40 секунд (Prometheus CPU в потолок при открытии — метрики — prometheus_engine_query_duration_seconds — p99 8 с на запрос), алерт-цикл evaluation 45 с (правила алертов те же тяжёлые запросы — алерты — «алерт с опозданием» — evaluation-лаg); оптимизация (день работы): (1) анализ запросов (Grafana-панель → Inspect → Query — топ-3 паттерна запросов повторяются в 14 панелях — дублирование вычислений — профилирование-мышление — «сначала найти повторение, потом оптимизировать»); (2) recording rules (6 правил: job:sli_success:ratio_rate5m/30m, job:http_duration:p95_5m, job:sli_success:ratio_rate30d(из 30m-агрегата — каскад — не raw 30d), burn rate-основы — interval 30s/1m/5m по окнам — группа slo — отдельная от алерт-групп — структура); (3) панели — на агрегаты (20 панелей — из 6 метрик — PromQL панелей — простейшие (чтение/avg — PromQL — Grafana); (4) алерты — на агрегаты (burn rate-правила читают ratio-метрики — evaluation группы 45 с → 2 с — алерт-дизайн); (5) promtool-тесты (6 правил × позитив/негатив-кейсы (тесты — CI-гейт — github-actions — «правила правим с тестами»); (6) результат: открытие дашборда 40 с → 1.2 с (панели читают готовые ряды), Prometheus CPU при обзоре −60%, алерт-лаg 45→2 с (SLO-чувствительность — «алерт пришёл вовремя» — буквальное следствие rules); (7) попутные находки: три панели показывали разные p95 (три slightly разных запроса из трёх эпох — «цифры не сходились на ретро» — rules унифицировали — одно определение — одна цифра — метрики-консистентность — ADR — «определение p95 — в rule, не в панели»); (8) цена: +40 рядов на rule-метрики (кардинальность — копейки), свежесть −30 с (interval — «реалтайм-панель ошибок» осталась на raw-запросе — осознанно — баланс); вывод: recording rules — «кэш вычислений» мониторинга — инвестиция дня в скорость/консистентность/алерт-латентность — техдолг-профилактика — дашборд, который открывается, — дашборд, которым пользуются.
FAQ
Чем recording rules отличаются от alerting rules?
Механика общая (группы/evaluation/expr — один файл-формат), результат разный: recording — record: (результат → новая метрика в TSDB — «запомнить»), alerting — alert: (результат → условие алерта → Alertmanager (алерты) — «сообщить»); связь: alerting-правила читают recording-метрики (алерт на готовый агрегат — проще/быстрее/стабильнее — сценарий выше — «алерт с тяжёлым expr» — дублирует вычисление дашборда — rule — один источник); практика: пара «rule + alert на rule» — стандарт SLO-стека (SLO — ratio-метрика + burn-алерты — burn rate); «можно всё в алертах?» — нет: alerting не создаёт метрики — дашборды останутся тяжёлыми (Grafana) — роли разные — обе нужны — метрики-дизайн.
Как тестировать recording rules?
promtool test rules — unit-тестирование (тест-файл: input series (синтетические данные — значения в моменты времени) + expected outputs (что rule должен выдать — promql_expr_test — «на таких series — ratio = 0.99» — тесты-структура); кейсы обязательные: нормальные данные, границы (нулевой знаменатель — деление — NaN/отсутствие — поведение зафиксировано — метрики-качество), пропуски (дырки в series — rate-окно — гистограммы-окна); CI-интеграция: promtool check + test на каждый PR с правилами (github-actions — гейт — CI-скорость — секунды); проверка в проде: after-deploy сверка (rule-метрика против ручного запроса за окно — Grafana Explore — Grafana — «числа сошлись» — сверка-культура); anti-флаги: rule без теста правится «на глаз» (дашборд врёт молча — техдолг), тест только позитивный (границы — где баги — тесты-дисциплина); VM/vmalert — тот же promtool-формат тестов (VM — переносимость).
Когда recording rules вредят? Свежесть (rule-метрика отстаёт на interval + evaluation — real-time-панели/алерты на секундных окнах — raw-запросы — «алерт на rule с interval 5m» — опоздание на минуты — алерт-латентность); кардинальность-ловушки (rule с by (instance/user/...) на высококардинальной метрике — ряды ×N (кардинальность — агрегировать вверх (job/route) — «rule сохранил все лейблы» — польза ноль, ряды — есть); CPU-перегруз (сотни правил с частым interval — evaluation-очередь — «правила тормозят Prometheus» — метрики evaluation-duration — ёмкость — ревизия/разрежение — профили-культура); каскадные ошибки (rule A из rule B из rule C — цепочка evaluation-порядок (группы — порядок не гарантирован между группами — «A посчитался до обновления B» — лаг на цикл — длинные цепочки — избегать — один уровень агрегации + прямые данные); «правила вместо исправления метрик» (сырьё плохое (кардинальность/дубли) — rule-костыль — лечить источник — метрики-качество — rule — оптимизация, не маска — техдолг).
Как переносить recording rules между Prometheus, VM и Mimir? Формат совместим (Prometheus-файлы правил — VM/vmalert и Mimir-ruler принимают те же YAML (VM, Mimir — перенос = смена места evaluation); различия-нюансы: MetricsQL-расширения в expr — работают в VM, не в Prometheus/Mimir («улучшили правило расширением» — обратная миграция сломана — критичное — чистым PromQL — VM-FAQ); интервалы/лимиты (Mimir per-tenant rules-лимиты — Mimir — «100 правил на tenant» — квоты — планировать), интервал-минимумы (VM — свои дефолты — VM); деплой-механика разная (Prometheus — rule_files+reload, Mimir — ruler API/cortextool (конфигурация), VM — vmalert-флаги — но источник один — git (IaC — CI деплоит в целевую систему — github-actions — миграция хранилища — правила переезжают «бесплатно» — миграция-стратегия); тесты — promtool — переносимы (тесты — единый формат — инвестиция в тесты правил переживает смену бэкендов — выбор-контекст).
Источники: документация Prometheus (recording rules, practices/rules, unit testing) — ссылки в шапке.