ИИ в мониторинге инфраструктуры: как предсказать сбои заранее

Чем раньше обнаружить вероятность возникновения сбоя в ИТ-инфраструктуре, тем больше шансов его не допустить. Решить эту задачу наиболее эффективно позволяют инструменты предиктивной аналитики в системе зонтичного мониторинга Naumen BSM. Специальные ML-модели позволяют определить вероятность возникновения сбоев на ранних стадиях. Рассказываем, как это работает.

Как с помощью ML-модели получить прогноз по событиям

Один из аналитических инструментов на базе ИИ, который используется в системе Naumen BSM, — это модель прогнозирования. Она анализирует значения метрик оборудования и определяет, как они будут меняться. Если сценарий неблагоприятный, то заранее предупреждает о возможной аварии. Рассмотрим, как обучить ИИ на данных конкретной метрики и учитывать прогнозы на уровне оборудования и сервисов.

Здоровье конфигурационной единицы (КЕ) зависит от одной или нескольких ключевых метрик. Значения метрик постоянно поступают в систему зонтичного мониторинга. Однако, чтобы заметить критичное изменение метрики, нужно неотрывно следить за графиком либо настроить триггер, указав пороговое значение. Тогда важное изменение метрики получится заметить по возникшему событию (алерту).

Чтобы заранее узнавать о вероятных сбоях, нужно подключить ML-модель, которая прогнозирует значения метрик.

Как подключить к метрике модель прогнозирования:

1. Добавить модель к выбранной метрике.
2. Задать горизонт прогнозирования.
3. Обучить модель на исторических данных.

Горизонт прогнозирования — это период, например, ближайшие несколько часов или дней, на который рассчитывается прогноз. Желаемый горизонт определяет пользователь.

Остальные параметры и коэффициенты, необходимые для выстраивания прогноза, ИИ рассчитывает автоматически: частота дискретизации, объем истории, сезонность и другие. При этом учитываются свойства метрики, доступный объем истории и заданный горизонт. Обучение занимает несколько минут. Затем модель станет активна и будет периодически строить прогноз на нужный период.

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

Рассмотрим на примере. На здоровье сервера влияет метрика «Память на диске». ИТ-службе необходимо понимать, как будут меняться значения этой характеристики в течение ближайших 4 часов. Такой период выбран потому, что при риске возникновения сбоя специалисты успеют принять предупреждающие меры. Отсюда задается нужный горизонт прогнозирования, модель обучается и выдает график, на котором будет отображаться четырехчасовой прогноз по метрике «Память на диске». График будет перестраиваться в соответствии с частотой расчета, при этом более ранние прогнозы здесь не отображаются, но сохраняются в истории расчетов.

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

Как с помощью ML-модели выявить аномалии в работе ИТ-систем и оборудования

В Naumen BSM предусмотрены такие инструменты интеллектуальной аналитики, как модели детектирования аномалий. Они предназначены для обнаружения отклонений в значениях метрик. Эту информацию можно использовать для выявления возможных аварий на ранних стадиях, особенно если для данной метрики не настроен триггер с пороговым значением.

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

ML-модель детектирования аномалий не требует устанавливать границы типичных значений. Она обучается на исторических данных и затем автоматически определяет, какие значения считать аномальными для метрики, учитывая заданный период обучения. Качество анализа зависит от свойств метрики и доступных данных.

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

Как подключить модель детектирования аномалий к метрике:

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

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

Итог обучения — график с историческими данными, на котором красным выделены точки с нетипичными значениями. Пунктирная линия показывает момент обучения модели.

Например, ИТ-службе необходимо определить границы типичных значений для метрики «Загрузка ЦПУ» сервера. Инженер обучил две ML-модели, получил и сравнил графики. Модель Isolation Forest на одном из участков выделила больше аномальных точек, чем другая, основанная на алгоритме Moving Z-Score. Значит, Isolation Forest лучше подходит для выявления отклонений по этой конкретной метрике.

В дальнейшем этот алгоритм будет анализировать значения метрики с периодичностью, заданной пользователем. Можно настроить, чтобы система автоматически отслеживала частоту отклонений, тогда при ее повышении (если за короткое время возникает много аномалий) ИТ-служба получит предупреждение о риске сбоя.

Таким образом, с помощью интеллектуальной аналитики получится организовать контроль за частотой возникновения аномалий в метриках. Это позволит заблаговременно узнавать о риске возникновения сбоя и вовремя реагировать на подобные ситуации. Также ML-модели на уровне зонтичного мониторинга могут заменить настройку порогов для метрик или повысить точность определения порогов для тех метрик, пороги которых меняются со временем и требуют периодического пересмотра.

Как использовать результаты ML-моделей

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

Различные компоненты ИТ-инфраструктуры связаны между собой. Поэтому здоровье оборудования рассчитывается на основе данных мониторинга самого устройства, а также связанных с ним компонентов. А при расчете здоровья сервиса или услуги учитывается состояние всех связанных элементов.

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

Допустим, одна ML-модель обнаружила аномалии по метрике «Загрузка ЦПУ», другая сформировала прогноз отклонения. На основе этих данных были сформированы события, которые повлияли на оценку здоровья сервера.

В ИТ-системе настраивается, как именно будет меняться здоровье КЕ под влиянием данных предиктивной аналитики. Например, чтобы при неблагоприятном прогнозе или обнаружении аномалий отображался статус здоровья «Предупреждение».

Также настраивается, какие прогнозы и аномалии следует учитывать, а какие игнорировать. У триггера, связанного с прогнозом метрики, можно задать уровень критичности. Тогда при прогнозе существенного роста или падения значений метрики можно будет создавать инцидент, а если изменения ожидаются менее значительные, просто генерировать событие для статистики, не изменяя статус здоровья КЕ.

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

В связке с системой Naumen Service Desk можно задать несколько сценариев для событий с различным уровнем критичности и срочности. Например, для одних нужно регистрировать запрос на обслуживание, для других — инцидент. Также определяется, в каких случаях отправлять уведомление о вероятном сбое ответственному специалисту.

При прогнозе недопустимых значений метрик или продолжительных аномалий стоит формировать инцидент, связанный как с КЕ, так и с услугой или сервисом, соответственно меняя его здоровье. Это позволяет ИТ-службам оценивать критичность сервиса, который рискует пострадать из-за сбоя КЕ, и своевременно принять предупреждающие меры.

К выводам

ML-модели в Naumen BSM прогнозируют сбои и детектируют аномалии в ИТ-инфраструктуре. На основе данных предиктивной аналитики создаются события, которые обрабатываются в соответствии с правилами, заложенными в системе.

Прогнозы могут влиять на статус здоровья конфигурационной единицы (компонента инфраструктуры) и связанных сервисов, а также на создание запросов и инцидентов в системе класса Service Desk. Таким образом, благодаря предиктивной аналитике ИТ-служба будет заранее получать предупреждения о вероятных сбоях.