Действительно ли полезен ML для снижения шума от алертов? Изучаем на примере одного метода


Предыстория


Последние пару лет рынок систем мониторинга будоражила аббревиатура AIOps. Все вендоры начали гнаться за использованием искусственного интеллекта в своих сложных и дорогих системах. Термины “root cause analysis”, “correlation”, “ML-tools”, “anomaly detection”, “incident prediction”, “noise reduction” основательно и, наверное, уже навсегда поселились на маркетинговых материалах и сайтах различных систем мониторинга.


Как мы знаем, рекламные буклеты одно, а инженерные будни другое. Наверное, многие сталкивались с ситуацией, когда обещания продавцов тех или иных технологических новинок сталкивались, как Титаник с айсбергом, с практикой внедрения, особенно в сложном ИТ-окружении больших компаний. Поэтому я изначально смотрел с большим скепсисом и не разделял ажиотажа вокруг этой темы. Тем более, когда есть такие железобетонные решения как Zabbix, Prometheus и Elastic. Но хайп хайпом, скепсис скепсисом, а мы все-таки инженеры и должны все проверять и изучать на практике, а не задаваться вопросом верить/ не верить в “magic button” от именитых вендоров и многообещающих стартапов. И вот, после очередной презентации от интегратора и обещаний за немаленькие деньги “рая на нашей грешной земле инженеров эксплуатации” нас собралась небольшая инициативная группа, которая решила “пощупать”, что все-таки из себя представляет эта магия искусственного интеллекта и машинного обучения в нашей практике. Таким образом, родились материалы и даже небольшой pet-проект, которыми я бы хотел поделиться с вами.


Жизненная проблема служб мониторинга


Самая распространенная проблема систем мониторинга — это адский шум, которые они создают при своей работе. От потока генерируемых сообщений захлебываются все дежурные службы. И в какой-то момент инженеры начинают воспринимать этот шум как обычное явление и перестают обращать внимание на очередную мигающую красную плашку. Результат всегда один и тот же: красное лицо и опущенные в пол глаза начальника службы мониторинга на совещании у ИТ-директора. Следующий раунд — это более умные настройки типа “три подряд проваленные проверки”, триггерные зависимости и т.п. Это помогает, но возрастает риск пропустить проблему и все равно приходиться начинать свой день с просмотров “графаны и кибаны”, этих вечных спутниц системного администратора. Иначе — опять “красное лицо”.


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


Для данной статьи далее приводятся результаты наших наработок на реальных открытых данных. В качестве таких данных мы взяли HTTP-проверки сайтов основных ритейлеров. Самая яркая выборка получилась у “Магнита”, отдельное ему спасибо за это. Кстати, на downdetector его нет, а, наверное, стоило бы добавить ;)


Классика


Для нашего примера берем интервал времени
2020-10-14 14:00 +03:00 минус 38 часов (ранее данных не было), т.е. [2020-10-12 23:00:00 +03:00 – 2020-10-14 14:00 +03:00]. За этот период всего прошло проверок: 3612.


Если брать стандартный алгоритм оповещения по порогам (threshold), который формирует оповещение, если предыдущее значение было 0, а текущее 1, то на такой выборке сформировалось бы 179 оповещений. При этом имеем самую высокую оперативность в оповещении о проблемах (см. рис. 1: распределение оповещений по классическому пороговому алгоритму. Время в UTC. Синим показаны проваленные проверки, красным оповещения
).


Рис.1Рис. 1. Распределение оповещений по классическому пороговому алгоритму. Время в UTC. Синим показаны проваленные проверки, красным — оповещения.


Если использовать алгоритм вычисления порога данных, при котором оповещение приходит только в случае проваленных подряд 3-х проверках, то по данной выборке сформировалось бы 44 оповещения (см. рис. 2). При этом задержка алерта уже составит как минимум 4 интервала проверки. Также мы рискуем напороться на проблему отсутствия алерта для ряда вида “0110010011101010…”, которую, можно частично решить, установив дополнительный триггер на % проваленных за период времени (обычно 1 час), что опять-таки приведет к потере оперативности.


