Перейти к содержанию

Правила алертинга

До Grafana 13 правила алертинга были простыми: порог, триггер. Теперь многомерный движок поддерживает цепочки выражений и умеет создавать отдельный алерт для каждого ряда данных.

Устройство правила

Правило состоит из запросов (A) и выражений (B, C, D, E). Порядок жёсткий: A запрашивает данные из источника, B обрабатывает его результат, C обрабатывает результат B, и так далее. Каждое следующее звено получает на вход выход предыдущего.

A: PromQL-запрос       →  временной ряд
B: Reduce (Last)         →  одно число на каждый label
C: Math (Value * 100)    →  число в процентах
D: Threshold (> 80)      →  Alerting / Normal

Это не «порог и всё» — это пайплайн. Math может посчитать соотношение двух метрик. Resample — передискретизировать данные на другой шаг. Classic Condition — проверить старый добрый оператор больше/меньше.

Reduce

Каждое выражение Reduce применяет агрегатную функцию к временному ряду:

  • Last — последнее значение. Самое полезное для алертов, потому что оно отражает текущее состояние, а не среднее за окно.
  • Min, Max — минимум или максимум за окно.
  • Avg — среднее за окно. Полезно для алертов на всплески: если за 5 минут среднее > порога — значит это не одна точка-выброс, а устойчивый тренд.
  • Sum, Count — сумма или количество точек.

Результат Reduce — не временной ряд, а вектор: набор пар (label_set, значение). Дальше этот вектор проверяется на Threshold или обрабатывается Math.

Классическое условие

Одномерный алерт — один запрос, один порог:

# A: PromQL
avg by (host) (rate(http_requests_total{status=~"5.."}[5m]))

# B: Reduce — Last
# C: Threshold — > 10

Условие: последнее значение 5xx ошибок > 10 в секунду → алерт. Работает для сценария «у всего кластера показатель ошибок больше N».

Но есть проблема. Что если у 50 хостов ошибок нет, а 3 конкретных пуляют 500 ошибок в секунду? avg by (host) размажет 500 по 50 хостам, получится 30 — среднее кажется нормальным. Алерт не сработает, потому что среднее по всей группе — ниже порога.

Многомерный алертинг

Многомерный движок Grafana 13 решает эту проблему фундаментально. Если запрос возвращает данные с лейблами (например by (host)), Grafana не схлопывает все ряды в одно число. Вместо этого она создаёт отдельный экземпляр правила на каждый уникальный набор значений лейблов.

Запрос: rate(http_requests_total{status=~"5.."}[5m])
Лейблы в результате: host=server-01, server-02, ..., server-50

Grafana создаёт 50 независимых алертов:
  - alert_rule{host="server-01"} — проверяет только server-01
  - alert_rule{host="server-02"} — проверяет только server-02
  - ...

Три хоста с 500 ошибками — три отдельных firing-алерта. Остальные 47 хостов — тишина. Сигнал/шум идеальный: вы видите только те хосты, с которыми реально проблема.

Как это настраивается

Никак. Это поведение по умолчанию в 13.x. Если запрос возвращает несколько рядов данных с разными лейблами, алертинг автоматически становится многомерным.

Единственная настройка — поле Alert on в классическом условии: можно выбрать, проверять ли Each time series (каждый ряд отдельно) или The query result (один алерт на весь результат запроса). Второй вариант — осознанный выбор когда вам нужен один сводный алерт.

Пример: и процентиль

Более умный кейс — алертить на P99, а не на среднее:

A: histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))
# Без by-лейблов. Одно общее значение P99 latency.

B: Reduce — Last
C: Threshold — > 2 (секунды)

Один алерт на всё приложение: «P99 latency всего сервиса > 2 секунд». Здесь многомерность не нужна — latency это глобальная характеристика сервиса.

Выражения помимо Reduce и Threshold

Math

Вычисления между результатами разных запросов. Например, процент ошибок:

A: rate(http_requests_total{status=~"5.."}[5m])  # ошибки
B: rate(http_requests_total[5m])                     # все запросы
C: Math: $A / $B * 100                             # процент ошибок
D: Threshold: > 5

Math работает с $A, $B, $C как с переменными, ссылаясь на предыдущие выражения по их буквам.

Resample

Приводит данные к фиксированному интервалу. Полезно когда запрос возвращает неравномерный временной ряд, а алертинг ожидает регулярный шаг.

A: PromQL с неровным временным рядом
B: Resample: downsampling, интервал 1m, функция Last
C: Reduce: Last
D: Threshold: > 100

Classic Condition

Совместимость со старым форматом. Операторы: gt, lt, within_range, outside_range, has_no_value. Для новых правил обычно достаточно связки Reduce + Threshold.

Folder и Evaluation Group

Правила принадлежат папке. Папка содержит Evaluation Group — набор правил, которые оцениваются одновременно с одним интервалом.

Правила высокого приоритета (отказ сервиса, потеря данных) — интервал 1 минута, в группе не больше 5–7 правил. Бизнес-метрики («продажи упали на 20% за час») — интервал 15 минут.

Почему это важно: скорость оценки группы равна сумме длительностей всех запросов в группе. 20 правил по 5 секунд каждое = 100 секунд минимум на цикл. Интервал группы в 60 секунд при такой нагрузке невозможен — Grafana предупредит при сохранении.

Лучше разбить на 4 группы по 5 правил, чем на 1 группу из 20. Лучше оптимизировать запросы, чем раздувать интервал.

Для тех, кто переходит со старого алертинга

  1. NoData и Error. В старом алертинге состояние no_data и error были скрытыми. В новом — явные состояния правила. Настройте их: что делать если источник данных перестал отвечать? Игнорировать или стрелять алерт?

  2. Pending period. Промежуток между срабатыванием условия и переходом в Alerting. По умолчанию — 0. Поставьте хотя бы 1 минуту: это отсечёт ложные срабатывания от единичных выбросов, которые сами затухают через секунду.

  3. Keep firing. Опция, которая заставляет Grafana продолжать отправлять алерты каждые N минут, пока алерт в состоянии Alerting, даже если новых оценок нет. Критично для правил с long-interval evaluation: правило проверяется раз в час, но вы хотите получать напоминание каждые 10 минут.

  4. Сводка и Runbook URL. Grafana 13 автоматически подставляет в уведомление: название правила, метки, значения, время срабатывания, график со спайком, ссылку на дашборд. Убедитесь что поля Summary и Runbook URL заполнены — это первое что читает дежурный инженер в три часа ночи.

Советы

  • Reduce Last, не Max или Avg, для алертов с состоянием. Max при спайке CPU даст ложный алерт и тут же сбросит его. Last стабилен.
  • One rule, one service. Не пихайте в одно правило и rate(errors) и cpu_usage — разберите на два. Сработает алерт — и дежурный гадает: ошибки или CPU?
  • Preview перед запуском. Вкладка Preview показывает как правило сработало бы на исторических данных. Прогоните на дневных или недельных данных перед активацией.
  • Тишина — тоже сигнал. Если алерт никогда не срабатывает в течение месяца, либо всё идеально, либо порог завышен и вы пропускаете реальные проблемы. Раз в квартал пересматривайте пороги.