Предыстория
Последние пару лет рынок систем мониторинга будоражила аббревиатура 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) работает алгоритм (желтый кружок — аномалии на выбранном интервале).
