Алерт в Prometheus без шума

«Учебное API получает 200 запросов в минуту, 10 из них — 5xx; при таком устойчивом состоянии нужна тревога. При двух запросах и одной ошибке этот алерт молчит». Попросите перевести минутный порог в единицы выбранного выражения. Если используется скорость в секунду, число 100 нельзя подставлять как будто это всё ещё запросы в минуту.

Окно определяет данные, по которым вычисляется скорость, а for требует, чтобы выражение оставалось активным достаточно долго перед срабатыванием. Эти интервалы не взаимозаменяемы. Попросите временную шкалу короткого всплеска и длительной ошибки. Проверьте также восстановление: правило должно прекращать тревогу по согласованному условию, а не держать её из-за случайно изменившихся меток каждого нового события.

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

Укажите затронутый сервис, симптом, значение и первый шаг диагностики, например проверку распределения ошибок по маршрутам. Ссылку на панель берите из вашей инфраструктуры, не выдумывайте. Енотик поможет оформить правило, но не знает нормального трафика и не проверяет его на вашем сервере. Порог из учебного примера нужно подтвердить историей и тестом правила перед отправкой реальных уведомлений дежурному.