[Системное администрирование, IT-инфраструктура, Алгоритмы, Машинное обучение] Действительно ли полезен ML для снижения шума от алертов? Изучаем на примере одного метода
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Предыстория
Последние пару лет рынок систем мониторинга будоражила аббревиатура 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. Распределение оповещений по классическому пороговому алгоритму. Время в UTC. Синим показаны проваленные проверки, красным — оповещения.
Если использовать алгоритм вычисления порога данных, при котором оповещение приходит только в случае проваленных подряд 3-х проверках, то по данной выборке сформировалось бы 44 оповещения (см. рис. 2). При этом задержка алерта уже составит как минимум 4 интервала проверки. Также мы рискуем напороться на проблему отсутствия алерта для ряда вида “0110010011101010…”, которую, можно частично решить, установив дополнительный триггер на % проваленных за период времени (обычно 1 час), что опять-таки приведет к потере оперативности.
Рис. 2. Распределение оповещений по 3-м проваленным подряд проверкам. Синим показаны проваленные проверки, красным — оповещения.
Таким образом “классические” алгоритмы заставляют выбирать: либо флуд-поток алертов, либо потеря оперативности. Причем при ограниченных ресурсах флуд-поток зачастую приводит к не меньшей потере оперативности, чем при сложных настройках триггеров. Осталось посмотреть, что нам в такой ситуации могут предложить методы AI/ML.
А что ML?
Прежде чем пойдем дальше, сразу бы хотелось оговориться, что мы не являемся Data Scientist и перед нами не стояла задача выбора оптимального метода. Наша задача заключалась в том, чтобы, во-первых, найти любой метод, который соответствовал 3-м критериям:
- Давал бы практическую пользу. В нашем случае — реально бы снижал количество алертов, при этом не пропуская проблемы.
- Был бы реализуем без серьезных вычислительных затрат, и, соответственно, его можно было бы встроить в пайплайн обработки собираемых метрик.
- Результаты, получаемые на выходе, можно было бы "качественно" интерпретировать и предсказать. Т.е. по сути метод должен быть достаточно простым и хотя бы "на ощупь" понятным без глубокого погружения в теорию вероятности, нечеткую логику и прочие радости высшей математики, частично подзабытые с университетской скамьи.
В нашем случае таким методом стал DetectIidSpike из библиотеки ML.NET. Основная идея данного метода: проверить укладывается или нет каждое новое значение на временном ряде в существующую выборку. Если не укладывается, то обозначить такое значение как аномалию. Другими словами для каждого нового значения проверяется "нулевая" гипотеза и если она подтверждается, то детектируется аномалия. После чего новое значение переобучает модель.
Отсюда очень важным для нормальной работы метода DetectIidSpike являются его два параметра:
- confidence — достоверность обнаружения аномалии в диапазоне [0, 100]. Чем больше значение, тем по сути шире полоса и, соответственно, тем больше значений будут восприниматься, как нормальные;
- pvalueHistoryLength — размер скользящего окна для вычисления p-value. Данный критерий как раз-таки используется в алгоритме для подтверждения "нулевой гипотезы", она же аномалия.
Теперь посмотрим, как данный алгоритм работает на практике. В рассматриваемом примере у нас HTTP-проверки сайтов, т.е. на выходе имеем единицы и нули. Для нашего алгоритма это вот не совсем подходящий материал. Здесь желательно иметь дело все-таки не с бинарными значениями. Для этого мы применили агрегацию данных по временным интервалам, т.е. превратили нашу последовательность из нулей и единичек на интервале 5 мин в число: отношение проваленных проверок к общему количеству проверок в этом интервале. Здесь велико было искушение взять просто количество проваленных, но это в корне неправильно, т.к. соседние интервалы могут отличаться по количеству проверок. Это может происходить как по причине динамических настроек проверок (например, при проблеме чаще идут проверки), так и по банальной причине задержек в проверках и пограничных "конфликтах", когда проверки попадают в соседние интервалы.
После этих подготовительных операций мы потоково направляем получаемые данные в наш прототип детектора аномалий в виде “заданий”. Стратегия запуска задания заключается в том, чтобы загрузить модель, рассчитанную в предыдущем раунде проверок, проверить является ли значение пиком (аномалией), провести «дообучение» модели полученным значением и сохранить измененную модель обратно на диск (или в память). Для этого наш планировщик раз в 5 мин формирует список заданий на вычисление в детекторе аномалий. Агенты, подключенные к планировщику по websockets протоколу, получают задания и выполняют их. На выходе мы имеем аномалии и оповещения, а сама система агентов очень легко масштабируется (у нас kubernetes реплики).
На приведенной выборке при настройках алгоритма (confidence: 95, pvalueHistoryLength: 5), мы в итоге получили 36 аномалий. Следует учитывать, что аномалией считается также резкое снижение количества проваленных проверок, т.е. за аномалии принимается восстановление работоспособности. Отфильтровав сообщения о восстановлении, имеем итоговые 24 оповещения. (Кстати, метод в библиотеке имеет соответствующую настройку).
Рис. 3. Аномалии и проваленные проверки (confidence: 95, pvalueHistoryLength: 5) Синим показаны относительные значений проваленных проверок, красным — оповещения
Как видно из графика (рис. 3), при недостаточном уровне обучения модель генерировала большое количество аномалий вначале, которое значительно сократилось на последующем интервале после достаточного обучения. А также, что имеет первостепенное значение, не были упущены практически никакие проблемы и полученный детектор аномалий достаточно оперативно реагировал на возникающие провалы (закрашенные области).
Для сравнения на рис. 4 приведен результат работы модели со скользящим окном pvalueHistoryLength=12 и достоверностью confidence: 98. Здесь результат: 14 аномалий.
Рис. 4. Аномалии и проваленные проверки (confidence: 98, pvalueHistoryLength: 12)
Краткий вывод
Таким образом, применяя метод DetectIidSpike нам удалось снизить количество оповещений практически в два раза (24 против 44) по сравнению с проверкой на 3 подряд проваленные проверки, и в 7,5 раз (24 против 179) с однократным трешхолдом. При этом, самое главное, не теряя в качестве и оперативности. А это говорит нам о том, что методы ML могут нам действительно на практике помочь в задачах мониторинга. По крайней мере, приведенный метод точно :)
P.S.: Если у вас есть идеи или конкретные методы ML, которые вы опробовали для решения проблемы флуд-алертинга, пишите в комментариях. Будет интересно попробовать.
P.P.S.: Ниже приведу еще несколько скриншотов из нашего pet-проекта с реальными данными проведенных проверок и сгенерированных аномалий. Можете посмотреть насколько эффективно или неэффективно (for whom how) работает алгоритм (желтый кружок — аномалии на выбранном интервале).
Несколько еще интересных скриншотов
SPL
===========
Источник:
habr.com
===========
Похожие новости:
- [Разработка под MacOS, Машинное обучение, Софт, Искусственный интеллект, TensorFlow] Apple представила форк TensorFlow для чипа M1
- [Python, Машинное обучение, Искусственный интеллект, TensorFlow] Нейросеть анализирует сексуальность игроков, пример машинной обработки и классификаци текста
- [Информационная безопасность, IT-инфраструктура, Удалённая работа] Виртуализация USB устройств в сетях
- [Машинное обучение] Измерение гендерных корреляций в предобученных NLP-моделях (перевод)
- [Машинное обучение, Робототехника, Искусственный интеллект, Транспорт, Будущее здесь] “Водитель, вы — слабое звено”: новая разработка Honda
- [Программирование, Машинное обучение] Ранжирование признаков с помощью Recursive Feature Elimination в Scikit-Learn (перевод)
- [Информационная безопасность, Обработка изображений, Машинное обучение, Искусственный интеллект] Насколько неуязвим искусственный интеллект?
- [Программирование, Машинное обучение, Искусственный интеллект, Голосовые интерфейсы] Open Source синтез речи SOVA
- [Big Data, Интернет вещей] Вебинар «Технологии RFID и BLE для контроля перемещения производственных активов»
- [Open source, Машинное обучение, Искусственный интеллект] DeepMind открыла код среды Lab2D для обучения нейросетей
Теги для поиска: #_sistemnoe_administrirovanie (Системное администрирование), #_itinfrastruktura (IT-инфраструктура), #_algoritmy (Алгоритмы), #_mashinnoe_obuchenie (Машинное обучение), #_monitoring (мониторинг), #_alerty (алерты), #_mashinnoe_obuchenie (машинное обучение), #_sistemnoe_administrirovanie (
Системное администрирование
), #_itinfrastruktura (
IT-инфраструктура
), #_algoritmy (
Алгоритмы
), #_mashinnoe_obuchenie (
Машинное обучение
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 18:59
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 Предыстория Последние пару лет рынок систем мониторинга будоражила аббревиатура 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. Распределение оповещений по классическому пороговому алгоритму. Время в UTC. Синим показаны проваленные проверки, красным — оповещения. Если использовать алгоритм вычисления порога данных, при котором оповещение приходит только в случае проваленных подряд 3-х проверках, то по данной выборке сформировалось бы 44 оповещения (см. рис. 2). При этом задержка алерта уже составит как минимум 4 интервала проверки. Также мы рискуем напороться на проблему отсутствия алерта для ряда вида “0110010011101010…”, которую, можно частично решить, установив дополнительный триггер на % проваленных за период времени (обычно 1 час), что опять-таки приведет к потере оперативности.  Рис. 2. Распределение оповещений по 3-м проваленным подряд проверкам. Синим показаны проваленные проверки, красным — оповещения. Таким образом “классические” алгоритмы заставляют выбирать: либо флуд-поток алертов, либо потеря оперативности. Причем при ограниченных ресурсах флуд-поток зачастую приводит к не меньшей потере оперативности, чем при сложных настройках триггеров. Осталось посмотреть, что нам в такой ситуации могут предложить методы AI/ML. А что ML? Прежде чем пойдем дальше, сразу бы хотелось оговориться, что мы не являемся Data Scientist и перед нами не стояла задача выбора оптимального метода. Наша задача заключалась в том, чтобы, во-первых, найти любой метод, который соответствовал 3-м критериям:
В нашем случае таким методом стал DetectIidSpike из библиотеки ML.NET. Основная идея данного метода: проверить укладывается или нет каждое новое значение на временном ряде в существующую выборку. Если не укладывается, то обозначить такое значение как аномалию. Другими словами для каждого нового значения проверяется "нулевая" гипотеза и если она подтверждается, то детектируется аномалия. После чего новое значение переобучает модель. Отсюда очень важным для нормальной работы метода DetectIidSpike являются его два параметра:
Теперь посмотрим, как данный алгоритм работает на практике. В рассматриваемом примере у нас HTTP-проверки сайтов, т.е. на выходе имеем единицы и нули. Для нашего алгоритма это вот не совсем подходящий материал. Здесь желательно иметь дело все-таки не с бинарными значениями. Для этого мы применили агрегацию данных по временным интервалам, т.е. превратили нашу последовательность из нулей и единичек на интервале 5 мин в число: отношение проваленных проверок к общему количеству проверок в этом интервале. Здесь велико было искушение взять просто количество проваленных, но это в корне неправильно, т.к. соседние интервалы могут отличаться по количеству проверок. Это может происходить как по причине динамических настроек проверок (например, при проблеме чаще идут проверки), так и по банальной причине задержек в проверках и пограничных "конфликтах", когда проверки попадают в соседние интервалы. После этих подготовительных операций мы потоково направляем получаемые данные в наш прототип детектора аномалий в виде “заданий”. Стратегия запуска задания заключается в том, чтобы загрузить модель, рассчитанную в предыдущем раунде проверок, проверить является ли значение пиком (аномалией), провести «дообучение» модели полученным значением и сохранить измененную модель обратно на диск (или в память). Для этого наш планировщик раз в 5 мин формирует список заданий на вычисление в детекторе аномалий. Агенты, подключенные к планировщику по websockets протоколу, получают задания и выполняют их. На выходе мы имеем аномалии и оповещения, а сама система агентов очень легко масштабируется (у нас kubernetes реплики). На приведенной выборке при настройках алгоритма (confidence: 95, pvalueHistoryLength: 5), мы в итоге получили 36 аномалий. Следует учитывать, что аномалией считается также резкое снижение количества проваленных проверок, т.е. за аномалии принимается восстановление работоспособности. Отфильтровав сообщения о восстановлении, имеем итоговые 24 оповещения. (Кстати, метод в библиотеке имеет соответствующую настройку).  Рис. 3. Аномалии и проваленные проверки (confidence: 95, pvalueHistoryLength: 5) Синим показаны относительные значений проваленных проверок, красным — оповещения Как видно из графика (рис. 3), при недостаточном уровне обучения модель генерировала большое количество аномалий вначале, которое значительно сократилось на последующем интервале после достаточного обучения. А также, что имеет первостепенное значение, не были упущены практически никакие проблемы и полученный детектор аномалий достаточно оперативно реагировал на возникающие провалы (закрашенные области). Для сравнения на рис. 4 приведен результат работы модели со скользящим окном pvalueHistoryLength=12 и достоверностью confidence: 98. Здесь результат: 14 аномалий.  Рис. 4. Аномалии и проваленные проверки (confidence: 98, pvalueHistoryLength: 12) Краткий вывод Таким образом, применяя метод DetectIidSpike нам удалось снизить количество оповещений практически в два раза (24 против 44) по сравнению с проверкой на 3 подряд проваленные проверки, и в 7,5 раз (24 против 179) с однократным трешхолдом. При этом, самое главное, не теряя в качестве и оперативности. А это говорит нам о том, что методы ML могут нам действительно на практике помочь в задачах мониторинга. По крайней мере, приведенный метод точно :) P.S.: Если у вас есть идеи или конкретные методы ML, которые вы опробовали для решения проблемы флуд-алертинга, пишите в комментариях. Будет интересно попробовать. P.P.S.: Ниже приведу еще несколько скриншотов из нашего pet-проекта с реальными данными проведенных проверок и сгенерированных аномалий. Можете посмотреть насколько эффективно или неэффективно (for whom how) работает алгоритм (желтый кружок — аномалии на выбранном интервале). Несколько еще интересных скриншотовSPL   =========== Источник: habr.com =========== Похожие новости:
Системное администрирование ), #_itinfrastruktura ( IT-инфраструктура ), #_algoritmy ( Алгоритмы ), #_mashinnoe_obuchenie ( Машинное обучение ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 18:59
Часовой пояс: UTC + 5