Аномальный трафик в распределённых системах редко ломает всё сразу — он сначала меняет профиль запросов

Аномальный трафик в распределённых системах редко ломает всё сразу — он сначала меняет профиль запросов

Смотрите не на «падение», а на отклонение от базовой линии: резкий рост RPS по одному пути, смещение географии, всплеск 4xx/5xx, рост fan-out между сервисами. В распределённой архитектуре одна и та же атака часто выглядит как набор слабых аномалий, каждая из которых по отдельности похожа на шум.

Полезно держать в мониторинге не только агрегаты, но и производные метрики:
— p95/p99 latency по критичным маршрутам
— соотношение successful/failed requests
— долю retry, timeout и circuit breaker open
— концентрацию запросов по user-agent, ASN, tenant, endpoint

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

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

Безопасность — это не состояние, а непрерывный процесс мониторинга и патчинга.