Конвейер обработки алертов

Конвейер — это путь, который проходит каждый входящий сигнал, прежде чем превратиться в уведомление дежурному. Прилетевшее событие не сразу становится алертом и не сразу кого-то будит: сначала по нему определяется источник, проверяется, не дубль ли это, вычисляется важность, затем применяются политики и сайленсы — и только потом, если сигнал прошёл все ступени, рождается алерт и запускается эскалация.

Эта статья даёт картину целиком. Детали каждой ступени — в своих разделах: Важность и её маппинг, Политики, Сайленсы, Как работает эскалация.

Путь сигнала целиком

Ниже — то же самое словами: что делает каждая ступень и почему она там, где она есть.

Приём

У сигнала два пути входа. AlertManager и Grafana отправляют данные на свой отдельный endpoint (Grafana шлёт payload, совместимый с форматом AlertManager); Zabbix и обобщённый webhook приходят на общий. По API-ключу из адреса определяется интеграция, а вместе с ней — команда-владелец, маршрут оповещения и правила определения важности.

Здесь же сигнал превращается в единицу обработки. У AlertManager и Grafana одна группа алертов сворачивается в один алерт (общие метки группы становятся метками этого алерта). У обобщённого webhook проще: один присланный сигнал — один алерт.

Отсюда важное следствие: границы группы задаёт отправитель, а значит, он же определяет, сколько алертов у вас появится и что с чем схлопнется. Для AlertManager это параметр group_by — как его выбрать, разобрано в Подключении AlertManager. Для обобщённого webhook ту же роль играет dedup_key — см. Подключение через webhook.

Развилка: не дубль ли это

Прежде чем заводить новый алерт, конвейер проверяет: нет ли уже активного алерта по этой же проблеме. Если есть — второй алерт не создаётся. Вместо этого у существующего растёт счётчик повторов, а принятые по нему ранее решения (важность, политики, сайленсы) не пересматриваются.

Активным считается незакрытый алерт. Как только он переходит в resolved, проблема считается завершённой — и если она возникнет снова, конвейер заведёт новый алерт с нуля, заново пройдя все ступени ниже.

Определение важности

По правилам severity mapping этой интеграции из меток сигнала вычисляется один из двух уровней — critical или warning. Если ни одно правило не сопоставилось, берётся значение по умолчанию. Эта важность поедет с алертом дальше и в самом конце определит, насколько настойчивой будет эскалация.

Почему уровней всего два и как «родные» шкалы источников переводятся в них — Важность и её маппинг.

Политики

Если сигнал — не дубль, он проходит через политики команды. Они применяются строго по порядку, сверху вниз; по умолчанию срабатывает первая совпавшая (это поведение меняет флаг продолжения цепочки). Условия политики опираются на метки сигнала через Label matchers (операторы «равно» / «не равно» / «присутствует» / «отсутствует»), его важность и время суток. Политика может:

• отбросить сигнал (drop) — на этом всё, алерт дальше не идёт;
• придержать (suppress, delay_until или Hold outside window) — поставить на паузу до заданного времени или до начала ближайшего рабочего окна, после чего алерт проснётся и пойдёт дальше;
• поднять или снизить важность — изменить уровень, с которым алерт отправится в эскалацию;
• добавить метки — обогатить алерт для последующих условий.

Подробно про условия, действия и порядок — раздел Политики.

Сайленсы

Если политики не отбросили и не придержали сигнал, проверяются сайленсы — точечные ручные подавления, которые заводят под конкретную ситуацию (например, на время плановых работ). Если алерт совпал с активным сайленсам по меткам, он ставится на паузу до конца окна подавления.

Метки на этой ступени — уже те, что получились после политик: добавленные действием Add labels участвуют в отборе наравне с пришедшими от источника.

Проверка эта — разовая, в момент создания алерта. Отсюда следствие, важное в разгар инцидента: сайленс, заведённый позже, на уже созданный алерт не подействует и его эскалацию не остановит — это делают Acknowledge или Resolve.

Подробно — раздел Сайленсы.

Создание

Сигнал, прошедший все ступени, становится алертом в статусе firing — «горит, требует внимания». Если же по пути политики или сайленсы решили придержать или отбросить его, алерт всё равно может появиться (на паузе или как отброшенный — для истории), но уведомлений по нему в этот момент не уходит.

Отброшенные (dropped) сигналы одной и той же проблемы тоже схлопываются в одну запись: повторный дроп той же группы не плодит новые строки, а наращивает счётчик повторов у уже существующего отброшенного алерта. Где смотреть отброшенные — см. Жизненный цикл ниже.

Эскалация

Маршрут оповещения — какая команда, какая политика эскалации и кто получатели — задаётся на интеграции, а не на политике. А вот насколько агрессивно пойдёт оповещение, решает важность алерта:

• warning — оповещается только первый шаг политики; дальше по цепочке эскалируют вручную;
• critical — вся лестница шагов проходится автоматически, по таймеру, пока алерт не подтвердят.

Как устроены шаги, смещения по времени и исчерпание цепочки — Как работает эскалация.

Уведомления

На последней ступени получателям, которых назначила эскалация, уходят уведомления по их каналам. С этого момента сигнал прошёл весь конвейер: из строчки данных он стал инцидентом, который кто-то увидел.

Жизненный цикл

Создание алерта — это ещё не конец истории. Дальше у него есть собственный жизненный цикл: он может ждать реакции, быть подтверждённым, закрытым — или какое-то время побыть на паузе.

Основная линия проста: firing → acknowledged (кто-то взял инцидент в работу) → resolved (проблема закрыта). Из firing есть боковые ветки: если алерт попал под сайленс или его придержала политика, он уходит на паузу («подавлен») или в ожидание («отложен»). Это не удаление — по истечении таймера такой алерт просыпается, снова становится firing и уходит в эскалацию, причём лестница шагов стартует заново.

Отдельно стоит отброшенный (dropped) алерт: его создаёт действие drop в политиках. Это конечное состояние — такой алерт остаётся только в истории и никого не оповещает. Повторные дропы той же проблемы не плодят записи, а наращивают счётчик повторов у одной строки. Смотреть отброшенные нужно в общем списке алертов: фильтр Status → Dropped (можно сузить фильтром интеграции), а в карточке такого алерта виден баннер «Dropped by policy» с именем сработавшей политики.