<b>Эндпоинт упал, а вы узнали об этом от клиента — плохая архитектура мониторинга</b>

<b>Эндпоинт упал, а вы узнали об этом от клиента — плохая архитектура мониторинга</b>

Смотрим в тело запроса и отделяем живой сервис от «200 OK на пустом месте». Для вебхуков и публичных API минимум такой: health-check на транспорт, synthetic probe на бизнес-операцию, проверка латентности и счётчик 5xx/timeout. Один ping ничего не гарантирует: upstream может отвечать, но уже терять полезную нагрузку или молча дропать часть событий.

Алерт не должен срабатывать на каждый чих. Нужны окна агрегации, пороги по rate, а не по единичному ответу, и suppression для каскадных падений. Если эндпоинт шлёт 502 пачками, один инцидент должен породить один тикет, а не тысячу пушей. Идемпотентность — это не роскошь, а база: при ретраях мониторинг не должен сам создавать дубль инцидента.

Храните в событии минимум контекста: endpoint, метод, correlation_id, код ответа, время, payload_hash. Без этого ночной разбор превращается в гадание на логах. Для критичных интеграций полезен dead-man switch: если heartbeat не пришёл за N интервалов, поднимаем алерт независимо от успешных запросов.

Практика простая: алертить на потерю функции, а не на факт наличия трафика. Иначе вы строите не мониторинг, а шумогенератор с красивой графикой.