Аномалии в трафике не ловятся “на глаз”: нужен базовый профиль и точка отсчёта

Аномалии в трафике не ловятся “на глаз”: нужен базовый профиль и точка отсчёта

Методология начинается не с алерта, а с определения нормального поведения. Сначала фиксируют базовые ряды по RPS, p95/p99 latency, доле ошибок, размеру пакетов и распределению по источникам. Без этого любой всплеск выглядит подозрительно, хотя может быть обычным суточным пиком или перекладкой нагрузки между узлами.

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

Отдельно проверяют корреляции. Если растёт latency, но не растёт error rate, это может быть очередь, деградация upstream или перегрузка одного пула. Если одновременно меняются RPS и доля 5xx, смотрят на балансировку, лимиты и ошибки прикладного слоя. Рекомендуется обратить внимание на метрику, которая первой отклоняется от профиля: она обычно указывает на первопричину.

Для фильтрации ложных срабатываний полезны окна сравнения: день к дню, час к часу, тот же маршрут и тот же тип трафика. А вот порог “выше X — тревога” без контекста работает плохо: он не различает сезонность, ретраи и перераспределение клиентов.

Практика простая: сначала нормализация, потом сегментация, затем корреляция. Если порядок нарушить, инцидент будет выглядеть как шум.