Алерты и группы алертов#

IncidentRelay сохраняет каждый входящий сигнал мониторинга как алерт и показывает операторам группу алертов на странице Alerts.

Группа алертов — это объект уровня инцидента. Именно этот объект пользователи подтверждают, разрешают, по нему отправляют уведомления, напоминания, эскалации и его объединяют.

Дочерний алерт — это конкретный сигнал внутри группы. Например, три алерта DiskFull с трёх хостов могут отображаться как одна группа алертов с тремя дочерними алертами.

Основные термины#

Термин	Значение
Группа алертов	Объект уровня инцидента, отображаемый на странице Alerts.
Дочерний алерт	Конкретный входящий сигнал внутри группы алертов.
`dedup_key`	Идентифицирует один конкретный алерт и используется для обновления того же дочернего алерта.
`group_key`	Определяет, какие дочерние алерты относятся к одной и той же группе алертов.
`group_by`	Настройка маршрута, управляющая тем, какие поля используются для построения `group_key`.
Merge	Ручная операция, перемещающая дочерние алерты из одной группы в другую.

Дедупликация против группировки#

Дедупликация и группировка решают разные задачи.

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

group_key объединяет несколько связанных дочерних алертов в одну группу алертов. Если у двух алертов разные значения dedup_key, но одинаковый group_key, они становятся разными дочерними алертами внутри одной группы алертов.

Пример:

{
  "labels": {
    "alertname": "DiskFull",
    "severity": "critical",
    "instance": "host1"
  },
  "fingerprint": "disk-full-host1-var"
}

и:

{
  "labels": {
    "alertname": "DiskFull",
    "severity": "critical",
    "instance": "host2"
  },
  "fingerprint": "disk-full-host2-var"
}

С маршрутом group_by = ["alertname", "severity"] оба алерта помещаются в одну группу, потому что у них совпадают alertname=DiskFull и severity=critical.

С маршрутом group_by = ["alertname", "severity", "instance"] они помещаются в разные группы, потому что instance различается.

Группировка по умолчанию#

Если маршрут не задаёт group_by, IncidentRelay использует группировку по умолчанию:

alertname
severity

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

Настройка `group_by` маршрута#

group_by маршрута принимает список имён полей.

Рекомендуемые примеры:

["alertname", "severity"]

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

["alertname", "severity", "instance"]

Группировать по имени алерта, уровню важности и инстансу. Это оставляет каждый хост в отдельной группе.

["alertname", "severity", "mountpoint"]

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

Поддерживаемые формы полей:

Форма	Пример	Значение
Простое имя метки	`alertname`	Читает сначала из меток, затем из аннотаций, затем из данных алерта верхнего уровня.
Явный путь к метке	`labels.instance`	Читает из меток алерта.
Явный путь к аннотации	`annotations.summary`	Читает из аннотаций алерта.
Явный путь в полезной нагрузке	`payload.trigger.id`	Читает из нормализованной полезной нагрузки.
Встроенная область	`source`, `team`, `route`, `service`	Использует метаданные IncidentRelay, полученные при маршрутизации.

Жизненный цикл группы алертов#

Firing#

Новая группа начинается в состоянии firing, когда хотя бы один дочерний алерт находится в состоянии firing.

Если в ту же группу добавляется другой дочерний алерт, счётчики пересчитываются, и группа остаётся в состоянии firing.

Acknowledged#

Подтверждение группы алертов помечает группу как acknowledged.

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

Подтверждение также отменяет поставленные в очередь доставки notification, reminder и escalation, которые были запланированы до ACK. Перед отправкой firing-уведомлений worker повторно читает сохранённый статус группы, поэтому устаревшее состояние scheduler не должно повторно пейджить уже подтверждённый инцидент.

Новый дочерний алерт обычно снова открывает подтверждённую группу как firing. Есть одно исключение для корреляции: если маршрут группирует только по непустому incident_key (или labels.incident_key), новый дочерний алерт с тем же ключом сохраняет acknowledged, если он не может повысить фактический приоритет инцидента. Реальное повышение приоритета всё равно снова открывает группу и запускает новый цикл эскалации.

Resolved#

Разрешение группы алертов разрешает все дочерние алерты в группе.

Когда для существующих дочерних алертов приходят входящие полезные нагрузки resolved, группа разрешается только тогда, когда разрешены все дочерние алерты.

Осиротевшая полезная нагрузка resolved не создаёт новую группу.

Комментарии#

Детали алерта включают раздел Comments для заметок ответственных.

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

Подробнее: Комментарии к алертам.

Merged#

Исходная объединённая группа помечается как merged и указывает на целевую группу. Дочерние алерты из исходной группы перемещаются в целевую группу.

Объединённые группы скрыты из обычного списка алертов, если только API/UI явно не запрашивает их включение.

Уведомления группы#

Группы алертов поддерживают отложенные и пакетные уведомления.

Первое уведомление о firing может быть отложено на ALERT_GROUP_WAIT_SECONDS. Это даёт IncidentRelay время собрать несколько дочерних алертов в одну группу перед уведомлением пользователей.

Обновления после первого уведомления ограничиваются по частоте параметром ALERT_GROUP_INTERVAL_SECONDS.

Если группа разрешается до отправки первого уведомления, IncidentRelay очищает ожидающее уведомление о firing и не отправляет шумные устаревшие уведомления.