Рис.2Рис. 2. Распределение оповещений по 3-м проваленным подряд проверкам. Синим показаны проваленные проверки, красным — оповещения.


Таким образом “классические” алгоритмы заставляют выбирать: либо флуд-поток алертов, либо потеря оперативности. Причем при ограниченных ресурсах флуд-поток зачастую приводит к не меньшей потере оперативности, чем при сложных настройках триггеров. Осталось посмотреть, что нам в такой ситуации могут предложить методы AI/ML.


А что ML?


Прежде чем пойдем дальше, сразу бы хотелось оговориться, что мы не являемся Data Scientist и перед нами не стояла задача выбора оптимального метода. Наша задача заключалась в том, чтобы, во-первых, найти любой метод, который соответствовал 3-м критериям:


  1. Давал бы практическую пользу. В нашем случае — реально бы снижал количество алертов, при этом не пропуская проблемы.
  2. Был бы реализуем без серьезных вычислительных затрат, и, соответственно, его можно было бы встроить в пайплайн обработки собираемых метрик.
  3. Результаты, получаемые на выходе, можно было бы "качественно" интерпретировать и предсказать. Т.е. по сути метод должен быть достаточно простым и хотя бы "на ощупь" понятным без глубокого погружения в теорию вероятности, нечеткую логику и прочие радости высшей математики, частично подзабытые с университетской скамьи.

В нашем случае таким методом стал DetectIidSpike из библиотеки ML.NET. Основная идея данного метода: проверить укладывается или нет каждое новое значение на временном ряде в существующую выборку. Если не укладывается, то обозначить такое значение как аномалию. Другими словами для каждого нового значения проверяется "нулевая" гипотеза и если она подтверждается, то детектируется аномалия. После чего новое значение переобучает модель.
Отсюда очень важным для нормальной работы метода DetectIidSpike являются его два параметра:


  • confidence — достоверность обнаружения аномалии в диапазоне [0, 100]. Чем больше значение, тем по сути шире полоса и, соответственно, тем больше значений будут восприниматься, как нормальные;
  • pvalueHistoryLength — размер скользящего окна для вычисления p-value. Данный критерий как раз-таки используется в алгоритме для подтверждения "нулевой гипотезы", она же аномалия.

Теперь посмотрим, как данный алгоритм работает на практике. В рассматриваемом примере у нас HTTP-проверки сайтов, т.е. на выходе имеем единицы и нули. Для нашего алгоритма это вот не совсем подходящий материал. Здесь желательно иметь дело все-таки не с бинарными значениями. Для этого мы применили агрегацию данных по временным интервалам, т.е. превратили нашу последовательность из нулей и единичек на интервале 5 мин в число: отношение проваленных проверок к общему количеству проверок в этом интервале. Здесь велико было искушение взять просто количество проваленных, но это в корне неправильно, т.к. соседние интервалы могут отличаться по количеству проверок. Это может происходить как по причине динамических настроек проверок (например, при проблеме чаще идут проверки), так и по банальной причине задержек в проверках и пограничных "конфликтах", когда проверки попадают в соседние интервалы.


После этих подготовительных операций мы потоково направляем получаемые данные в наш прототип детектора аномалий в виде “заданий”. Стратегия запуска задания заключается в том, чтобы загрузить модель, рассчитанную в предыдущем раунде проверок, проверить является ли значение пиком (аномалией), провести «дообучение» модели полученным значением и сохранить измененную модель обратно на диск (или в память). Для этого наш планировщик раз в 5 мин формирует список заданий на вычисление в детекторе аномалий. Агенты, подключенные к планировщику по websockets протоколу, получают задания и выполняют их. На выходе мы имеем аномалии и оповещения, а сама система агентов очень легко масштабируется (у нас kubernetes реплики).


