Выявление аномалий

На этой странице:

• Что это такое
• Алгоритмы прогнозирования
  • Переопределение модели для отдельной метрики
  • Направление аномалии
  • Обучение и прогрев
• Метрики базовой линии и сигналы аномалий
• Какие метрики профилируются
• Встроенные правила выявления аномалий
• Подавление ложных срабатываний
• Как добавить метрики в профилирование
• Дополнительные параметры
• Что дальше

Что это такое

Выявление аномалий — механизм Proto Observability Platform, который с помощью машинного обучения (ML) автоматически строит базовую линию (ожидаемый диапазон значений, baseline) для ключевых показателей каждого сервиса и ключевой транзакции. Базовая линия учитывает суточную и недельную сезонность и постоянно переобучается на свежих данных, поэтому не требует ручной настройки порогов — она подстраивается под нормальное поведение каждого сервиса.

Аномалией считается выход фактического значения за границы ожидаемого диапазона; по умолчанию контролируются обе границы, направление настраивается — см. Направление аномалии. Базовую линию рассчитывает сервис proto-metric-analyzer.

Скриншот: базовая линия (серая область — ожидаемый диапазон) и фактические значения (линия) для вызовов, ошибок и времени отклика.

Алгоритмы прогнозирования

Прогноз для каждой метрики строится одним из трёх взаимозаменяемых алгоритмов. Алгоритм задаётся глобально и может быть переопределён для отдельной метрики.

Модель по умолчанию для всех метрик задаётся переменной POBP_MODEL_DEFAULT (по умолчанию stl_zscore).

Переопределение модели для отдельной метрики

Переменная POBP_MODEL_OVERRIDES задаёт модель и, необязательно, направление аномалии для конкретных метрик. Формат записи — метрика:модель либо метрика:модель:направление, записи разделяются ;:

services:
  proto-metric-analyzer:
    environment:
      POBP_MODEL_DEFAULT: "stl_zscore"
      POBP_MODEL_OVERRIDES: "service_resp_time:stl_zscore:up;service_error_sum:stl_zscore:up;service_calls_sum:stl_zscore:down"

Неизвестное имя модели приводит к ошибке конфигурации при запуске; некорректное значение направления записывается в журнал как предупреждение, и для этой метрики применяется значение POBP_DIRECTION_DEFAULT (переопределение модели при этом сохраняется).

Направление аномалии

Фильтр направления определяет, какая сторона выхода за границы диапазона считается аномалией:

Значение по умолчанию задаётся переменной POBP_DIRECTION_DEFAULT, для отдельной метрики — третьим элементом в POBP_MODEL_OVERRIDES.

Обучение и прогрев

Каждая модель переобучается на скользящем окне истории (POBP_ROLLING_TRAINING_WINDOW_SIZE, по умолчанию 7d) с интервалом POBP_RETRAINING_INTERVAL_MINUTES (по умолчанию 120 минут) и строит прогноз на горизонт POBP_FORECAST_HORIZON_MINUTES. Горизонт должен с запасом перекрывать интервал переобучения плюс фактическую длительность цикла обучения: на больших каталогах метрик полное переобучение может занимать часы, и если горизонт исчерпается раньше следующего цикла, прогноз перестанет обновляться. Число одновременно обучаемых моделей ограничено POBP_PARALLELISM, длительность обучения одной модели — POBP_TRAINING_TIMEOUT_SECONDS.

Модели stl_zscore и holtwinters не выполняют подгонку, пока не накоплено не менее двух полных суточных циклов данных минутного разрешения (около 2 суток). До этого момента модель считается необученной, а публикация её прогноза пропускается — это защищает от «схлопнутого» коридора, который на короткой истории давал бы поток ложных срабатываний.

Метрики базовой линии и сигналы аномалий

Для каждой профилируемой метрики платформа публикует сопутствующий набор значений в метрике <метрика>_prophet, различаемых лейблом value_type:

Подробнее о метриках базовой линии — Метрики и выражения для правил.

Какие метрики профилируются

Из коробки базовая линия рассчитывается для следующих метрик:

Для каждой из этих метрик автоматически публикуется набор метрик базовой линии <метрика>_prophet. Встроенные правила алертинга есть для метрик сервисов и ключевых транзакций (см. ниже). Для системных метрик базовая линия публикуется, но встроенного правила нет — при необходимости создайте собственное.

Встроенные правила выявления аномалий

Из коробки доступны правила алертинга в группе ANOMALY (критичность WARNING, срабатывание при выполнении условия в течение 7 минут). Каждое правило сравнивает фактическое значение метрики с верхней границей её базовой линии:

