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

Интеграция

Создайте интеграцию типа Alertmanager, как описано в обзоре интеграций, и сохраните её API key. Пресет важности берёт уровень из лейбла severity, так что для начала его можно не менять.

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

Добавьте в alertmanager.yml получатель (receiver), заменив <API_KEY> своим ключом:

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

Затем направьте на receiver incidentgarden нужные маршруты (routes). При включенном send_resolved Prometheus будет отправлять закрывающее событие в Incident Garden, когда алерт закроется.

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

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

Что решает group_by

Параметр group_by в маршруте alertmanager.yml определяет, какие срабатывания Prometheus поедут одним батчем и какие лейблы у батча окажутся общими.

Два лейбла требуют особого внимания:

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

Качество алертов закладывается ещё в Prometheus, поэтому загляните в антипаттерны Алерты без агрегации в PromQL и Описание алерта как диагностический отчёт.