Мониторинг медленных ответов: замечайте деградацию

Если проверять только HTTP-код, рост задержки останется успешным результатом до таймаута. Пользователи при этом уже могут ждать дольше обычного. Порог ответа даёт команде отдельный сигнал о деградации и помогает реагировать до полного отказа.

Используйте URL с предсказуемой нагрузкой. Тяжёлый отчёт и лёгкий health endpoint имеют разный нормальный диапазон. Порог, выбранный без истории, может превратить обычные колебания в поток уведомлений. Учитывайте сетевую задержку региона и реальные требования к методу.

Таймаут ограничивает ожидание незавершённого запроса. Порог медленного ответа отмечает долгий, но завершившийся ответ. Настройте оба значения осмысленно: сначала определите допустимую длительность, затем предел ожидания при отсутствии результата.

Деградация подтверждается после трёх последовательных циклов оценки, в которых все учитываемые свежие успешные региональные результаты выше порога. Для восстановления нужны два цикла с результатами ниже 80% порога. Это запас против переключения статуса на каждом небольшом колебании.

Например, при пороге 1 000 мс одного ответа 1 842 мс недостаточно для деградации, а возврат к 900 мс ещё не означает восстановление. Для восстановления нужны результаты ниже 800 мс в двух последовательных циклах. Правила оповещений настраиваются отдельно от этой оценки.

При изменении URL пересмотрите порог. Новый endpoint может выполнять другую работу, поэтому старое значение не обязательно подходит. Сохраните предмет проверки понятным: один монитор измеряет конкретный запрос, а не скорость всей системы.