Скриншот: список правил, отфильтрованный по группе ANOMALY.

Все правила односторонние — срабатывают только при превышении верхней границы (value_type="yhat_upper") и только при наличии трафика. Дополнительные условия по трафику подавляют ложные срабатывания при простое сервиса и в период первичного обучения модели. Схема выражения:

sum(services_calls) by (service, service_id, service_group)
  > sum(services_calls_prophet{value_type="yhat_upper"}) by (service, service_id, service_group)
  and avg(services_calls) by (service, service_id, service_group) > 0

Эти правила встроенные: их нельзя редактировать или удалить, но можно отключить или создать копию и настроить уже копию — см. Настройка оповещений → Работа с правилами.

max(services_calls_prophet{value_type="anomaly_windowed"}) by (service, service_id) > 0

Подавление ложных срабатываний

Помимо условий по трафику во встроенных правилах, в самом расчёте базовой линии работают четыре механизма.

Оконный сигнал аномалии. Отдельная аномальная точка почти всегда шум. Платформа ведёт скользящее окно длиной POBP_ANOMALY_WINDOW_MINUTES (по умолчанию 30 минут), считает в нём долю аномальных точек (value_type="anomaly_window_fraction") и поднимает флаг anomaly_windowed, только когда доля достигла POBP_ANOMALY_WINDOW_FRACTION_THRESHOLD (по умолчанию 0.3). Мгновенный флаг anomaly при этом сохраняется для совместимости.

Защита от «отравления» модели. При переобучении точки ранее обнаруженных аномалий маскируются, чтобы прошлый инцидент не был усвоен моделью как нормальное поведение (POBP_MASK_ANOMALIES_IN_TRAINING, по умолчанию включено). Если маскирование затронуло бы более POBP_MASK_CAP_FRACTION обучающей выборки (по умолчанию 10 %), оно пропускается с предупреждением в журнале — это защищает метрики с длительной аварией от обучения на пустых данных.

Адаптивная дисперсия по времени суток. При включённом POBP_ADAPTIVE_VARIANCE (по умолчанию включено) разброс остатков считается отдельно для каждого интервала суток размером POBP_VARIANCE_BUCKET_MINUTES (по умолчанию 60 минут). Коридор автоматически расширяется в шумные часы и сужается в спокойные. Механизм применяется к моделям stl_zscore и holtwinters; prophet использует собственную оценку неопределённости и не затрагивается.

Контроль прогрева. Пока не накоплено двух полных суточных циклов данных, модели stl_zscore и holtwinters не публикуют прогноз (см. Обучение и прогрев).

Общая чувствительность задаётся множителем POBP_Z_THRESHOLD (по умолчанию 3.0) — он применяется единообразно ко всем трём моделям: для stl_zscore и holtwinters это множитель среднеквадратичного отклонения остатков, для prophet из него выводится ширина доверительного интервала. Уменьшение значения повышает чувствительность и число срабатываний, увеличение — снижает.

Как добавить метрики в профилирование

Список профилируемых метрик задаётся в конфигурации сервиса proto-metric-analyzer через переменные окружения — изменение кода не требуется. Доступны две переменные:

• POBP_ADDITIONAL_METRICS_LIST — рекомендуемый способ расширения. Список метрик через ;, который добавляется к стандартному набору (с дедупликацией).
• POBP_METRICS_LIST — полностью заменяет стандартный набор (тогда нужно перечислить и стандартные метрики, и новые).

В элементе списка можно указать селектор лейблов, например up{app="payments"} — каждая подходящая серия профилируется отдельно.

Пример для docker-compose (добавить APDEX сервисов и свою метрику):

services:
  proto-metric-analyzer:
    environment:
      POBP_ADDITIONAL_METRICS_LIST: "services_apdex;my_custom_metric"

После применения для новой метрики автоматически появятся метрики базовой линии <метрика>_prophet.

sum(my_custom_metric) by (service, service_id)
  > sum(my_custom_metric_prophet{value_type="yhat_upper"}) by (service, service_id)

max(my_custom_metric_prophet{value_type="anomaly_windowed"}) by (service, service_id) > 0

Дополнительные параметры

Поведение профилирования настраивается переменными окружения сервиса proto-metric-analyzer.

Выбор модели и направления

Обучение

Чувствительность и подавление ложных срабатываний

Что дальше

• Алертинг в Proto Observability Platform — обзор модуля алертинга.
• Настройка оповещений — создание каналов, политик и правил, работа с правилами.
• Метрики и выражения для правил — метрики сервисов и метрики базовой линии _prophet.
• Управление SLO — цели уровня обслуживания и правила по скорости сжигания бюджета ошибок.