Уведомления

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

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

Схема работы выглядит следующим образом:

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

Точки контакта содержат настройки для отправки уведомлений, в том числе по электронной почте, в Slack, OnCall, через вебхуки и их сообщения.

Контактная точка – это список интеграций, каждая из которых отправляет сообщение определенному адресату.

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

Сначала следует создать контактную точку и протестировать уведомления. Затем нужно настроить правило оповещения так, чтобы уведомления отправлялись либо в контактную точку, либо через политики уведомлений.

Правила уведомления являются основой комплексной системы оповещения. Они обеспечивают гибкий и эффективный способ направления оповещений в различные контактные точки, помогая снизить количество отвлекающих оповещений и гарантируя, что ни одно оповещение не будет пропущено.

Дерево политики уведомлений (рисунок 80) отвечает за:

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

Рисунок 80 — Политика уведомлений

Каждая политика уведомлений (рисунок 81) решает определенные задачи:

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

Рисунок 81 — Политика уведомлений

Когда в ИТ-инфраструктуре происходит сбой, система оповещений может легко сгенерировать сотни или даже тысячи оповещений (уведомлений). Несколько правил оповещений часто срабатывают одновременно. Кроме того, каждое правило оповещения может сгенерировать несколько оповещений.

Группировка уведомлений об оповещениях обычно необходима для того, чтобы не перегружать почтовый ящик организации оповещениями. Группировка объединяет похожие оповещения за определенный период в одно уведомление.

Использование группировки уведомлений:

Labels (Метки) – группировка экземпляров оповещений одного и того же типа с помощью меток;
Timing options (Параметры таймера) – ожидание заданного времени перед отправкой уведомления, чтобы сгруппировать входящие оповещения.

"Alerting (Оповещения)" предоставляет расширенные возможности уведомлений, которые пригодятся и команде по мере совершенствования первоначальной системы оповещений.

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

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

Архитектура

"Alerting (Оповещения)" основана на модели Prometheus для разработки систем оповещения. Ее архитектура отделяет генератор оповещений от менеджера оповещений (известного как Alertmanager) для повышения масштабируемости и производительности (рисунок 82).

Рисунок 82 — Архитектура Alerting

Подсистема предоставляет собственный менеджер оповещений, расширяющий возможности менеджера оповещений Prometheus, для управления оповещениями и их отправки. Если используется менеджер оповещений Prometheus или Mimir, можно настроить оповещения Подсистемы для управления ими и обработки уведомлений для оповещений, управляемых Подсистемой.

Контактные точки

Контактные точки содержат настройки для отправки уведомлений об оповещениях. Можно назначить контактную точку в правилах оповещения или в параметрах политики уведомлений.

Контактная точка включает в себя одну или несколько интеграций для отправки уведомлений, например:

Alertmanager;
Amazon SNS;
Cisco Webex Teams;
DingDing;
Discord;
Email;
Google Chat;
Grafana Oncall;
Kafka REST Proxy;
Line;
Microsoft Teams;
MQTT;
Opsgenie;
Pagerduty;
Pushover;
Sensu Go;
Slack;
Telegram;
Threema Gateway;
VictorOps;
Webhook;
WeCom.

Например, контактная точка может содержать интеграцию с Pagerduty, интеграцию с электронной почтой и Slack или интеграцию с Pagerduty, интеграцию со Slack и две интеграции с электронной почтой. Также можно настроить контактную точку без интеграции, в этом случае уведомления не будут отправляться.

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

Политики уведомления

Политики уведомлений позволяют гибко настраивать обработку уведомлений и сводить к минимуму количество оповещений.

С помощью сопоставления меток экземпляры оповещений направляются в политики уведомлений. Затем политика уведомлений может объединить несколько экземпляров оповещений в одно уведомление и отправить его контактному лицу (рисунок 83).

Рисунок 83 — Схема работы политики уведомлений

Политики уведомлений представляют собой не список, а скорее древовидную структуру:

корнем дерева политики уведомлений является "Default notification policy (Политика уведомлений по умолчанию)";
у каждой политики могут быть дочерние политики;
каждая политика может иметь родственные политики, имеющие один и тот же родительский и иерархический уровень.

Каждая политика состоит из набора сопоставлений меток (0 или более), которые определяют, какие оповещения интересны или неинтересны для обработки. Политика сопоставления — это политика уведомлений с сопоставлениями меток, которые соответствуют меткам экземпляра оповещения (рисунок 84).

