Мониторинг вебхуков: как не проспать падение эндпоинта и не утонуть в ложных алертах

Мониторинг вебхуков: как не проспать падение эндпоинта и не утонуть в ложных алертах

Проверять надо не только 2xx. Для вебхука важны: таймаут, 4xx/5xx, пустое тело, битый JSON, неверная подпись. Если хендлер молча отдает 200 на мусор, мониторинг бесполезен: инцидент будет жить в очереди, а не в графике. Смотрим в тело запроса и валидируем схему до любой бизнес-логики.

Дальше — синтетика. Отдельный job шлёт тестовый payload в боевой endpoint и ждёт предсказуемый ответ. Если нет квитанции за N секунд — алерт. Полезно проверять и обратную сторону: может ли ваш обработчик стабильно писать в очередь, а не зависать на внешнем API. Ретрай-политика решает всё, но ретраи без дедупликации превращают падение в шторм.

Минимальный набор метрик:
• latency p95/p99
• доля 5xx и 4xx
• timeout rate
• размер очереди
• число повторных доставок по одному event_id

Идемпотентность — это не роскошь, а база. Ключ дедупликации берите из event_id, если его нет — из хеша полезной нагрузки плюс источник. Логи пишите структурно: request_id, source, event_id, decision, error_class. Без этого дебажить придётся руками, а руками ночью обычно дорого.

Алерт должен срабатывать на симптом, а не на шум: 3 подряд 5xx, рост таймаутов, провал synthetic-check, либо очередь не разгребается дольше допустимого окна. Всё остальное — косметика.