На приведенной выборке при настройках алгоритма (confidence: 95, pvalueHistoryLength: 5), мы в итоге получили 36 аномалий. Следует учитывать, что аномалией считается также резкое снижение количества проваленных проверок, т.е. за аномалии принимается восстановление работоспособности. Отфильтровав сообщения о восстановлении, имеем итоговые 24 оповещения. (Кстати, метод в библиотеке имеет соответствующую настройку).


Рис. 3Рис. 3. Аномалии и проваленные проверки (confidence: 95, pvalueHistoryLength: 5) Синим показаны относительные значений проваленных проверок, красным — оповещения


Как видно из графика (рис. 3), при недостаточном уровне обучения модель генерировала большое количество аномалий вначале, которое значительно сократилось на последующем интервале после достаточного обучения. А также, что имеет первостепенное значение, не были упущены практически никакие проблемы и полученный детектор аномалий достаточно оперативно реагировал на возникающие провалы (закрашенные области).


Для сравнения на рис. 4 приведен результат работы модели со скользящим окном pvalueHistoryLength=12 и достоверностью confidence: 98. Здесь результат: 14 аномалий.


Рис. 4Рис. 4. Аномалии и проваленные проверки (confidence: 98, pvalueHistoryLength: 12)


Краткий вывод


Таким образом, применяя метод DetectIidSpike нам удалось снизить количество оповещений практически в два раза (24 против 44) по сравнению с проверкой на 3 подряд проваленные проверки, и в 7,5 раз (24 против 179) с однократным трешхолдом. При этом, самое главное, не теряя в качестве и оперативности. А это говорит нам о том, что методы ML могут нам действительно на практике помочь в задачах мониторинга. По крайней мере, приведенный метод точно :)


P.S.: Если у вас есть идеи или конкретные методы ML, которые вы опробовали для решения проблемы флуд-алертинга, пишите в комментариях. Будет интересно попробовать.


P.P.S.: Ниже приведу еще несколько скриншотов из нашего pet-проекта с реальными данными проведенных проверок и сгенерированных аномалий. Можете посмотреть насколько эффективно или неэффективно (for whom how) работает алгоритм (желтый кружок — аномалии на выбранном интервале).


Несколько еще интересных скриншотов



Комментарии 3

    0
    За статью спасибо! Однако самое сложное в этих задачах — конкретная реализация.

    >>>даже небольшой pet-проект, которыми я бы хотел поделиться с вами.
    А вот и не поделились! )
      0
      Спасибо за интерес!
      Мы с ребятами как раз-таки подбирали метод и библиотеку, который можно было бы легко встроить и использовать. Результат с ML.NET действительно получился, на мой взгляд, достойный, как по скорости, так и по размеру модели. Если есть интерес, то архитектуру решения можно будет описать еще в одной статье.

      А по pet-project поделился, но скромно: скриншоты в самом конце статьи. Основная идея сделать облачный мониторинг с встроенными реально полезными ML-инструментами (не хайпа ради). При этом, чтобы все можно было подключить реально в пару кликов, и таким инструментом могли пользоваться непрофессиональные пользователи. А ML им как раз-таки очень и очень нужен — у них нет времени и навыков постоянно тюнить систему мониторинга.

      Проект (Hamster Cloud), в принципе, уже запущен: можно зарегистрироваться и бесплатно поставить какой-нибудь свой веб-ресурс на мониторинг.
        0
        Спасибо, было бы интересно почитать вкратце про архитектуру и необходимые мощности для обработки, скажем, 1000 метрик с точками раз в 1-5 минут.

        Видел где-то расчёт для OpenDistro Anomaly Detector'a, там вроде на 3х машинках с 16GB RAM они обещали расчёт ~2400 метрик, но не могу сейчас найти эту статейку.

        А сайт Ваш потестим. Только почему мы сконцентрировались только на сайт-мониторинге? Всё равно ведь на каких данных аномалии искать. Вот ребятки не стали сужать себе область применения — и вроде отлично себя чувствуют, прайс ломят — моё почтение.

    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

    Самое читаемое