ГлавнаяРешенияИнтеграция с системами мониторинга

Интеграция с системами мониторинга

Для многих средних и крупных компаний наличие систем мониторинга обычное явление. В рамках проектов по внедрению ITSM процессов зачастую решаются задачи по интеграции OMNITRACKER и систем мониторинга.

 

РЕШАЕМЫЕ ЗАДАЧИ

  • Сокращение времени на анализ состояния наблюдаемого оборудования на основании данных от систем мониторинга.
  • Сокращение времени устранения инцидентов за счёт их раннего автоматизированного обнаружения системами мониторинга.

 

ПРЕИМУЩЕСТВА

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

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

 

СХЕМА ИНТЕГРАЦИИ OMNITRACKER С СИСТЕМАМИ МОНИТОРИНГА

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

 

 

 Перечень обрабатываемых состояний КЕ приведён в следующей таблице.

 

Состояние КЕ

Описание

Действия

Работает (UP)

КЕ находится в исправном рабочем состоянии. Переводит открытое событие DOWN и BAD в статус "Закрыто"
Не работает (DOWN) Неработоспособность  конфигурационных единиц или их элементов (например, интерфейсов Firewall), участвующих в предоставлении услуг. Порождает инцидент соответствующего приоритета
Плохо работает (Warning/Bad) Нарушены пороговые значения важных показателей. Нужна неотложная реакция. Порождает инцидент соответствующего приоритета

 

СПОСОБЫ ИНТЕГРАЦИИ OMNITRACKER

В качестве систем мониторинга наиболее часто выступают: Microsoft SCOM, семейство продуктов Solarwinds, GFI, IBM Tivoli Netcool, Cisco LMS

Интеграция OMNITRACKER с системами мониторинга может быть выполнена различными способами:

  • по электронной почте – система мониторинга отправляет письмо с формализованными темой и текстом, содержащее идентификатор объекта мониторинга и описание события;
  • с помощью специализированных коннекторов, например  SCOM Universal Connector;
  • с использованием веб-сервисов – система мониторинга вызывает веб-сервис OMNITRACKER и передает идентификатор объекта мониторинга и описание события;
  • с использованием механизмов импорта данных из файлов или таблиц СУБД – OMNITRACKER по расписанию импортирует данные из системы мониторинга.

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

Ниже приведен простой пример письма от системы мониторинга в OMNITRACKER

 

EventID:SRV-01-34545676
SourceSystem:IBM
CIName:SRV-01
CIIPAddress:11.140.172.132
CIState:UP
ShortName:Server Down
Description:Server interface Lan:0 10.100.172.172 Down

Где:

EventID – уникальный номер сообщения в системе мониторинга
SourceSystem – система-источник
CIName – hostname источника (конфигурационной единицы) сообщения
CIIPAddress - hostname источника (конфигурационной единицы) сообщения
CIState – передаваемое состояние. Возможные значения – UP, DOWN, BAD
ShortName – краткое описание сообщения
Description – полное описание сообщения

 

Письмо разбирается штатными средствами OMNITRACKER и бизнес-логика обрабатывает его в зависимости от состава письма.

Если система мониторинга может поставлять данные с помощью API или веб –сервиса, то задача решается с помощью запуска сервером OMNITRACKER VBS скриптов, внешних команд с конфигурируемыми параметрами командной строки или COM/DCOM объектов. Такой подход позволяет инициировать практически любое взаимодействие с внешними системами.

 

ОСОБЕННОСТИ / РИСКИ / ОГРАНИЧЕНИЯ

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

Система мониторинга должна быть настроена так, чтобы отправлять только значимые сообщения, т.е. сообщения, требующие внимания ИТ-специалистов. Цикл опроса объекта мониторинга, время ожидания отклика (∆t.Мониторинг) и количество запросов должно быть установлено таким образом, чтобы исключить "дребезг" — поток ложных или краткосрочных срабатываний, связанный с чрезмерно детальными настройками системы мониторинга. Корректность настроек обеспечивается администратором системы мониторинга и в общем случае выставляется для каждого объекта индивидуально.

 

 

 

∆t.ot является величиной постоянной, указывается явно в атрибуте "Время ожидания по событию" для каждого КЕ в CMDB.

По событию DOWN/BAD в OMNITRACKER регистрируется инцидент спустя заданный интервал времени (на рисунке — ∆t.ot, панель "ОТ.События"). Время ∆t.ot задаётся достаточным для того, чтобы система мониторинга опросила КЕ, которые могут являться причинами события DOWN, произошедшего на данной КЕ.

 

ПРИМЕРЫ РЕАЛИЗАЦИИ ИНТЕГРАЦИИ ITSM СИСТЕМЫ

Типовой процесс работы интеграции с системой мониторинга можно разложить на 4 этапа

1. Отправить сообщение в OT

 

 

Система мониторинга передаёт информацию о состоянии КЕ в систему OMNITRACKER. Сообщение, пришедшее от системы мониторинга, регистрируется в статусе "Открыто" в виде объекта "Событие".

 

2. Зарегистрировать событие

Omnitracker регистрирует полученное от системы мониторинга событие в статусе "Открыто".

Фиксируется определенный набор атрибутов события в системе (Источник, КЕ, статус, идентификатор, и т.д.). Omnitracker привязывает КЕ к зарегистрированному событию. Если КЕ не найдено, Менеджеру процесса управления конфигурациями автоматически направляется запрос на обслуживание (ЗНО) категории "Актуализация CMDB".

 

3. Обработка события

В случае получения события DOWN или BAD система OMNITRACKER ожидает период равный ∆t.ot. Если в этот период времени от системы мониторинга не получено событие UP, в OMNITRACKER регистрируется инцидент.

 

4. Закрытие события

Событие DOWN и BAD в OMNITRACKER закрывается по сообщению UP от системы мониторинга.

При закрытии фиксируется:

  • статус события "Закрыто";
  • время закрытия;
  • если событие связано с инцидентом, то выполняется процедура закрытия инцидента (если все события по инциденту закрыты, инцидент переводится в статус "Устранён").