Политики уведомлений
Политики уведомлений предоставляют гибкий способ проектирования обработки уведомлений и минимизации шума от оповещений.
С помощью сопоставителей меток экземпляры оповещений маршрутизируются в политики уведомлений. Затем политика уведомлений может сгруппировать несколько экземпляров оповещений в одно уведомление и доставить его в точку контакта.
Политики уведомлений — это не список, а структура, организованная по древовидному принципу:
- Корнем дерева политик уведомлений является Default notification policy.
- Каждая политика может иметь дочерние политики.
- Каждая политика может иметь соседние политики, разделяющие одного родителя и один иерархический уровень.
Каждая политика состоит из набора сопоставителей меток (0 или более), задающих, какие оповещения она заинтересована или не заинтересована обрабатывать. Подходящая политика — это политика уведомлений, сопоставители меток которой совпадают с метками экземпляра оповещения.
Используйте метки и сопоставители меток, чтобы связать правила оповещений с политиками уведомлений и silences. Это обеспечивает гибкий способ управления экземплярами оповещений: указать, какая политика должна их обрабатывать и какие оповещения отключать.
Сопоставитель меток состоит из 3 отдельных частей: метки, значения и оператора.
-
Поле Label — это имя метки для сопоставления. Оно должно точно совпадать с именем метки.
-
Поле Value сопоставляется с соответствующим значением для указанного имени Label. Способ сопоставления зависит от значения Operator.
-
Поле Operator — это оператор для сопоставления со значением метки. Доступны следующие операторы:
Note
Если вы используете несколько сопоставителей меток, они объединяются логическим оператором AND. Это означает, что для связывания правила с политикой должны совпасть все сопоставители.
По умолчанию Grafana использует единое дерево политик уведомлений для всей маршрутизации оповещений. Также есть возможность настроить несколько политик уведомлений с помощью функции множественных политик, которая позволяет разделить логику маршрутизации на отдельные независимо управляемые деревья маршрутизации.
Пример сопоставления меток
Если вы определите следующий набор меток для вашего оповещения:
{ foo=bar, baz=qux, id=12 }
то:
- Сопоставитель метки, определённый как
foo=bar, совпадает с этим правилом оповещения. - Сопоставитель метки, определённый как
foo!=bar, не совпадает с этим правилом оповещения. - Сопоставитель метки, определённый как
id=~[0-9]+, совпадает с этим правилом оповещения. - Сопоставитель метки, определённый как
baz!~[0-9]+, совпадает с этим правилом оповещения. - Два сопоставителя меток, определённые как
foo=barиid=~[0-9]+, совпадают с этим правилом оповещения.
Исключение меток
Вы также можете написать сопоставители меток, чтобы исключить метки.
Вот пример, показывающий, как исключить метку Team. Вы можете выбрать любое из приведённых ниже значений для исключения меток.
Tip
Практический пример маршрутизации с помощью политик уведомлений см. в нашем учебнике по началу работы с экземплярами оповещений и маршрутизацией уведомлений.
Маршрутизация
Чтобы определить, какие политики уведомлений обрабатывают экземпляр оповещения, система ищет подходящие политики начиная с вершины дерева — с политики уведомлений по умолчанию.
Если подходящая политика найдена, система продолжает вычислять её дочерние политики в порядке их отображения. Если дочерняя политика совпадает с оповещением, система затем рекурсивно вычисляет её дочерние политики, пока не найдёт больше подходящих дочерних политик. В этом случае экземпляр оповещения обрабатывает только самая глубокая подходящая дочерняя политика.
По умолчанию, как только найдена подходящая политика, система не продолжает поиск среди соседних политик. Если вы хотите, чтобы соседние политики одной подходящей политики также обрабатывали экземпляр оповещения, включите Continue matching siblings для конкретной подходящей политики.
Note
Политика уведомлений по умолчанию совпадает со всеми экземплярами оповещений. Она всегда обрабатывает экземпляры оповещений, если нет дочерних политик или ни одна из дочерних политик не совпадает с метками экземпляра оповещения — это предотвращает пропуск любых оповещений.
Если оповещения используют несколько меток, эти метки также должны присутствовать в политике уведомлений, чтобы сопоставляться и маршрутизировать уведомления в конкретную точку контакта.
Вот разбор предыдущего примера:
Pod stuck in CrashLoop не имеет метки severity, поэтому ни одна из его дочерних политик не совпадает. Он имеет метку team=operations, поэтому совпадает первая политика.
Политика team=security не совпадает, и Continue matching siblings для этой политики не настроено.
Disk Usage – 80% имеет и метку team, и метку severity и совпадает с дочерней политикой команды operations.
Note
Когда оповещение совпадает и с родительской, и с дочерней политикой (как в этом случае), маршрутизация следует за дочерней политикой (
severity), так как она обеспечивает более конкретное совпадение.
Unauthorized log entry имеет метку team, но не совпадает с первой политикой (team=operations), поскольку значения различаются, поэтому он продолжит поиск и совпадёт с политикой team=security. У неё нет дочерних политик, поэтому дополнительная метка severity=high игнорируется.
Такая структура маршрутизации и дерева удобна для организации и обработки оповещений для отдельных команд, а также для сужения конкретных случаев внутри команды путём применения дополнительных меток.
Наследование
Помимо того, что дочерние политики являются полезной концепцией для маршрутизации экземпляров оповещений, они также наследуют свойства от своей родительской политики. Это относится и к дочерним политикам политики уведомлений по умолчанию.
По умолчанию дочерняя политика наследует от родителя следующие свойства уведомлений:
Затем каждая политика может при необходимости переопределить эти свойства.
Наследование свойств уведомлений вместе с процессом маршрутизации — эффективный метод группировки связанных уведомлений и обработки конкретных случаев через дочерние политики.
Пример наследования
Этот пример показывает, как дерево политик уведомлений из предыдущего примера позволяет дочерним политикам team=operations наследовать его точку контакта. Так вы можете избежать указания одной и той же точки контакта несколько раз для каждой дочерней политики.