Рисунок 84 — Сопоставление экземпляров оповещений с политиками уведомлений

Чтобы определить, какие политики уведомлений применяются к конкретному оповещению, Подсистема ищет соответствующие политики, начиная с вершины дерева – с политики уведомлений по умолчанию.

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

По умолчанию после обнаружения подходящей политики Подсистема не продолжает поиск родственных политик. Если требуется, чтобы родственные политики одной подходящей политики также обрабатывали экземпляр оповещения, следует включить опцию "Continue matching siblings (Продолжение поиска родственных политик)" для конкретной подходящей политики.

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

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

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

По умолчанию дочерняя политика наследует следующие свойства уведомлений от родительской политики:

контактная точка;
параметры группировки;
варианты выбора времени.

Затем каждая политика может перезаписать эти свойства, если это необходимо.

Наследование свойств уведомлений в сочетании с процессом маршрутизации – эффективный способ группировки связанных уведомлений и обработки конкретных случаев с помощью дочерних политик.

Групповые уведомления

Группировка в "Alerting (Оповещения)" позволяет объединять релевантные оповещения в меньшее количество уведомлений. Это особенно важно, если уведомления отправляются первым лицам, например дежурным инженерам, которым может быть сложно обрабатывать большое количество уведомлений за короткий промежуток времени. В некоторых случаях это может негативно сказаться на способности первых лиц реагировать на инцидент. Например, при крупном сбое, при котором многие приложения не работают, группировка может стать разницей между получением 1 телефонного звонка и 100 телефонных звонков.

Группировка объединяет похожие оповещения за определенный период в одно уведомление, уменьшая количество оповещений.

В политике уведомлений можно настроить объединение нескольких оповещений в одно уведомление:

опция "Group by" определяет критерии группировки входящих оповещений в рамках политики; по умолчанию используется правило оповещения;
параметры синхронизации определяют, когда и как часто отправлять уведомления.

Экземпляры оповещений группируются вместе, если у них совпадают значения меток, настроенных в параметре "Group by".

Например, учитывая, что для "Group by" параметра установлено значение метки team:

alertname:foo, team=frontend и alertname:bar, team=frontend находятся в одной группе;
alertname:foo, team=backend и alertname:qux, team=backend находятся в другой группе.

По умолчанию политики уведомлений в Подсистеме группы оповещаются по правилам оповещений. В частности, они группируются с помощью меток alertname и grafana_folder, поскольку имена правил оповещений не уникальны для разных папок.

Если требуется сгруппировать оповещения по другим меткам, отличным от правила оповещения, необходимо изменить параметр "Group by" на любую другую комбинацию меток.

Если требуется сгруппировать все оповещения, обрабатываемые политикой уведомлений, в одну группу (без группировки оповещений по правилам оповещений или другим меткам), можно оставить "Group by" пустым в политике по умолчанию.

Если требуется получать каждое оповещение как отдельное уведомление, можно сгруппировать их по специальной метке "..." и убедиться, что других меток нет.

В политике уведомлений также можно настроить частоту отправки уведомлений для каждой группы оповещений. В политике уведомлений есть три отдельных таймера, применяемых к группам:

Групповое ожидание – время ожидания перед отправкой первого уведомления для новой группы оповещений;
Интервал группы – время ожидания перед отправкой уведомления об изменениях в группе оповещений;
Интервал повтора – время ожидания перед отправкой уведомления, если группа не изменилась с момента последнего уведомления.

Эти таймеры сокращают количество отправляемых уведомлений. Задерживая отправку уведомлений, можно объединить входящие оповещения в одно уведомление вместо множества (рисунок 85).

Рисунок 85 — Базовая схема последовательности таймеров политики уведомлений

Групповое ожидание – (по умолчанию 30 секунд) время, в течение которого Подсистема ожидает отправки первого уведомления для новой группы оповещений. Чем дольше группа ожидает, тем больше времени требуется для включения других оповещений в первоначальное уведомление о новой группе. Чем меньше группа ожидает, тем раньше отправляется первое уведомление, но при этом есть риск не включить некоторые оповещения.

Групповой интервал – (по умолчанию 5 минут) если оповещение опоздало для включения в первое уведомление из-за группового ожидания, оно включается в последующие уведомления после группового интервала. Групповой интервал – это время ожидания перед отправкой уведомлений об изменениях в группе. Например, изменением группы может быть добавление нового оповещения о срабатывании в группу или разрешение существующего оповещения.

