Skip to main content

Rules engine

info

Перевод в процессе / Translation in progress. See русская версия.

Rules engine превращает поток логов и метрик в изменения состояний компонентов и инциденты. Движок сверяет входящие батчи с настроенными правилами и решает, открывать ли новый инцидент или подтверждать существующий.

LogRule​

LogRule — правило над потоком логов: оно проверяет события в окне оценки и решает, выполнилось ли условие триггера. Типовые триггеры: совпадение по pattern/regex, доля ошибок (error_rate) над порогом за окно, количество совпадающих записей за интервал.

Параметры защиты от шума:

  • consecutive_confirmations (integer) — сколько подряд подтверждений должно прийти, прежде чем движок откроет инцидент. Это и есть flap-guard: одиночное совпадение не эскалируется.
  • cooldown_seconds (duration, секунды) — минимальный интервал между повторными инцидентами по одной паре правило/компонент.

MetricRule​

MetricRule — правило над численными метриками компонента. Оно агрегирует точки в окне и сравнивает результат с порогом. Агрегаты: avg, max, p95, count. Правило задаёт окно, агрегат, оператор сравнения и порог (например, avg latency > 500ms за 5m).

Параметры защиты от шума такие же, как у LogRule:

  • consecutive_confirmations (integer) — число подряд подтверждённых окон до открытия инцидента.
  • cooldown_seconds (duration, секунды) — пауза между повторными срабатываниями по одной паре правило/компонент.

Событийная модель оценки​

Rules evaluation в Flaree — событийная. Обработчики LogRule и MetricRule подписаны на доменные события LogsBatchInserted и MetricsBatchInserted, которые публикуются после записи батча в хранилище. Каждая оценка выполняется в ответ на такое событие и только для затронутых правил.

Rules evaluation не управляется wall-clock таймером и не опрашивает хранилище по расписанию. Это решение зафиксировано в ADR 0008: оценка идёт по факту прихода данных, что исключает дрейф между записью и оценкой и снимает нагрузку от периодических сканов.

Защита от шума​

Flap-guard через consecutive_confirmations отсекает одиночные всплески: при значении 3 правило откроет инцидент только после трёх подряд подтверждённых окон. Cooldown через cooldown_seconds ограничивает частоту повторных инцидентов — новый по тому же правилу не откроется раньше, чем истечёт cooldown.

Практический совет: для шумных сигналов начинайте с consecutive_confirmations: 2–3 и cooldown_seconds порядка длины SLO-окна, и ослабляйте параметры, только если правило пропускает реальные проблемы.

Дальше​

За точными именами полей, эндпоинтами и схемами запросов/ответов смотрите API reference. Связанные концепции: квоты и retention и архитектура.