Введение.
Собственно, речь в данной статье пойдет об Unit-мониторах (Unit Monitors), а если точнее, то о Windows Events мониторах.
Мне кажется Windows Event мониторы в SCOM 2007 R2 достаточно интересны и к тому же этот функционал мало где описан. SCOM 2007 R2 дает возможность создать 5 типов мониторов (Рисунок 1), плюс по некоторым типам есть разнообразные настройки, принцип функционирования которых не всегда очевиден.
Рисунок 1.
Во время изучения теории, я думал, что некоторые мониторы работают одним образом, на практике же оказалось несколько иначе. В данной статье хотелось бы на достаточно подробном и интуитивно-понятном уровне описать принцип работы мониторов этой категории.
Статья была написана для SCOM 2007 R2, но возможно будет актуальна и для SCOM 2012. В процессе написания статьи были выявлены некоторые странности в поведении SCOM, а возможно это ошибки, которые сохранились даже после установки накопительного обновления 4 (CU4).
Общие сведения о мониторах.
Для чего нужен монитор? Монитор настраивается на выполнение определенных проверок компонентов объекта управления, и затем эти проверки отражаются на состоянии монитора, а, в конечном счете, и на состоянии объекта управления. Например, монитор отслеживает появление какого-либо события в журнале событий Windows и, при появлении такого события, переходит в состояние Warning. В нормальное (Health) состояние монитор может быть переведен наступлением другого события, например, ручным сбросом состояния. По такому принципу работают Unit-мониторы. Есть еще Rollup-мониторы, но в этой статье они не обсуждаются.
Сразу опишу события, которые позволяют сбросить состояние монитора в Health. Таких событий три и они одинаковы для всех типов мониторов обсуждаемых в данной статье:
- Manual – ручной сброс состояния монитора;
- Timer Reset – сброс по прошествии заданного времени;
- Windows Event Reset – сброс при возникновении определенного события Windows.
То есть, если у нас монитор находится в состоянии Warning или Critical и возникает одно из перечисленных событий, то состояние монитора переводится в Health. Да, хотелось бы отметить, что Window Event Unit-мониторы, доступные для создания через Operations Console, имеют всего два состояния Success и Failure, но в пакете управления (management pack) Microsoft.Windows.Library доступны также мониторы с тремя состояниями (Health, Warning, Critical). Для того чтобы ими воспользоваться, вам придется использовать другие средства создания мониторов, например, Authoring Console.
В начале статьи можно было увидеть картинку с типами мониторов, которые доступны через Operations Console. Продублирую эту информацию:
- Simple Event Detection;
- Repeated Event Detection;
- Missing Event Detection;
- Correlated Event Detection;
- Correlated Missing Event Detection.
А теперь подробнее по каждому монитору.
Simple Event Detection.
Это простой монитор, который реагирует на указанное вами событие в журнале событий Windows (Windows Event Log). Вроде ничего сложного и криминального в работе этого монитора нет.
Рабочий поток (workflow) монитора выглядит примерно так:
Рисунок 2.
Модуль Microsoft.Windows.BaseEventProvider отслеживает события на определенном компьютере в определенном журнале (задается на шаге Event Log Name в визарде), далее данные типа
Microsoft.Windows.EventData передаются модулю
System.ExpressionFilter, конфигурацию которого вы задаете в мастере создания монитора на шаге Event Expression Unhealthy Event . Фильтр событий задается через типом
ExpressionType. Если System.ExpressionFilter получает данные, которые подходят под критерии фильтрации, то на выходе возвращается событие и состояние монитора изменяется на Failure.
Simple Event Monitor со сбросом по событию (Windows Event Reset) имеет дополнительный рабочий поток, такой же что и был изображен ранее, но настроен он на состояние Success.
Repeated Event Detection.
Этот монитор отслеживает повторение событий в заданном промежутке времени. Вроде бы ничего сложного, но некоторые настройки данного монитора могут быть непонятны.
У данного монитора есть три режима учета событий (Counting Mode): Trigger on timer, Trigger on count и Trigger on count, sliding.
Что делает
Trigger on timer? Он просто отслеживает появление указанных событий в определенный интервал времени и в конце этого интервала отражает состояние монитора.
Trigger on count. Монитор меняет свое состояние на Failure, если в определенном интервале времени было обнаружено заданное число событий.
Trigger on count, sliding. Поведение тоже самое, что и у Trigger on count, но при появлении очередного события интервал времени начинается заново.
Теперь рассмотрим интервалы времени (или отслеживания):
- Based on items occurence within a time interval. Этот интервал времени начинается свой отсчет при первом появлении события.
- Based on fixed weekly schedule. Указывается интервал времени на основе дней недели.
- Based on fixed simple recurring schedule. Указываются фиксированные, рекурсивные промежутки времени.
Теперь по каждой комбинации отдельно.
Trigger on timer и Based on items occurence within a time interval. Этот монитор отслеживает события (количество не важно), при этом отсчет времени начинается при первом появлении события. Состояние монитора отражается только по истечении интервала. На выходе мы получаем последнее событие, а также счетчик событий в этом интервале.
Например (рисунок 3), мы сконфигурировали интервал в 1 минуту на отслеживание события А. В 01:15 генерируется интересующее нас событие. В этот момент начинается отсчет интервала в 1 минуту. По истечении интервала (02:15) происходит изменение состояния монитора в Failure (Warning или Critical). В эту минуту могут генерироваться дополнительные интересующие нас события, тогда монитор будет увеличивать счетчик событий, но интервал увеличиваться не будет. Выводом монитора будут данные о последнем событии и число событий в интервале.
Рисунок 3.
Trigger on timer и Based on fixed weekly schedule. Этот монитор аналогичен Based on items occurence within a time interval, но интервал начинается не при первом появлении события, а в фиксированное время. В качестве времени может быть указан интервал в часах, в днях недели, а также и то и другое. Изменение состояния монитора происходит также в конце интервала, на выходе данные о последнем событии и число этих событий.
Что самое интересное, монитор данного вида изменяет свое состояние на Failure в конце интервала вне зависимости от того были ли желаемые события или нет. Это происходит, потому что модуль System.ConsolidatorCondition, с использованием фиксированных интервалов и отражающий состояние в конце этого интервала, всегда возвращает данные типа System.ConsolidatorData. Если события возникали, то счетчик событий будет больше 0, если нет то 0. Но чем это грозит? Да тем, что монитор изменит свое состояние на всех целевых объектах и состояние этих объектов также, скорее всего, изменится. Скажем если у вас 500 управляемых объектов Windows, и вы нацелили монитор на класс Windows Computer, то все 500 объектов поменяют свое состояние и, возможно, вся консоль будет засыпана Предупреждениями (Alert). Видимо Microsoft забыла вставить дополнительный модуль System.ExpressionFilter с фильтром Count > 0. Позже будет показано, как это нужно было сделать. Такое поведение было замечено на 2007 R2 без CU4 и с CU4.
Trigger on timer и Based on fixed simple recurring schedule. Тоже самое, что и Based on items occurence within a time interval, но интервал начинается фиксировано и циклически, а не при первом появлении заданного события. Есть возможность выровнять интервал по определенной границе. Например, мы настроили монитора на интервал в 1 минуту и выравнивание по 00:00 (рисунок 4).
Рисунок 4.
С этим монитором наблюдаются те же самые проблемы, что и с монитором Based on fixed weekly schedule. Монитор данного вида изменяет свое состояние на Failure в конце интервала вне зависимости от того были ли желаемые события или нет.
Trigger on count и Based on items occurence within a time interval. Это уже другой тип подсчета событий – количественный за определенный промежуток времени. Работает следующим образом. Первое событие начинает отсчет заданного интервала времени, и если в этом интервале времени происходит заданное количество событий, то состояние монитора переходит в Failure. Срабатывание монитора происходит сразу после обнаружения заданного числа событий. На выходе имеем последнее сгенерированное событие (например, третье, если счетчик срабатывания равен трем) и данные об этом последнем событии. Например (Рисунок 5), мы сконфигурировали интервал в 1 минуту и 3 срабатывания события А. В 01:15 сработало первое событие А, начался интервал в 1 минуту, в этом интервале сгенерировалось всего два события, состояние монитора сохранилось на Success. В 02:40 появилось новое событие, которое не принадлежит предыдущему интервалу, поэтому начался новый интервал в 1 минуту. В этом интервале сработало 4 события, но монитор изменил свое состояние уже после третьего события, четвертое событие не учитывается.
Рисунок 5.
Trigger on count и Based on fixed weekly schedule. Также считает количество событий, но в определенном заданном фиксированном интервале времени. Как и с Trigger on timer можно указать дни недели и промежутки времени. Но в отличие от Trigger on timer переводит свое состояние в Failure сразу после фиксирования заданного числа событий, а не в конце интервала. То есть принцип срабатывания такой же что и с Trigger on count и Based on items occurence within a time interval.
Trigger on count и Based on fixed simple recurring schedule. Срабатывание аналогично Trigger on count Based on items occurence within a time interval, но интервал времени не начинается с появлением первого события. Это фиксированные рекурсивные интервалы времени. Их можно также выровнять по определенной временной границе.
Trigger on count, sliding. Для этого монитора есть только один возможный параметр интервала -
Based on items occurence within a time interval. Это и верно, поскольку он использует динамические интервалы, то другие два типа фиксированных интервалов абсолютно бессмысленны. Работает он достаточно просто. Берется последнее событие и от него отсчитывается заданный интервал. Если в этот интервал попадает определенное количество событий, то монитор переходит в состояние Failure. На выходе мы получаем данные последнего события в интервале и количество событий во всем интервале.
Например (рисунок 6), мы сконфигурировали монитор, интервал 1 минута, повторяющихся событий А – 3. При возникновении последнего события отсчитывается минутный интервал и высчитывается количество событий. В нашем случае три. Состояние монитора изменяется на Failure.
Рисунок 6.
Реализация.
Примерная реализация Repeated Event мониторов следующая:
Рисунок 7.
Первая часть аналогична Simple Event Detection, но далее, после модуля System.ExpressionFilter, данные передаются модулю
System.ConsolidatorCondition, который производит консолидацию событий. Конфигурация System.ConsolidatorCondition передается через свойство Consolidator типа
ConsolidatorType. На выходе получаем данные типа
System.ConsolidatorData. Стоит заметить, что System.ConsolidatorCondition может работать с данными любого типа (на входе принимает данные типа System.BaseData). Консолидация может происходить просто по данным на входе (после фильтрации модулем System.ExpressionFilter), либо по дополнительной фильтрации в самом модуле System.ConsolidatorCondition. Например, дополнительную фильтрацию для Repeated Event Detection мониторов можно задать кнопкой Edit на странице Repeated Event Configuration (Рисунок 8).
Рисунок 8.
Missing Event Detection.
Этот тип мониторов достаточно простой. Он изменяет свое состояние на Critical, если в заданный интервал времени не было ни одного указанного события.
Монитор можно настроить на два типа фиксированных интервалов: Based on fixed weekly schedule и Based on fixed simple recurring schedule. Предназначение интервалов аналогично интервалам монитора Repeated Event Detection.
Реализация.
Принцип реализации (Рисунок 9):
Рисунок 9.
Модуль Microsoft.Windows.BaseEventProvider отслеживает события в указанном журнале, далее данные типа
Microsoft.Windows.EventData передаются модулю
System.ExpressionFilter . После модуля Systep.ExpressionFilter, данные передаются в композитный монитор System.MissingConsolidatorCondition, который состоит из нативных (native) модулей System.Consolidator и System.ExpressionFilter. Поскольку данный тип мониторов работает только с фиксированными интервалами отслеживания, то в конце указанного интервала всегда генерируются данные типа
System.ConsolidatorData. Если событие происходило, то Count будет больше нуля, если не было – Count равен нулю. Нас как раз интересует отсутствие событий в этом интервале, поэтому для System.ExpressionFilter настроен фильтр «Count Equal 0». Получается, что в конце интервала System.ConsolidatorCondition отдает данные типа System.ConsolidatorData модулю System.Expression, тот, если событий не происходило (Count = 0), отдает данные дальше на выход и происходит изменение состояние монитора на Failure, или же блокирует данные, тогда изменение состояния монитора не происходит.
Помните ошибку в работе монитора Repeated Event Detection? Как раз Microsoft видимо забыл вставить модуль System.ExpressionFilter с фильтром Count > 0.
Correlated Event Detection.
Это, наверное, один из самых непонятных типов мониторов. Correlated Mission Event Detection тоже непонятный, но он основан на Correlated-мониторе, поэтому если рассмотрим его, поймем и Mission.
В чем смысл корреляции в данном случае? Найти связь между двумя типами событий, соотнести эти события по заданным признакам в определенный интервал времени. К примеру, у нас есть приложение, которое почувствовав себя плохо, сначала генерирует событие уровня Warning, а далее известно, что если приложению уж совсем поплохело, то должно генерироваться какое-то количество дополнительных событий уровня Error. Нам необходимо отслеживать такое поведение. В этом нам как раз таки и поможет монитор Correlated Event Detection.
А теперь о различных конфигурациях мониторов данного типа. Существует пять типов корреляции. Первый.
The First Occurrence of A with the configured occurrence of B in chronological order. Работает он следующим образом. При возникновении первого события A начинается отсчет времени. Если в этот промежуток времени срабатывает заданное количество событий B, то события считаются связанными и происходит изменение состояния монитора (с небольшой задержкой). При этом интервал времени не продляется и не начинается заново, если в заданный промежуток времени попадают дополнительные события А.
На выходе получаем результат из двух событий в структуре типа
System.CorrelatorData: первое событие А (Item0Context), Item0Count (всегда равно 1), последнее событие B (Item1Context) и количество событий B.
Например (Рисунок 10), нам нужно после события А отслеживать три события B в двухминутном интервале. В 00:25 возникает событие А, начинается двухминутный интервал, в этот интервал попадают четыре события B. Происходит связывание первого события А и третьего события B. Четвертое событие B не учитывается и в результирующие данные не попадает. Отражение состояния монитора происходит после обнаружения сконфигурированного числа (три в нашем случае) событий B, но с небольшой задержкой, 60 секунд.
Рисунок 10.
The First Occurrence of A with the configured occurrence of B, or vise versa. При появлении первого события А (или B) начинается новый интервал корреляции. Если в этот интервал попадает заданное количество событий типа B (или А), то сообщения считаются связанными и монитор меняет свое состояние. Тут главное понять, что именно с первого события начинается интервал корреляции. Сообщение, инициировавшее интервал корреляции, считается основным, в этом случае противоположное событие должно появиться в интервале сконфигурированное количество раз. Новый интервал не может начаться, пока не истечет текущий.
На выходе: событие инициировавшее интервал и последнее противоположное событие.
Рассмотрим предыдущий пример. Событие B начинает интервал, в интервал должно попасть три события А, чтобы сообщения считались связанными. Этого не происходит, поэтому состояние монитора не изменяется.
Рисунок 11.
А вот если бы первого события B не было, то событие А считалось бы инициировавшим интервал корреляции и мы бы получили срабатывание монитора (Рисунок 12).
Рисунок 12.
The Last Occurrence of A with the configured occurrence of B in chronological order. На первый взгляд может показаться, что здесь все очевидно: последнее событие А начинает новый интервал и ждет появление событий B. На самом деле поведение совсем другое. Поведение аналогично «The First Occurrence of A with the configured occurrence of B in chronological order», но происходит связывание последнего события А с последним событием B.
То есть, первое событие А начинает интервал, далее в этом интервале начинается отсчет событий B. Если обнаруживается заданное количество событий B, то происходит корреляция последнего события А с последним событием B, далее изменение состояния монитора.
Проиллюстрирую на схеме (Рисунок 13). Условия те же: три события B, двухминутный интервал.
Рисунок 13.
На выходе последнее событие A и третье событие B.
The Last Occurrence of A with the configured occurrence of B, or vise versa. Поведение этого монитора аналогично «The First Occurrence of A with the configured occurrence of B, or vise versa», за тем исключением, что происходит соотнесение последнего события А и последнего события B. Соотнесение событий аналогично «The Last Occurrence of A with the configured occurrence of B in chronological order».
The First Occurrence of A with the configured occurrence of B happens, enable interval restart. Тут все достаточно просто. Каждое событие А начинает новый интервал. Если в этот интервал попадает заданное количество событий B, то происходит связывание последнего А с последним B. Если в уже начавшемся интервале появляется событие А, то интервал сбрасывается и начинается новый отсчет событий B.
Рисунок 14.
Реализация.
Принцип реализации (Рисунок 15):
Здесь есть два модуля Microsoft.Windows.BaseEventProvider, один для события А, другой для B. Есть два фильтра System.ExpressionFilter, также для события А и B. Далее отфильтрованные события попадают в композитный модуль
System.CorrelatorAutoCondition, который и проделывает все работы по корреляции событий (инициация интервала, подсчет событий) и возвращению данных типа
System.CorrelatorData, наличие которых вызывает изменение состояния монитора на Failure. Модуль System.CorrelatorAutoCondition состоит из нативных модулей
System.Correlator и System.ExpressionFilter. Модуль System.Correlator всегда возвращает данные по закрытию интервала, поэтому здесь модуль System.ExpressionFilter введен специально, чтобы отфильтровывать некорректные данные (пустые или если число событий в промежутке меньше, чем задано). На уровне модуля System.Correlator (также как и с System.Consolidator) можно задать дополнительный фильтр для корреляции событий (в Operations Console это кнопка Configure advanced options).
Mission Correlated Event Detection.
Этот тип мониторов полная противоположность Correlated Event Detection. Где этот монитор можно задействовать? Например, у вас есть приложение, которое, обнаружив собственную нестабильную работу, генерирует некоторое событие. Далее у вас есть приложение (это можно также реализовать с помощью Правил (Rules)), которое реагирует на это событие и запускает ряд тестов или процедур восстановление, в процессе работы которых генерируются события об исправлении ошибок. Вам важно знать, что в определенный промежуток времени после генерации ошибки успешно отработали корректирующие процедуры. Если это не так, то вы бы хотели получить Alert.
Многие настройки монитора этого типа аналогичны настройкам Correlated Event Detection.
The First Occurrence of A with the configured occurrence of B in chronological order. Первое событие А начинает интервал. Если в этом интервале происходит заданное число событий B, то монитор сохраняет свое состояние. Если в этом интервале вообще не генерируются события B или этих событий меньше, чем мы указали, то монитор меняет состояние на Failure. Статус всегда определяется в конце интервала. В случае смены состояния на Failure, на выходе мы имеем первое событие А и последнее событие B.
The First Occurrence of A with the configured occurrence of B, or vise versa. Тоже самое, что и предыдущий тип, но интервал может инициироваться первым событием А или первым событием B. Далее идет отсчет количества событий B, если интервал начался с сообщения A, или отсчет количества событий A, если интервал начался с B. Если событий, противоположных инициировавшему интервал, нет или меньше заданного количества, то происходит изменение монитора на Failure. Определение состояния монитора происходит в конце интервала.
В случае смены состояния на Failure, на выходе мы имеем первое событие А (или B) и последнее событие B (или A).
The Last Occurrence of A with the configured occurrence of B in chronological order. Тоже самое что и «The First Occurrence of A with the configured occurrence of B in chronological order», но коррелируются последнее в интервале событие А и последнее событие B. Это происходит в конце интервала, в случае если монитор перешел в состояние Failure.
The Last Occurrence of A with the configured occurrence of B, or vise versa. Тоже самое что и «The First Occurrence of A with the configured occurrence of B, or vise versa», но коррелируются последнее в интервале событие А (или B) и последнее событие B (или А). Это происходит в конце интервала, в случае если монитор перешел в состояние Failure.
The First Occurrence of A with the configured occurrence of B happens, enable interval restart. Поведение этого монитора аналогично одноименному из Correlated Event Detection. Каждое событие А начинает новый интервал, если в новый интервал попадает нужное количество событий B, то состояние монитора не меняется. Состояние монитора определяется в конце интервала. Если событий B не было вообще или было, но меньше, чем сконфигурировано, то состояние монитора изменяется на Failure.
В случае срабатывания монитора, на выходе имеем последнее событие А и последнее событие B.
Реализация.
Рисунок 16.
Монитор реализован следующим образом. Есть два модуля Microsoft.Windows.BaseEventProvider, один для события А, другой для B. Есть два фильтра System.ExpressionFilter, также для события А и B. Далее отфильтрованные события попадают в композитный модуль
System.CorrelatorAutoMissingCondition, который и проделывает все работы по корреляции событий (инициация интервала, подсчет событий) и возвращению данных типа
System.CorrelatorData, наличие которых на выходе вызывает изменение состояния монитора на Failure. Модуль System.CorrelatorAutoMissingCondition состоит из нативных модулей
System.Correlator и System.ExpressionFilter. Модуль System.Correlator всегда возвращает данные по завершению интервала, поэтому здесь модуль System.ExpressionFilter введен специально, чтобы отфильтровывать некорректные данные. То есть, на выходе появляются данные только в том случае, если в конце интервала событий не было или было, но меньше сконфигурированного числа. На уровне модуля System.Correlator можно задать дополнительный фильтр для корреляции событий (в Operations Console это кнопка Configure advanced options).
Заключение.
На самом деле перечисленные в этой статье типы мониторов далеко не все. В предустановленных пакетах управления (management packs) можно найти еще много интересных шаблонов мониторов (monitor types) и шаблонов модулей (module types), которые расширяют функционал работы с событиями. Но создавать мониторы на основе этих шаблонов придется не из Operations Console, а используя другие утилиты, например, Authoring Console.
Используемая литература:
Event Monitors -
http://technet.microsoft.com/en-us/library/ff629447
Operations Manager Management Pack Development Kit -
http://msdn.microsoft.com/en-us/library/ee533840
