Аномальный трафик в распределённых системах: где ломается видимость и как это ловить

Аномальный трафик в распределённых системах: где ломается видимость и как это ловить

В распределённой архитектуре опасен не пик нагрузки, а расхождение между сервисами: один слой считает запросы нормальными, другой уже теряет очереди, ретраи и сессии. Атака или сбой редко выглядит как один резкий всплеск — чаще это смещение распределения, рост ошибок на периферии и деградация латентности по цепочке.

Контролируйте не только RPS, но и контекстные метрики:
— долю 4xx/5xx по каждому хопу;
— p95/p99 latency отдельно для входа, очередей и downstream;
— retry rate, timeout rate, circuit breaker open rate;
— ratio между входящим трафиком и успешными бизнес-операциями.
Если смотреть только на агрегат, вы пропустите медленную DDoS-имитацию, бот-активность или ошибочную петлю ретраев.

Аномалию нужно сравнивать не с «средним за день», а с базовой линией для конкретного маршрута, региона, ASN и типа клиента. Полезны разрезы по user-agent, источнику, endpoint, размеру payload и доле idempotent-запросов. Когда трафик выглядит корректно по объёму, но меняется по форме, именно там обычно прячется проблема.

Сигнал должен приходить раньше инцидента: алерты на дисбаланс очередей, рост timeouts между сервисами и несоответствие между ingress и sidecar-метриками дают больше, чем попытка ловить «аномалию вообще». Проверяйте логи, истина всегда скрыта в них.