Как создать свой кастомный зависимый монитор (Часть 2)
В первой части мы рассмотрели возможность создания кастомного зависимого монитора на основе скрипта, который позволял гибко вычислять состояние распределенного приложения. Во второй части мы рассмотрим другой интересный метод создания зависимого монитора, который использует встроенные возможности Operations Manager.
Как было упомянуто в первой части, кастомный Rollup механизм используется в тех случаях, когда не хватает возможностей стандартного механизма. Например, у вас есть отказоустойчивый сервис, компоненты которого есть как в основном датацентре, так и в резервном датацентре. Предположим, вы создали распределенное приложение в Operations Manager, которое отображает работоспособность сервиса в обоих датацентрах в зависимости от статуса его компонент. При использовании стандартного монитора, ваше распределенное приложение переходит в статус Critical при выходе из строя компонент в одном из датацентров. В этом случае было бы логично, чтобы ваше приложение переходило в статус Warning при неисправности компоненты в резервном датацентре.
Данный метод использует возможности монитора запускать восстанавливающие задачи (Recovery Tasks) при смене состояния монитора, а также используется специальный Write action модуль для изменения состояния мониторов. Этот модуль не наше изобретение. Он используется в мониторах ComputernotReachable и HealthServiceHeartbeatFailure. Если открыть свойство этих мониторов, то можно увидеть, что у них много различных recovery tasks. Часть из этих задач используют этот модуль. Алгоритм следующий: при переходе монитора HealthServiceHeartbeatFailure в состояние Critical срабатывает диагностический таск, который проверяет доступность сервера по ICMP. Если сервер не доступен, то запускается Recovery task, который меняет состояние монитора ComputernotReachable на состояние Critical.
К сожалению, нет возможности использовать данный модуль для создания задач прямо из консоли Operations Manager, поэтому придется редактировать непосредственно в XML.
Ниже список шагов, которые необходимо выполнить для настройки Recovery task:
1. Установить пакет управления с библиотекой
2. Создать распределенное приложение или взять уже существующее
3. Открыть Health Explorer распределенного приложения или его компонентов
4. Выбрать зависимый монитор, состояние которого необходимо изменять
5. Создать Recovery task для этого монитора по шаблону RunCommand
6. Экспортировать пакет управления, который содержит ранее сделанный Recovery task
7. Добавить ссылку на библиотеку, если ранее она не добавлялась
8. Изменить Write Action модуль и сохранить изменения
9. Импортировать измененный пакет в Operations Manager
Далее, на примере одного распределенного приложения, мы продемонстрируем как настроить такую задачу.
В этом примере мы будем использовать готовое распределённое приложение «Service». Оно состоит из нескольких компонент и одна из этих компонент называется "DB". Наша задача состоит в том, чтобы компонента "DB" всегда находилась в статусе Warning в тех случаях, когда ее объекты находятся в состоянии Critical или Warning. Следовательно, статус компоненты "DB" может быть либо Warning, либо Healthy и никогда - Critical:
 |