Интервал повтора – (по умолчанию 4 часа) служит напоминанием о том, что оповещения в группе все еще срабатывают. Таймер интервала повтора определяет, как часто будут отправляться (или повторяться) уведомления, если группа не изменилась с момента последнего уведомления.

Шаблоны

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

В Подсистеме есть различные варианты шаблонов сообщений с оповещениями:

Примечания к правилам оповещений:
- аннотации для дополнительной информации, например summary и description, чтобы оповещать о сообщениях с уведомлениями;
- аннотации шаблонов для отображения значений запроса, имеющих отношение к оповещению, например, имени сервера или порогового значения запроса;
Метки правил оповещения:
- метки используются для того, чтобы отличать экземпляр оповещения от всех других экземпляров оповещения;
- шаблоны меток используются для добавления дополнительной метки на основе значения запроса или в случае, если метки из запроса неполные или недостаточно информативные;
Шаблоны уведомлений:
- шаблоны уведомлений используются контактными точками для единообразного оформления заголовков и описаний уведомлений;
- шаблоны уведомлений требуются при настройке внешнего вид и информацию уведомлений.
- не следует использовать шаблоны уведомлений для добавления дополнительной информации в оповещения – вместо этого использовать аннотации.

На рисунке 86 показан весь процесс создания шаблонов: от запроса меток и создания шаблонов для сводки оповещений и уведомлений до окончательного сообщения об оповещении.

Рисунок 86 — Создание шаблонов

На этой диаграмме:

запрос правила оповещения возвращает 12345 вместе со значениями меток instance и job;
этот результат запроса нарушает условие правила оповещения, вызывая запуск экземпляра оповещения;
экземпляр оповещения генерирует сводную аннотацию, определяемую шаблоном, используемым в сводной части правила оповещения; в данном случае отображается значение метки instance: server1;
Alertmanager получает экземпляр оповещения о срабатывании, включая итоговую аннотацию, и определяет контактную точку, которая будет обрабатывать оповещение;
Alertmanager использует шаблон уведомления контактной точки для форматирования сообщения, затем отправляет уведомление настроенному получателю (-ям) – адресу электронной почты.

Шаблоны аннотаций

Аннотации можно определить в правиле оповещения, чтобы добавить дополнительную информацию к оповещениям.

При создании правила оповещения Подсистема предлагает несколько дополнительных аннотаций, таких как description, summary, runbook_url, dashboardUId и panelId, которые помогают идентифицировать оповещения и реагировать на них. Также можно создавать собственные аннотации.

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

Аннотации могут содержать обычный текст, но, если нужно, можно отобразить значения запроса, относящиеся к оповещению, например:

показать значение запроса, которое запускает оповещение;
включить метки, возвращаемые запросом, которые идентифицируют оповещение;
отформатировать сообщение аннотации в зависимости от значения запроса.

Шаблоны меток

Метки используются для того, чтобы отличать один экземпляр оповещения от всех остальных, поскольку набор меток однозначно идентифицирует экземпляр оповещения. Политики уведомлений и отключения оповещений используют метки для обработки экземпляров оповещений.

Также можно создавать шаблоны меток на основе результатов запроса. Это полезно, если метки, которые возвращаются в результате запроса, недостаточно подробны. Например:

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

Вот пример создания шаблона для метки severity на основе значения запроса:

{{ if (gt $values.A.Value 90.0) -}}
critical
{{ else if (gt $values.A.Value 80.0) -}}
high
{{ else if (gt $values.A.Value 60.0) -}}
medium
{{ else -}}
low
{{- end }}

Шаблоны уведомлений

Шаблоны уведомлений позволяют настраивать содержимое уведомлений, например тему электронного письма или текст сообщения в Slack.

Шаблоны уведомлений отличаются от шаблонов аннотаций и меток следующими особенностями:

Шаблоны уведомлений назначаются контактной точке, а не правилу оповещения.
Если не указано иное, контактная точка использует шаблон по умолчанию, который включает соответствующую информацию об оповещении.
Один и тот же шаблон можно использовать в нескольких контактных точках, что упрощает его поддержку и обеспечивает единообразие.
Шаблоны уведомлений не следует использовать для добавления дополнительной информации к отдельным оповещениям, а использовать для этого аннотации.
Хотя и шаблоны аннотаций/меток, и шаблоны уведомлений используют один и тот же язык шаблонов, доступные переменные и функции различаются.