Подключение AlertManager

Это руководство показывает, как подключить Prometheus AlertManager как источник алертов. Если вы ещё не проходили базовую настройку, начните с Quick Start.

Предусловия

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

1. Team — команда, которая будет принимать алерты этой интеграции.
2. Escalation Policy этой команды — цепочка, по которой алерты пойдут к получателям.

Как создать команду и политику, описано в Quick Start: Создание команды и Escalation Policy.

Создание интеграции

Endpoint приёма

AlertManager отправляет батчи на endpoint вашей интеграции:

POST https://api.incidentgarden.ru/api/v1/integrations/<API_KEY>/alerts

Конфигурация AlertManager

Добавьте в alertmanager.yml receiver, который шлёт на этот endpoint (замените <API_KEY> на ваш ключ):

receivers:
  - name: incidentgarden
    webhook_configs:
      - url: 'https://api.incidentgarden.ru/api/v1/integrations/<API_KEY>/alerts'

После этого направьте нужные маршруты (routes) AlertManager на ресивер (receiver) incidentgarden.

Маппинг важности

Пресет для типа Alertmanager:

• source_field — labels.severity
• critical ← critical
• warning ← warning, info
• default — critical

Это означает, что важность каждого алерта берётся из метки severity в его labels. Как изменить эти значения — см. Настройка важности. Зачем нужен маппинг и как он связан с эскалацией — в концепции Важность и её маппинг.

Как обрабатывается батч

Один батч AlertManager превращается в один алерт (плоская группировка). Жизненным циклом группы управляет верхнеуровневый status: отправляйте точные значения firing или resolved. Статус отдельного элемента alerts[].status для этого не используется. Полный контракт и примеры см. в формате payload.

Что решает group_by

Состав батча задаёте вы сами — параметром group_by в route вашего alertmanager.yml. Он определяет, какие срабатывания Prometheus поедут одним батчем и какие метки у этого батча будут общими. Поскольку батч — это ровно один алерт, а «та же самая проблема» опознаётся по общим меткам группы, group_by прямо решает, сколько алертов у вас появится и что с чем схлопнется. Это единственная настройка на стороне отправителя, которая так сильно меняет картину дежурства, — поэтому её стоит выбрать осознанно, а не оставить как получилось.

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

• alertname даёт алерту заголовок. Если её нет в group_by, заголовок берётся из общей метки батча — а общей она будет, только если alertname совпал у всех срабатываний группы. Иначе алерт приедет с заголовком Unnamed Alert, и по списку понять, что именно горит, не получится.
• severity участвует в определении важности: важность считается по общим меткам батча. Если в одну группу попали срабатывания разной важности, общей метки severity у батча не окажется — маппинг не сойдётся, и алерт получит важность по умолчанию, то есть critical (см. Настройка важности). Иными словами, смешав в одной группе critical и warning, вы получите critical.