Для создания Recovery task необходимо выполнить следующие действия:
1. Открыть Health Explorer компоненты "DB"
2. Выбрать монитор, состояние которого необходимо изменять. Можно создать свой зависимый монитор, а можно использовать существующий. В данном примере будет создан Recovery task только для зависимого монитора, который находится под агрегирующим монитором «Availability»:
|
3. Открыть свойство зависимого монитора, перейти на вкладку DiagnosticandRecovery, нажать Add в области Configurerecoverytasks и в открывшемся меню выбрать Recoveryforcriticalstate:
4. В открывшемся окне выбрать шаблон Run Command, выбрать пакет для сохранения таска и нажать Next. Если пакет, в котором создано распределенное приложение, не запечатан, то Recovery task можно сохранить только в том же пакете управления.
5. На вкладке General, в поле Recovery Name, указать имя задачи: «Critical to Warning Recovery Task». Выбрать Critical health state и отметить значения Run recovery automatically и Recalculate monitor state after recovery finishes:
6. На вкладке CommandLine в поле Fullpathtofile указать какое-нибудь уникальное имя. В дальнейшем мы его заменим, но оно нам пригодится для поиска данного фрагмента при редактировании в XML. Нажать Create и затем Ok.
7. Далее необходимо экспортировать пакет управления где был сохранен Recovery task и открыть его для редактирования в любом редакторе. Перед редактированием необходимо сделать копию пакета!!!
8. Если это первый Recovery task такого типа в этом пакете, то необходимо создать ссылку в данном пакете на ранее установленную библиотеку. Для этого между тэгами <Reference></Reference> добавить строки следующего вида:
<Reference Alias="CustomTaskLibrary">
<ID>Custom.Task.Library</ID>
<Version>1.0.0.0</Version>
<PublicKeyToken>438e8ec9b8100732</PublicKeyToken>
</Reference>
9. Далее необходимо найти ранее созданный Recovery task. Его можно найти по тэгу <Recoveries> или по уникальному имени, которое было указано в поле Fullpathtofile.
В XML коде Recovery task будет выглядеть следующим образом:
<Recovery ID="MomUIGenaratedRecovery740fc548a8f748a6a69d2013a6cecd05" Accessibility="Public" Enabled="true" Target="SC_ea0945f3c9874a2b94b2a5749ef3ff66_Service_ddec17b501b64a94911602f8f1d981e1" Monitor="SCIMembership_a53870b8c04740c9abf01002955730b8_Availability_HealthMonitor" ResetMonitor="true" ExecuteOnState="Error" Remotable="true" Timeout="300">
<Category>Custom</Category>
<WriteAction ID="MomUIGenaratedModulece99d530c2b84e6f802d71b14087f301" TypeID="System!System.CommandExecuter">
<ApplicationName>Critical to Warning 555</ApplicationName>
<WorkingDirectory />
<CommandLine />
<TimeoutSeconds>15</TimeoutSeconds>
<RequireOutput>true</RequireOutput>
</WriteAction>
</Recovery>
10. Необходимо заменить часть, выделенную желтым цветом, следующим строками:
<WriteAction ID="WA" TypeID="CustomTaskLibrary!Custom.Task.Library.Set.Monitor.Action">
<MonitorId>$MPElement[Name="SCIMembership_a53870b8c04740c9abf01002955730b8_Availability_HealthMonitor"]$</MonitorId>
<HealthState>Warning</HealthState>
</WriteAction>
Значение параметра Name для тэга <MonitorId> необходимо поменять на значение, которое указано в параметре Monitor (выделено зеленым цветом).
11. Сохранить изменения в пакете и импортировать его в Operations Manager
12. После импорта проверить работу Recovery task для данной компоненты. Если состояние данной компоненты до создания Recovery task было Critical, то необходимо сбросить состояние нижележащих мониторов, так как Recovery task срабатывает как только объект переходит в состояние Critical.
|
Данный метод также имеет свои особенности в использовании:
· Он не умеет определять, какой объект вышел строя и поэтому не может менять состояние монитора в зависимости от имени объектов. Поэтому мы не можем использовать веса в этом методе в отличии от первого метода.
· Данный метод требует дополнительного тестирования, особенно в случаях больших разветвленных распределенных приложений, когда состояние объектов может достаточно быстро изменяться. Например, однажды мы наблюдали «залипания» состояния монитора. То есть за то время, когда отрабатывал Recovery task, состояние монитора менялось на Healthy, а уже после этого завершался Recovery task и менял состояние на Warning. Получалась ситуация, когда все объекты под этим монитором были в состоянии Healthy, а сам монитор в состоянии Warning. Между тем, нужно заметить, что Recovery task отрабатывает очень быстро (менее 500 ms).
В данном примере мы рассмотрели только один случай, когда монитор переходит из состояния Critical -> Warning. Конечно, можно сделать различные комбинации, например, Critical -> Healthy, Healthy-> Critical и т.д. Более того, можно менять состояние другого монитора, а не только того, который содержит Recovery task.
Для вашего удобства, в прикрепленном файле находится пакет управления, который может быть использован в качестве библиотеки.
Будем рады услышать комментарии и отзывы.
Данная статья носит информационный характер, ссылки на веб-сайты предоставляются для удобства пользователей. Корпорация Майкрософт не несет никакой ответственности за содержание веб-сайтов, не предоставляет никаких гаран т ий относительно точности, полноты или законности их содержания, ссылки на которые используются в данной статье. Ссылка на внешний узел не подразумевает одобрения мнений, информации или продукции представленной на таких веб-сайтах.
Comments
- Anonymous
November 06, 2014
В сегодняшней статье речь пойдет о том, как создать свой кастомный зависимый (dependency) монитор для