Naumen Business Service Monitoring
Комплексное решение для цифрового мониторинга
и управления ИТ-ландшафтом предприятия


Как правила корреляции событий в мониторинге инфраструктуры помогают выявлять инциденты

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

Что дают правила корреляции событий

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

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

Вручную оценивать уведомления сложно, так как:


  • событий очень много, и это массивы данных. Анализ уведомлений занимает много времени;
  • на уровне решений инфраструктурного мониторинга отсутствует единая система типизации. Каждая из них по-своему определяет статусы событий.

Системы зонтичного мониторинга, например, Naumen BSM, позволяют структурировать данные и настраивать механизмы реагирования для событий разных типов. Зонтичное решение консолидирует информацию из внешних источников — систем инфраструктурного мониторинга, а затем запускает обработку событий с помощью правил типизации и корреляции.

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

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


  • локализовать сбой;
  • оценить степень влияния инцидента на инфраструктуру и услуги;
  • назначить срок решения в зависимости от критичности аварии.

Также в Naumen BSM предусмотрен механизм, благодаря которому количество зарегистрированных инцидентов по однотипным событиям сокращается.

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

Стандартизация событий

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

Унификация по типу события. В Naumen BSM по умолчанию используются типы событий «Восстановление», «Информация», «Отклонение» и «Предупреждение». На входе в зонтичный мониторинг поступают события со статусами «Error», «Restore», «Info» и десятками других. В правилах указывается, какие статусы соответствуют типам событий, и система автоматически проверяет и категоризирует события. Например, все события со статусом «Error» и «Warning» определяет как «Отклонение».

Унификация по ситуации. В корреляцию события заложено, какие параметры соответствуют конкретным ситуациям. Например, по значениям «Restore» в описании события и по идентификатору объекта, который соответствует конкретному коммутатору, выявляется ситуация «Восстановление работы коммутатора».

Определение критичности событий и регистрация инцидентов

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

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

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

Сопоставление объекта автоматической инвентаризации с конфигурационной единицей в CMDB

Принцип сопоставления между объектом автоматической инвентаризации и конфигурационной единицей

Правила корреляции позволяют определить соответствие между физическим устройством и виртуальным представлением в системе зонтичного мониторинга. Для этого используется:


  • идентификатор ОАИ, объекта автоматической инвентаризации — уникальный номер, по которому системы инфраструктурного мониторинга учитывают конкретное физическое устройство;
  • конфигурационная единица, КЕ — обозначение ИТ-ресурса в базе данных управления конфигурациями, CMDB.

А для оценки влияния сбоя на инфраструктуру применяются ресурсно-сервисные модели, РСМ — схемы, на которых отображаются взаимозависимости оборудования и услуг.

Оценив все параметры события и определив влияние аварии на сервисы и услуги, система принимает решение о создании инцидента. При регистрации запроса может автоматически назначаться срок решения в соответствии с SLA.

Обработка однотипных аварийных событий

Генерация аварийных событий в системе инфраструктурного мониторинга не прекращается после регистрации инцидента. Соответственно, и в зонтичный мониторинг сообщения об одном и том же сбое будут поступать до тех пор, пока не восстановится работа оборудования. А количество таких «поступлений» зависит от периодичности сбора данных планировщиками задач мониторинга.

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

Регистрация инцидента по первому событию и связь последующих событий с этим инцидентом.

Регистрация инцидента по первому событию и установление последующих событий как потенциально связанных с инцидентом

Для снижения количества дублирующих инцидентов можно использовать правила корреляции. Когда в систему поступают одинаковые события — с одного и того же устройства и с такими же параметрами, то инцидент создается только по первому из них. Последующие события получают статус «Отложено» и «связываются» с инцидентом.

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

Таким образом, правило не только сокращает количество одинаковых инцидентов, но и упрощает процесс завершения работ.

Правила на практике

Рассмотрим, как работают правила типизации и корреляции в Naumen BSM при возникновении аварийного события на конкретном примере.

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

  1. Аварийному событию по коммутатору присваивается тип «Отклонение» и ситуация «Коммутатор недоступен». Тип и ситуация событий, поступивших с других устройств, зависит от параметров. Например, аварийные сообщения с сервера классифицированы как «Отклонение», «Сервер недоступен».

    Унификация событий по типам с помощью правил корреляции в зонтичном мониторинге

    Правила типизации позволяют унифицировать события по типам и ситуациям в соответствии с определяющими параметрами

  2. По идентификатору ОАИ выясняется связь пострадавшего коммутатора с конкретной конфигурационной единицей.
  3. С помощью РСМ устанавливается, что КЕ поддерживает критически важную для бизнеса услугу «Эксплуатация сети».
  4. Автоматически регистрируется инцидент, в соответствии с SLA определяется срок восстановления услуги — 2 часа.

    Регистрация инцидента и корреляция связанных событий в зонтичном мониторинге.

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

  5. В зонтичный мониторинг каждые 10 минут поступают аварийные события из внешних источников. В правиле корреляции указано, что инцидент нужно регистрировать по первому событию, поступившему за 2 часа. Однотипные события, поступившие за этот период, «связываются» с уже зарегистрированным инцидентом.

    Потенциально связанные события в карточке инцидента зонтичного мониторинга.

    В карточке инцидента содержится список потенциально связанных событий

  6. Коммутатор починили через час после фиксации аварии. За это время система зарегистрировала 1 инцидент и 5 связанных событий по этому устройству. И столько же инцидентов и событий по другому оборудованию, которое отключилось в результате сбоя.
  7. При изменении статуса инцидента на «Закрыто» связанные события завершились автоматически.

Изменение статуса для завершения связанных событий через корреляцию в зонтичном мониторинге Naumen BSM.

Для завершения событий нужно закрыть инцидент, с которым они связаны

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

Что еще интересного

ИИ в мониторинге: как использовать
#технологии

Рассматриваем инструменты предиктивного анализа, которые помогают заранее выявлять вероятные аварии в ИТ-ландшафте

Планировщики задач мониторинга
#фичи

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

Когда нужен зонтичный мониторинг
#лучшие_практики

Сформулировали 5 признаков, которые подскажут, что компании пора внедрять зонтичное решение