Подключение через webhook
Принимайте алерты из любой системы через обобщённый webhook.
Если у вашей системы мониторинга нет готового пресета, используйте обобщённый webhook. Подойдёт любой источник, способный отправить HTTP POST с JSON-телом. Если вы ещё не проходили базовую настройку, начните с Quick Start.
Создание интеграции
Откройте вкладку интеграций команды
Откройте нужную команду, перейдите на вкладку Integrations и нажмите Add Integration.
Заполните параметры
Укажите имя, выберите тип Generic Webhook, команду и политику эскалации.
Скопируйте API key
Скопируйте API key сразу — он показывается только один раз.
Endpoint приёма
Минимальное тело запроса
Обязательно только поле title:
Поля тела запроса
| Поле | Обязательно | Описание |
|---|---|---|
title | да | Заголовок алерта |
description | нет | Подробное описание |
source | нет | Источник алерта |
status | нет | firing или resolved; по умолчанию firing |
dedup_key | нет | Ключ дедупликации |
labels | нет | Объект «строка → строка» с метками алерта |
Отправляйте в status точное значение firing или resolved. Полная семантика
статуса и поведение при других значениях описаны в
формате payload.
Дедупликация
Повторные события об одной и той же проблеме сводятся в один алерт, а не плодят новые. Чтобы это работало правильно, отправитель должен дать конвейеру признак, по которому «одна и та же проблема» отличается от «другая проблема». Формально поля необязательные, но по существу это требование к интеграции: присылайте одно из двух.
dedup_key— предпочтительный вариант. Стабильный идентификатор проблемы на стороне источника: одинаковый у всех повторных событий об одной проблеме и разный у разных проблем. Дополнительный плюс — он должен совпадать у события открытия и события закрытия: именно по нему событие соstatus=resolvedнаходит открытый алерт и закрывает его, а не создаёт новый.- Содержательные
labels— если стабильного идентификатора у источника нет. Ключом становится набор меток целиком, поэтому в нём должно быть то, что различает проблемы: хост, сервис, имя проверки. Набора вида{"severity": "critical"}недостаточно — он одинаков у половины ваших событий.
Без dedup_key и без содержательных labels вторая проблема потеряется.
Когда нет ни того, ни другого, единственное, что остаётся конвейеру, — заголовок.
Два разных события с одинаковым title (классика — «Disk space low» с двух
разных серверов) станут одним алертом: второе засчитается повтором первого,
отдельного алерта по нему не появится и никто по нему не будет оповещён. Дежурный
увидит одну проблему вместо двух и узнает о второй только когда откроет карточку
первой.
То же самое произойдёт при неразличающих labels — например если источник шлёт
только severity. Проверьте это до того, как интеграция уйдёт в дежурство: если
в вашем потоке заголовки не уникальны, dedup_key обязателен.
Если dedup_key задан, дедупликация идёт по нему; если нет — по labels; если
не заданы и они — по title. Откройте карточку первой записи и проверьте
обновлённые метки на вкладке Payload.
Важность
Чтобы важность вычислялась из тела запроса, задайте source_field в маппинге —
см. Настройка важности. По умолчанию
пресет для Generic Webhook пустой, поэтому всем алертам присваивается важность
critical.
Например, при source_field = labels.severity важность берётся из тела так:
Поле labels используется и для вычисления важности, и в условиях Label matchers
у Policies. Если метку не прислать, для политики она считается
отсутствующей: matcher «равно» / «присутствует» по ней не совпадёт, а matcher «не
равно» / «отсутствует» совпадёт со всеми такими алертами. Присылайте в labels
те метки, на которые опираетесь в условиях.