Звоните: +7 (495) 517-57-25

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

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

Решаемые задачи

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

Преимущества

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

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

Схема интеграции OMNITRACKER с системами мониторинга

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

 integration monitorimg systems pic1

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

 

Состояние КЕ

Описание

Действия

Работает (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 и бизнес-логика обрабатывает его в зависимости от состава письма.

integration monitorimg systems pic2

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

 Особенности / Риски / Ограничения

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

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

 integration monitorimg systems pic3

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

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

Примеры реализации интеграции ITSM системы

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

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

integration monitorimg systems pic4

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

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

integration monitorimg systems pic4

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

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

 

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

integration monitorimg systems pic4

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

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

integration monitorimg systems pic4

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

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

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