IncidentGarden

Настройка важности (severity mapping)

Как перевести «родные» уровни важности источника в две важности Incident Garden.

Severity mapping — это правило, по которому «родные» значения важности из полученного события переводятся в две важности Incident Garden: critical и warning. Что это и зачем — подробно в концепции Важность и её маппинг.

Структура маппинга

  • source_field — имя метки в labels, из которой берётся важность. Для записи вида labels.severity используется сегмент severity.
  • mapping.critical — список значений, которые переводятся в critical.
  • mapping.warning — список значений, которые переводятся в warning.
  • defaultcritical или warning, применяется, когда значение из источника не найдено ни в одном списке.

Где менять в интерфейсе

Откройте страницу интеграции и нажмите Edit settings. Доступны поля:

  • Source field — имя метки-источника важности
  • Critical values — значения, переводимые в critical (через запятую)
  • Warning values — значения, переводимые в warning (через запятую)
  • Default severity — важность по умолчанию

Тип интеграции после создания не меняется. Пресет маппинга подставляется при создании — по выбранному типу.

Пресеты по типу

Типsource_fieldcriticalwarning
Alertmanagerlabels.severitycriticalwarning, info
Zabbixseveritydisaster, highaverage, warning, information, not_classified
Generic Webhookпустой

Для Generic Webhook source_field пустой, поэтому важность по умолчанию — critical. Чтобы вычислять важность из тела запроса, задайте source_field сами.

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

Алерт получает значение Default severity в трёх случаях:

  • Source field не задан — как в пресете Generic Webhook;
  • метки с таким именем в событии нет или она пустая;
  • значение пришло, но его нет ни в Critical values, ни в Warning values — например, источник добавил новый уровень, а маппинг про него не знает.

Во всех пресетах Default severitycritical. Это сознательный выбор: не знаем важность — будим, чтобы инцидент не потерялся. Обратный вариант означал бы, что незнакомое значение из источника тихо получает мягкую обработку: по warning оповещается только первый шаг эскалации, дальше нужно эскалировать руками (см. Как работает эскалация). Пропущенный critical обходится дороже лишнего звонка.

Отсюда практический вывод при отладке: если после подключения интеграции всё приходит как critical — почти наверняка не совпал маппинг, а не «источник шлёт только критику». Проверьте по порядку:

  1. Source field — то ли имя метки, которое реально приходит в событии.
  2. Critical values / Warning values — точно ли те значения, которыми оперирует источник (совпадение точное, с учётом регистра).
  3. Само событие — приходит ли в нём эта метка вообще.

Как осознанно вернуть warning

Если интеграция заведомо шумная и её незнакомые значения будить не должны, поставьте Default severity = warning: страница интеграции → Edit settingsDefault severity. Тогда всё, что не совпало явно, пойдёт мягким путём — первый шаг эскалации и дальше вручную.

Меняя Default severity на warning, вы берёте на себя обязательство держать Critical values полными. Всё, что действительно должно будить, теперь обязано быть перечислено там явно: любое новое значение, которое источник начнёт слать позже, попадёт в warning и ночью никого не поднимет.

На этой странице