
Комментарии 3
На картинке в delivery notification есть опция Webhook, при этом в самой документации найти не удалось. В результате, есть ли возможность при инциденте отправлять запрос из nxs-anomaly в кастомный сервис?
Принимать ACK из кастомного сервиас вроде как можно.
Спасибо за отличный вопрос. Да, можно. nxs-anomaly умеет при инциденте сам отправлять запрос в ваш сервис. Для этого в цепочку эскалации (escalation chain) добавляется шаг TRIGGER_WEBHOOK. Он описан, просто не на видном месте: в CONFIGURATION.md, раздел 4, таблица шагов и абзацы про TRIGGER_WEBHOOK ниже.
Как это работает:
Когда эскалация доходит до этого шага, nxs-anomaly шлёт POST на webhook_url. Если сервис не ответил, запрос повторяется.
Тело запроса - JSON в формате вебхука Alertmanager (version: “4”), а не текст по шаблону. В нём status, alerts[].labels (там alertname, severity), annotations.summary с заголовком инцидента и groupKey, где лежит ID группы алертов (delivery_adapters.go:1179). Свой шаблон тела задать нельзя. Если ваш сервис уже умеет принимать вебхуки Alertmanager, он примет и этот.
Для авторизации есть headers. Секрет лучше передавать ссылкой на переменную окружения, в production-профиле так обязательно: {“kind”: “TRIGGER_WEBHOOK”, “webhook_url”: “https://my-service/hook”, “headers”: {“Authorization”: “env:NXS_ANOMALY_MYSVC_AUTH”}}
В production-профиле включена защита от SSRF, и внутренние адреса (частные сети, localhost) запрещены. Внутренний сервис нужно разрешить через NXS_ANOMALY_BLOCK_PRIVATE_WEBHOOKS_EXCEPT (подробнее в SECURITY_PROFILE.md).
В UI шаг выглядит как «Вызвать исходящий вебхук» в редакторе цепочки. Через API или Terraform он задаётся как шаг цепочки.
ACK из вашего сервиса: да, это работает. ID группы сервис берёт из groupKey в полученном вебхуке. Затем вызывает POST /api/v1/alert-groups/{id}/acknowledge (или /resolve) с API-ключом, у которого роль не ниже responder.
От метрики до дежурного: путь алерта через Prometheus, Alertmanager и nxs-anomaly