Аномалия трафика в распределенной системе часто начинается с «нормы», которую никто не формализовал

Аномалия трафика в распределенной системе часто начинается с «нормы», которую никто не формализовал

Если у сервиса нет базовой модели поведения, любой всплеск выглядит «рабочей нагрузкой». Для распределенных систем это критично: один узел может маскировать деградацию, пока соседние уже отдают 5xx, а очередь растет быстрее, чем срабатывают алерты.

Смотрите не только на RPS. Полезнее коррелировать:
— p95/p99 latency по каждому критичному endpoint
— долю ошибок по коду ответа и типу upstream
— глубину очередей, retry-rate, timeout-rate
— skew между регионами, подсетями и балансировщиками

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

Снизить шум помогает простое правило: алерт строится не на одном метрике, а на связке «трафик + ошибки + латентность + изменение распределения». Без этого вы ловите симптомы, а не инцидент.

Периметр не заканчивается на фаерволе, он заканчивается на последнем микросервисе.