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

Mon, 01 Jan 0001 00:00:00 +0000

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

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

Что это такое

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

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

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

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

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

Имя модели	Алгоритм	Особенности
`stl_zscore`	Сезонно-трендовое разложение методом Loess (STL) с оценкой отклонения по остаткам (z-score)	Используется по умолчанию. Устойчив к выбросам, дёшев по ресурсам, поддерживает адаптивную дисперсию по времени суток
`holtwinters`	Тройное экспоненциальное сглаживание (Holt-Winters, `ExponentialSmoothing`)	Хорошо описывает плавный тренд с устойчивой сезонностью, поддерживает адаптивную дисперсию по времени суток
`prophet`	Аддитивная модель Prophet с суточной и недельной сезонностью	Собственный механизм оценки неопределённости; полезен на длинных рядах с выраженными сезонными эффектами и пропусками данных

Модель по умолчанию для всех метрик задаётся переменной 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 (переопределение модели при этом сохраняется).

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

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

Значение	Что отмечается как аномалия	Типичное применение
`up`	только превышение верхней границы	время отклика, доля ошибок
`down`	только падение ниже нижней границы	количество вызовов, доля успешных операций
`both`	обе стороны	значение по умолчанию

Значение по умолчанию задаётся переменной 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 независимо от выбранного алгоритма. Суффикс сохранён для обратной совместимости с существующими дашбордами и правилами алертинга и не означает, что расчёт выполняется моделью Prophet.

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

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

`value_type`	Тип	Назначение
`yhat`	значение	прогноз (центр ожидаемого диапазона)
`yhat_lower`	значение	нижняя граница ожидаемого диапазона
`yhat_upper`	значение	верхняя граница ожидаемого диапазона
`anomaly`	0/1	мгновенный признак аномалии в текущей точке
`anomaly_severity`	0.0–…	степень отклонения от границы диапазона
`anomaly_window_fraction`	0.0–1.0	доля аномальных точек в скользящем окне
`anomaly_windowed`	0/1	рекомендуемый сигнал для правил алертинга: поднимается, только когда доля аномальных точек в окне достигла порога
`_stale`	1	прогноз устарел — модель давно не переобучалась или горизонт исчерпан

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

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

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

Категория	Метрика	Показатель
Сервисы	`services_calls`	количество вызовов
Сервисы	`services_callduration`	время отклика
Сервисы	`services_errorcallsperc`	доля вызовов с ошибками
Ключевые транзакции	`calls_keybusinesstransactioncount`	количество вызовов
Ключевые транзакции	`calls_keybusinesstransactionduration`	время отклика
Ключевые транзакции	`calls_keybusinesstransactionerrorperc`	доля вызовов с ошибками
Хосты	`system_cpu_idle`	простой CPU
Хосты	`system_mem_usable`	доступная память

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

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

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

Правило	Метрика	Когда срабатывает
Аномалия в количестве вызовов	`services_calls`	фактическое число вызовов выше ожидаемого диапазона
Аномалия во времени отклика	`services_callduration`	время отклика выше ожидаемого
Аномалия в количестве ошибок	`services_errorcallsperc`	доля ошибок выше ожидаемой
Аномалия в количестве вызовов ключевой транзакции	`calls_keybusinesstransactioncount`	то же для ключевой транзакции
Аномалия во времени отклика ключевой транзакции	`calls_keybusinesstransactionduration`	то же для ключевой транзакции
Аномалия в проценте ошибок ключевой транзакции	`calls_keybusinesstransactionerrorperc`	то же для ключевой транзакции

Скриншот: список правил, отфильтрованный по группе 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.

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

Переменная	По умолчанию	Назначение
`POBP_MODEL_DEFAULT`	`stl_zscore`	модель по умолчанию: `stl_zscore`, `holtwinters` или `prophet`
`POBP_MODEL_OVERRIDES`	—	модель и направление для отдельных метрик: `метрика:модель[:направление]`, через `;`
`POBP_DIRECTION_DEFAULT`	`both`	направление аномалии по умолчанию: `up` / `down` / `both`

Обучение

Переменная	По умолчанию	Назначение
`POBP_ROLLING_TRAINING_WINDOW_SIZE`	`7d`	объём истории для обучения модели
`POBP_RETRAINING_INTERVAL_MINUTES`	`120`	как часто переобучается модель
`POBP_FORECAST_HORIZON_MINUTES`	`max(240, интервал × 3)`	горизонт прогноза; должен с запасом перекрывать интервал переобучения и длительность цикла обучения
`POBP_PARALLELISM`	`2`	сколько моделей обучается одновременно; верхний предел зависит от числа ядер контейнера
`POBP_TRAINING_TIMEOUT_SECONDS`	`300`	предельная длительность обучения одной модели

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

Переменная	По умолчанию	Назначение
`POBP_Z_THRESHOLD`	`3.0`	чувствительность: множитель сигмы, единый для всех трёх моделей (меньше — чувствительнее)
`POBP_ANOMALY_WINDOW_MINUTES`	`30`	длина скользящего окна для оконного сигнала
`POBP_ANOMALY_WINDOW_FRACTION_THRESHOLD`	`0.3`	доля аномальных точек в окне, при которой поднимается `anomaly_windowed`
`POBP_MASK_ANOMALIES_IN_TRAINING`	`True`	маскировать ранее обнаруженные аномалии перед переобучением
`POBP_MASK_CAP_FRACTION`	`0.10`	предельная доля обучающей выборки, которую разрешено маскировать
`POBP_ADAPTIVE_VARIANCE`	`True`	считать разброс отдельно по интервалам суток (`stl_zscore`, `holtwinters`)
`POBP_VARIANCE_BUCKET_MINUTES`	`60`	размер интервала суток для адаптивной дисперсии; допустимо от 5 до 360

Версия

Параметры POBP_Z_THRESHOLD и POBP_DIRECTION_DEFAULT, оконный сигнал аномалии, защита от «отравления» модели и адаптивная дисперсия по времени суток доступны начиная с версии 201.

Что дальше

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

Документация Proto Observability Platform – Holt-Winters