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

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

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

Полезно контролировать не только объем, но и форму трафика:
— соотношение read/write и долю retry;
— рост fan-out на один входящий запрос;
— сдвиг по кодам ответа, особенно 4xx/5xx;
— расхождение между ingress и egress на уровне узла или кластера.

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

Практически это означает: держать baseline по каждому критичному сервису, вводить пороги не только по абсолютным значениям, но и по отклонению от сезонности, а алерты строить на корреляции метрик, а не на одном графике. Безопасность — это не состояние, а непрерывный процесс мониторинга и патчинга.