Политики уведомлений#
Политики уведомлений определяют, какие общие каналы уведомлений получают события для сервиса.
Они полезны, когда несколько маршрутов относятся к одному логическому сервису и должны использовать одинаковые правила уведомлений. Вместо копирования списков каналов в каждый маршрут назначьте сервису одну политику уведомлений и настройте маршрут на её использование.
Как работают политики уведомлений#
Политика уведомлений принадлежит одной команде и содержит упорядоченные правила.
Каждое правило определяет:
- типы событий, которые оно обрабатывает;
- необязательные матчеры алертов;
- один или несколько каналов уведомлений;
- продолжается ли вычисление после срабатывания правила;
- включено ли правило.
Правила вычисляются по позиции, начиная с наименьшей позиции.
Когда правило срабатывает, его каналы добавляются к целям доставки. Затем вычисление останавливается, если для этого правила не включён параметр Continue matching.
Дублирующиеся каналы удаляются перед доставкой.
Типы событий#
Правило может обрабатывать один или несколько типов событий:
| Тип события | Описание |
|---|---|
notification | Первичные уведомления об алертах и обновления алертов |
reminder | Напоминания о неподтверждённых алертах |
escalation | Уведомления об эскалации |
События подтверждения и разрешения не выбирают каналы повторно. IncidentRelay обновляет сообщения, созданные предыдущими доставками.
Это означает, что изменение или удаление политики уведомлений не мешает IncidentRelay обновить уже доставленное сообщение при подтверждении или разрешении алерта.
Матчеры#
Правила политики уведомлений используют тот же формат матчеров, что и правила сопоставления сервисов.
Общий редактор может предлагать имена и значения меток из недавних алертов команды. См. Матчеры алертов.
Пустой объект матчера соответствует любому алерту:
{}
Сопоставление по серьёзности:
{
"severity": "critical"
}
Сопоставление по приоритету:
{
"priority": ["p1", "p2"]
}
Сопоставление по меткам:
{
"labels": {
"environment": "production",
"namespace": {
"regex": "^payments-"
}
}
}
Сопоставление по полям сервиса или команды:
{
"fields": {
"service.slug": "payments-api",
"team.slug": "platform"
}
}
Правило-перехватчик (catch-all) обычно размещается последним, чтобы алерты, не обработанные более ранними правилами, всё же получали уведомление.
Режимы каналов маршрута#
Маршрут управляет тем, как IncidentRelay комбинирует собственные каналы с сопоставленной политикой уведомлений сервиса.
| Режим | Поведение |
|---|---|
route_only | Использовать только каналы, настроенные непосредственно на маршруте |
service_policy | Использовать только каналы, выбранные политикой уведомлений сервиса |
service_policy_plus_route | Комбинировать каналы политики сервиса и каналы маршрута |
Существующие маршруты по умолчанию используют route_only, поэтому включение политик уведомлений не изменяет их текущее поведение доставки.
Отсутствие неявного отката#
service_policy не откатывается к каналам маршрута.
Если у сопоставленного сервиса нет политики, политика отключена или ни одно включённое правило не соответствует событию, этот режим маршрута не выбирает общий канал.
Используйте service_policy_plus_route, когда каналы маршрута должны оставаться запасным вариантом или всегда должны получать событие.
Персональные правила уведомлений, включая правила браузерных push-уведомлений, вычисляются отдельно от политик общих каналов.
Настройка политики уведомлений#
- Откройте Services → Notification Policies.
- Выберите New policy.
- Выберите команду-владельца.
- Введите имя и необязательное описание.
- Сохраните политику.
- Откройте меню действий политики и выберите Rules.
- Добавьте правила в нужном порядке вычисления.
- Выберите типы событий, основные фильтры, расширенные условия и каналы для каждого правила.
- Сохраните каждое правило.
В редакторе правила доступны основные фильтры:
- приоритет;
- важность;
- источник алерта;
- сервис;
- окружение сервиса;
- критичность сервиса;
- tier сервиса.
Эти поля записываются в тот же объект matchers, который уже использует существующий matcher engine. Секция Расширенные условия остаётся для labels, annotations, полей маршрута и произвольных комбинаций. Основные фильтры, расширенные условия и выбранный набор условий объединяются через AND.
Включённое правило должно содержать хотя бы один канал уведомлений. Отключённое правило можно сохранить без каналов.
Назначение политики сервису#
- Откройте Services → Service Catalog.
- Создайте или отредактируйте сервис.
- Выберите значение в поле Notification policy.
- Сохраните сервис.
Сервис может использовать только включённую политику уведомлений, принадлежащую той же команде.
Политику, назначенную сервису, нельзя удалить. Удалите политику из всех сервисов, прежде чем удалять её.
Настройка маршрута#
- Откройте Routes.
- Создайте или отредактируйте маршрут.
- Выберите Notification channel source.
- Выберите один из вариантов:
- Route channels only;
- Service notification policy;
- Service policy + route channels.
- Сохраните маршрут.
Для режимов политики сервиса у группы алертов должен быть сервис. Сервис может поступать из сервиса маршрута по умолчанию или из совпадающего правила сервиса.
Пример: критические алерты и правило-перехватчик#
Правила политики:
- Critical alerts
- типы событий:
notification,reminder,escalation; - матчер:
{"severity": "critical"}; - каналы: Mattermost и Telegram;
- continue matching: отключено.
- Default alerts
- типы событий:
notification; - матчер:
{}; - каналы: Email;
- continue matching: отключено.
Критический алерт использует Mattermost и Telegram и останавливается на первом правиле. Некритический первичный алерт пропускает первое правило и использует Email.
Пример: комбинирование нескольких совпадающих правил#
Правила политики:
- Production alerts
- матчер:
{"labels": {"environment": "production"}}; - каналы: Operations Mattermost;
- continue matching: включено.
- Critical alerts
- матчер:
{"severity": "critical"}; - каналы: Emergency Telegram;
- continue matching: отключено.
Критический production-алерт получает доставку и через Mattermost, и через Telegram. Некритический production-алерт получает доставку только через Mattermost.
Отключённые ресурсы#
IncidentRelay игнорирует:
- отключённые политики;
- отключённые правила;
- отключённые или удалённые каналы.
Правило политики, которое не включает текущий тип события, пропускается.
Рекомендуемая настройка#
комбинироваться.
доставки.
события.
- Держите правило-перехватчик последним, когда каждое событие должно достигать общего канала.
- Используйте специфичные правила перед общими.
- Используйте
continue_matchingтолько тогда, когда каналы из нескольких правил должны - Используйте
service_policy, когда политика сервиса является авторитетной конфигурацией - Используйте
service_policy_plus_route, когда каналы уровня маршрута также должны получать - Тестируйте правила напоминаний и эскалаций отдельно от правил первичных уведомлений.