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

AB Tasty предлагает решения для создания онлайн-экспериментов и оптимизации взаимодействия с пользователем. Наши продукты используются в широком спектре отраслей с клиентами любого размера. Следовательно, отслеживаемые нами таймсерии имеют чрезвычайно разнообразные закономерности. Это затрудняет создание эффективных правил обнаружения аномалий для всех наших клиентов.

В этом блоге описаны проблемы обнаружения аномалий в реальной жизни и способы их решения в ThirdEye.

Сценарий использования

Давайте посмотрим на типичный таймсериал, который мы хотим отслеживать: количество посетителей.

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

У нас 4000 клиентов, так что у нас будет 4000 таких сигналов. Мы хотим обнаружить потерю данных. Поскольку мы хотим быстро обнаруживать инциденты, мы проверяем значения каждый час. Мы определяем потенциальную потерю данных как снижение на 80% по сравнению с базовым уровнем.
Например:
- базовое значение составляет 200. Наблюдаемое значение 140 → ОК
- базовое значение 200. Наблюдаемое значение 20 → Аномалия!

Базовый показатель - это значение, которое мы ожидаем увидеть на основе исторических данных. Вычисление базовой линии может быть простым или основываться на сложных моделях машинного обучения.

Выглядит просто, правда? Посмотрим, как мы реализуем это в ThirdEye.

Реализация

Во-первых, нам нужно выбрать способ вычисления базовой линии . Начнем с простого.
Учитывайте сезонность: нет смысла сравнивать понедельник с воскресеньем или сравнивать 18:00 с 6:00. Следовательно, для вычисления ожидаемого значения мы используем значения для одного дня недели и одного часа.
Фактически, чтобы учесть шум, вместо того, чтобы брать только предыдущее значение, мы возьмем среднее из двух последних значений:

Мы реализуем такое правило в Thirdeye:

Сразу после написания конфигурации обнаружения мы можем предварительно просмотреть поведение на исторических данных. Это помогает проверить работоспособность:

Обнаружено большое аномальное падение 15 сентября! Большой. Но есть еще одна аномалия - красная точка слева, которая выглядит как ложное срабатывание.
Решите первую задачу по обнаружению аномалий в реальном времени:

Задача 1: шум в малых значениях

Рассмотрим клиента, у которого шумит около ± 100 посетителей.
В течение дня у клиента около 2,5 тыс. посетителей в час. ± 100 посетителей - это изменение всего на 4%, поэтому правило обнаружения не срабатывает.
Но что происходит ночью, когда посещаемость очень низкая? Если среднее значение ночью равно 100, в некоторых неудачных случаях у вас может быть базовое значение 180 посетителей, а текущее значение 30 посетителей: падение 83%!
Именно это и произошло выше. Сначала это выглядит нормально: мы получаем это ложное срабатывание только один раз в предварительном просмотре. Мы могли оценить, что у нас есть эта ошибка, только раз в месяц. Но помните: у нас есть 4000 таймсерий для мониторинга. Одно ложное срабатывание в месяц для каждой таймсерии означает 130 ложных срабатываний в день! Это недопустимо.
Мы могли бы подумать об усреднении эффекта шума, используя больше исторических данных. Это могло бы помочь, но не решило бы реальной проблемы: правило оповещения не управляет сезонностью.
Мы исправим это с помощью модели машинного обучения, но сначала рассмотрим другую проблему.

Вызов 2: важные тенденции

Рассмотрим таймсерии с важной тенденцией: исторические данные быстро станут неактуальными.

Мы видим, что базовая линия (оранжевая пунктирная линия) слишком велика. Среднее значение быстро уменьшается, поэтому значения за предыдущие недели не актуальны. Как человек, мы видим нисходящий тренд каждый день, но простое правило использует данные только за t-7 дней и t-14 дней. Мы получаем много ложных срабатываний.
Проблема в том, что правило предупреждения не управляет важными тенденциями.

Представляем модели машинного обучения

Для решения двух описанных выше проблем мы используем модель Холта-Винтерса. Эта модель машинного обучения изучает тренд и сезонность временных рядов.
Мы реализуем правило в ThirdEye:

Мы просматриваем правило на двух сложных таймсериях:

Это выглядит лучше: модель ML не попадает в ловушку сезонностей и тенденций. Но возникают новые проблемы: появляются новые ложные срабатывания, и их трудно объяснить.
Обратите внимание на параметр sensitivity в config. В малых размерах модель допускает значения, далекие от базовой линии. В больших размерах модель менее терпима: она может вызвать множество ложных срабатываний. Проблема в том, что точная настройка sensitivity не является простой задачей. Самое главное, sensitivity не помогает достичь нашей основной цели: обнаруживать 80% падения.

Мы хотели бы получить лучшее из двух правил обнаружения:
→ модель машинного обучения для управления сложными шаблонами в таймсериях.
→ простое правило для обеспечения соблюдения наших бизнес-требований.

В ThirdEye легко комбинировать правила: мы используем модель машинного обучения в качестве базового детектора и фильтруем аномалии, которые не соответствуют нашему бизнес-правилу:

Обратите внимание, что мы установили более высокое значение sensitivity для модели машинного обучения. Ничего страшного, ложные срабатывания будут отфильтрованы бизнес-правилом.

Теперь у нас есть надежное правило! По крайней мере, так кажется.

Вызов 3: ложные тенденции

Подумайте о продажах, сроках подписки на мероприятия, продвижении выпуска продукта ... все это распространяется на несколько дней, но не вечно.
Что происходит потом?

Что-то похоже на тенденцию, но это временно. Модель изучает это и делает нерелевантные прогнозы: мы получаем ложное срабатывание. С нашими многочисленными клиентами подобные проблемы случаются каждую неделю.
Управлять такой закономерностью с помощью модели машинного обучения чрезвычайно сложно, поэтому мы добавляем новое бизнес-правило: мы сравниваем текущее значение со средним значением за последние 5 недель. Идея состоит в том, что на медианное значение за долгую историю не так сильно влияют ложные тенденции. Мы не рассматриваем аномалию, если разница со средним значением незначительна.

Реализуем фильтр:

Получаем превью:

Никаких ложных срабатываний! В ThirdEye легко наложить эвристику на модели машинного обучения. Это ключ к достижению надежных правил обнаружения. Мы считаем, что это обязательная функция в любой промышленной системе обнаружения аномалий.

Проблема 4: временные ошибки

Проблема, которую мы часто наблюдаем, - это временное падение данных:
- клиенты выполняют обслуживание: их трафик снижается на несколько минут.
- у нашего конвейера задержка больше, чем обычно: во время обнаружения значения маленькие.
Это не ложные срабатывания, но такие аномалии могут спамить много. Если это совместимо с SLA, мы хотим игнорировать такие аномалии.

Сложим еще одно правило: игнорировать аномалии, длящиеся менее 2 часов:

Получаем превью:

Временная ошибка игнорируется.

Теперь у нас есть надежное правило обнаружения аномалий! Вот полная конфигурация yaml:

Другие проблемы

Мы надеемся, что эти визуальные эффекты помогли вам понять проблемы обнаружения аномалий в реальной жизни. Ниже приведены некоторые другие проблемы и способы их решения в ThirdEye.

  • праздники: классическая тема в таймсерии. В ThirdEye легко управлять: вы можете игнорировать аномалии на определенных таймфреймах. Собственно, наша главная задача в AB Tasty - правильно выбрать календари: в зависимости от страны праздники бывают совершенно разными! Для каждого клиента мы определяем основные страны и берем соответствующие календари.

  • предупреждение о спаме: задания по обнаружению запускаются каждый час . Если аномалия не устранена, ThirdEye будет повторно отправлять предупреждения. Чтобы этого избежать, можно объединить аномалии. Мы объединяем аномалии, идущие подряд или с интервалом в один час. Завершаем слияние через 3 дня. Таким образом, мы получаем новое предупреждение, если аномалия все еще существует.

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

Производительность в масштабе

В этой статье мы сосредоточились на тонкой настройке единственного правила обнаружения. В AB Tasty это не масштабируется, потому что нам нужно создать тысячи правил обнаружения. Мы создали инструмент для создания правил на основе бизнес-информации, такой как SLA, пакет продуктов и отрасль. Мы называем это построителем правил обнаружения .
Вместо измерения производительности отдельного правила мы измеряем производительность самого построителя правил обнаружения и постепенно настраиваем его .

Мы делаем это на производстве.

Мы выполняем следующий итерационный цикл:
1. Создание новых правил
2. Запускаем задания обнаружения для производственных данных. , для всех наших клиентов. Не отправляйте оповещения в дежурную систему.
3. Проанализируйте аномалии. Назовите их полезными или бесполезными. Определите пределы текущих сгенерированных правил. Определите возможности точной настройки.
4. Добавьте наиболее общие тонкие настройки в построитель правил обнаружения.

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

Бесплатного обеда для масштабного обнаружения аномалий не существует

Заключение

Даже простое на первый взгляд правило обнаружения может оказаться сложным для реализации в реальной жизни. Мы определили общие проблемные шаблоны в таймсериях и объяснили, как мы управляем ими в ThirdEye.
Мы надеемся, что эта статья поможет сообществу разработчиков данных в их следующих проектах по обнаружению аномалий.

Ресурсы:

- Сяохуэй Сунь, Умные оповещения в ThirdEye, 2019, Linkedin
- Сирил де Катё, Качество данных: обнаружение аномалий таймсерий в масштабе с помощью Thirdeye, 2021, AB Tasty
- Тобиас Мейси, Глеб Межанский , Стратегии упреждающего управления качеством данных, 2021 г., Подкаст по разработке данных
- Проведите исследования, близкие к производственным, Спектор и др., Гибридный подход Google к исследованиям, 2012 г.
- Компоненты временных рядов в Hyndman, RJ, & Athanasopoulos, G. (2018) Прогнозирование: принципы и практика, 2-е издание, OTexts: Мельбурн, Австралия. OTexts.com/fpp2. Доступ 15 сентября 2021 г.

Если не указано иное, изображение автора.