Если группа уже была уведомлена, а затем разрешается, IncidentRelay немедленно отправляет уведомление о разрешении.

Соответствующие настройки:

[alerts]
alert_group_wait_seconds = 30
alert_group_interval_seconds = 300
alert_group_notification_check_interval_seconds = 10
alert_group_notification_batch_size = 100

Ручные AlertGroup#

Ручные AlertGroup позволяют ответственным и редакторам создать техническую группу алертов напрямую из UI или API, когда проблема известна до того, как внешняя система мониторинга отправит алерт.

Ручная AlertGroup сохраняется как техническая группа алертов с одним дочерним Alert:

source группы алертов — manual;
source дочернего алерта — manual;
статус начинается как firing;
подтверждение, разрешение, shelving, ответственные, заинтересованные стороны, комментарии, приоритет и хронология работают так же, как для групп алертов, созданных интеграцией.

Ручные AlertGroup не требуют маршрута приёма. Создатель выбирает команду напрямую и может дополнительно выбрать сервис.

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

Разрешения#

Пользователь может создать ручную AlertGroup для команды, если он является одним из:

глобальный администратор;
редактор группы или администратор группы для группы команды;
менеджер команды;
ответственный команды.

Наблюдатели не могут создавать ручные инциденты.

Пример API#

curl -X POST https://incidentrelay.example.com/api/alert-groups \
  -H "Authorization: Bearer TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "team_id": 12,
    "service_id": 34,
    "title": "Storage API is unavailable",
    "message": "Customers are receiving 5xx from storage-api.",
    "severity": "critical",
    "priority": "p1",
    "notify": true
  }'

Поведение уведомлений

Когда notify равно true, IncidentRelay планирует обычное уведомление группы алертов. Для ручных AlertGroup без маршрута доставка определяется через политику уведомлений выбранного сервиса.

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

Ручное объединение#

Ручное объединение полезно, когда две группы были созданы отдельно, но фактически описывают один инцидент.

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

Пример API:

curl -X POST https://incidentrelay.example.com/api/alert-groups/101/merge \
  -H "Authorization: Bearer TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "source_group_ids": [102, 103],
    "reason": "Same customer-facing incident"
  }'

Ответ — целевая группа алертов с пересчитанными счётчиками.

API AlertGroup#

IncidentRelay 2.3 предоставляет технические AlertGroup только через /api/alert-groups. Старый /api/alerts удалён как часть намеренно несовместимого API split 2.3.

Поле id всегда является идентификатором AlertGroup. Детали доступны по адресу:

GET /api/alert-groups/{id}

Полное сопоставление endpoint’ов приведено в руководстве по миграции API 2.3.

Примеры API#

Список групп#

curl -H "Authorization: Bearer TOKEN" \
  "https://incidentrelay.example.com/api/alert-groups?status=firing&severity=critical"

Получить детали группы#

curl -H "Authorization: Bearer TOKEN" \
  "https://incidentrelay.example.com/api/alert-groups/101"

Ответ с деталями содержит:

{
  "type": "alert_group",
  "id": 101,
  "status": "firing",
  "alert_count": 2,
  "firing_count": 2,
  "alerts": [
    {
      "type": "alert",
      "id": 501,
      "status": "firing",
      "dedup_key": "disk-full-host1-var"
    },
    {
      "type": "alert",
      "id": 502,
      "status": "firing",
      "dedup_key": "disk-full-host2-var"
    }
  ]
}

Подтвердить группу#

curl -X POST https://incidentrelay.example.com/api/alert-groups/101/acknowledge \
  -H "Authorization: Bearer TOKEN" \
  -H "Content-Type: application/json" \
  -d '{}'

Разрешить группу#

curl -X POST https://incidentrelay.example.com/api/alert-groups/101/resolve \
  -H "Authorization: Bearer TOKEN" \
  -H "Content-Type: application/json" \
  -d '{}'

Устранение неполадок#

Алерты не группируются#

Проверьте значение group_by маршрута. Если включена метка instance, pod, container или другая метка с высокой кардинальностью, IncidentRelay может создавать по одной группе на хост или на pod.

Несвязанные алерты группируются#

Добавьте больше полей в group_by маршрута, например instance, mountpoint, service или другую метку, разделяющую инциденты для команды.

Группа была подтверждена, но снова стала firing#

Новый дочерний алерт обычно снова открывает подтверждённую группу. Если маршрут группирует только по incident_key, дочерние алерты с тем же ключом сохраняют ACK, пока не могут повысить фактический приоритет. Если такая группа всё же снова открылась, проверьте более высокий входящий приоритет, пустой/изменившийся ключ, дополнительные поля группировки или переопределение group key через orchestration.

Уведомление о разрешении не было отправлено#

Если группа разрешилась до отправки первого отложенного уведомления, IncidentRelay намеренно пропускает как уведомление о firing, так и о разрешении, чтобы избежать шума.

Группа исчезла после объединения#

Исходная группа была помечена как merged. Откройте целевую группу, чтобы увидеть перемещённые дочерние алерты.

Shelving#

Открытый AlertGroup можно временно отложить без изменения технического статуса firing/acknowledged. Shelving приостанавливает notification/update/reminder/escalation, но не ingestion и расчёт impact. Подробнее: Откладывание алертов.

Алерты и группы алертов