Детальное определение целей в Operations Manager 2007

Создание собственных объектов наблюдения (правил, мониторов, групп и так далее), является рутинной частью работы многих администраторов System Center Operations Manager (OpsMgr) 2007. Для каждого создаваемого объекта, необходимо ответить на стандартный вопрос – какую цель использовать.

Выбор верной цели для объекта очень важен, но правильный подход к этому может быть не всегда ясен. OpsMgr предлагает ряд вариантов для нацеливания. Эта статья рассмотрит несколько из них, с целью помочь администраторам выбрать соответствующий метод для каждой ситуации; термины «класс» и «цель» будут здесь употребляться взаимозаменяемо.

Предположим, что у нас есть внутреннее приложение, именуемое widget («штуковина»), за которым необходимо наблюдать. Все спецификации наблюдения уже определены и работа по созданию объектов наблюдения для widget началась. Однако быстро обнаруживается, что у widget нет точной цели! Согласно рекомендациям OpsMgr, все правила, мониторы и так далее должны быть нацелены на наиболее конкретный объект из возможных, чтобы ограничить распределение лишь интересующими системами. Какие возможности в OpsMgr могут помочь добиться этой цели?

Использование существующей цели

По умолчанию OpsMgr включает длинный список целей, и этот список растет с импортом новых пакетов управления. При создании нового объекта пакета управления ( MPO) и обдумывании его предназначения сначала следует проверить доступные элементы, чтобы увидеть, не будет ли достаточно одной из существующих целей. При создании MPO для расширения, например наблюдения за серверами System Management Server (SMS), вероятно, что существующие цели, импортированные вместе с пакетом управления сервером SMS, могут быть использованы повторно для MPO.

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

Распространенным подходом (хотя и не лишенным некоторых недостатков) является привязка нового MPO к клиенту Windows или классу сервера Windows или любому другому подходящему базовому классу (опять же, надо быть максимально конкретным), включающему требуемые цели. Делая это, не забудьте создать MPO в отключенном состоянии. После этого можно создать группу, содержащую все системы, где необходимо исполнить эти MPO и переопределить отключенные MPO, чтобы они включались только для агентов в группе. Это обеспечивает доставку MPO и их работу только на агентах, допускаемых переопределением.

Каковы недостатки этого подхода? Во-первых, использование этого метода нацеливает на более широкий класс объектов (компьютер Windows, например), так что все наблюдаемые MPO, нацеливаемые таким способом, появляются под целевым объектом в Health Explorer (см. рис. 1).

Рис. 1. Health Explorer для компьютера, на которого нацелено переопределение

На деле это чисто косметический момент, так что он может и не быть проблемой в определенной среде. Но нацеливание подобным образом вызывает воздействие на состояние работоспособности родительского объекта (такого как компьютер Windows), при воздействии на пользовательский монитор. Так что если у приложения widget возникает проблема, может пострадать работоспособность всего целевого объекта. В зависимости от того, что отслеживается, это может быть заслуживающим внимания, а может и нет.

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

Может показаться, что это вопрос семантики, но подумайте о группах в OpsMgr. Группы являются объектами, подобно любому другому объекту. Когда объект выбирается в качестве цели, это значит, что рассматриваемый MPO развертывается на агентах, владеющих целевым объектом.

Так какой же агент владеет объектом группы? Верно – корневой сервер управления (RMS). Нацеливание на группу вызовет доставку MPO агенту, владеющему группой, а это значит, что MPO будут развернуты только на RMS! Если MPO нацелены должным образом, то сцена уже подготовлена для развертывания MPOs на верных агентах, но отключение MPO останавливает этот процесс, прежде чем он может начаться.

При появлении переопределения существующая цель остается целью – переопределение просто меняет отключенный статус на включенный для нескольких агентов на членство в группе. Но агенты там, где MPO включен, уже являются частью первоначальной цели для MPO. Согласен, поначалу это немного сбивает с толку.

Теперь рассмотрим ситуацию, где не работает ни одна из изложенных выше идей. Что в ней делать? Остается лишь один вариант: создать новую цель, специально для MPO, что можно проделать либо используя шаблон наблюдения за службами в консоли операций, либо создав новую цель в консоли разработки.

Но перед рассмотрением этого, как насчет создания обнаружения атрибута? Можно подумать, что это приемлемый вариант, который был пропущен. Давайте посмотрим. Возможно создание обнаружения атрибутов, получающего информацию из реестра или от WMI. Чтобы работать, обнаружение атрибутов должно быть целью как класс, содержащий реестр или интересующие записи WMI. Обычными целями являются классы клиента Windows client или Windows Server, либо даже более общий класс компьютера Windows.

Отметьте, что сам термин (обнаружение атрибута) предполагает то, что происходит на практике: новый атрибут обнаруживается и используется для расширения существующего класса. Действительно, результатом этого становится создание нового класса, но на деле это тот же старый класс со все теми же членами, но с сообщением о новом атрибуте. Отталкиваясь от этого, можно увидеть, что обнаружение нового атрибута не идентично созданию действительно уникальной цели.

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

После выбора этого варианта в мастере, выдается предупреждение о том, что класс компьютера Windows нельзя расширить (он, в конце концов, находится в запечатанном пакете управления – если бы это не был запечатанный пакет управления, то не было бы и такого предупреждения), а переименованный класс цели представляется как выбор, который можно использовать, чтобы продолжить (см. рис. 2). Это происходит потому, что целью обнаружения атрибута является расширение существующего класса.

Рис. 2. Обнаружение атрибута не создает уникального класса

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

Рис. 3. Шаблон службы

Но имейте в виду, что использование шаблона может привести к созданию дополнительных MPO, помимо того, что предполагается или требуется. После использования шаблона службы, неплохо проверить, какие дополнительные объекты были созданы и определить, следует ли оставить их (см. рис. 4).

Рис. 4. Объекты, созданные при использовании шаблона

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

Если шаблон службы использовать нельзя или нежелательно, единственным остающимся вариантом является использование консоли разработки. Один взгляд на консоль разработки показывает, что правильное использование этого компонента требует очень глубокого рассказа – далеко выходящего за рамки этой статьи.

Тем не менее, стоит привести несколько простых примеров, в которых консоль разработки используется для создания и заполнения новой цели в OpsMgr. Я дам два примера, которые возвращаются к идее использования записи в реестре для уникальной идентификации приложения widget, а также третий пример, демонстрирующий обнаружение сценарием.

Создание целей с помощью консоли разработки

Во многих случаях, возможен поиск в реестре определенного значения и ключа, который уникально идентифицирует интересные серверы, размещающие желаемую цель. Если класс (цель) может быть построен и заполнен системами там, где существует ключ реестра widget, это будет простым способом создания уникальной цели.

Мой первый пример проходит через выполнение этого путем простого поиска существования ключа реестра. Второй пример будет искать конкретное значение, связанное с ключом реестра. Обратите внимание на то, что, хоть и возможно создать правило обнаружения атрибута реестра (как обсуждалось выше) и обнаружение в консоли разработки, как демонстрируется в следующих примерах, эти два действия не достигают тех же результатов – первое просто расширяет существующий класс, тогда как второе реально создает новую цель.

Использование ключа реестра

При первом запуске консоли разработки, необходимо сперва выбрать, следует ли загрузить существующий пакет управления или создать новый. При выборе создания нового пакета управления, появляется мастер, позволяющий выбрать шаблон либо для пустого пакета управления, либо для пакета управления Windows Application (Registry) («Приложение Windows (реестр)») (см. рис. 5).

Рис. 5. Выбор шаблона для нового пакета управления

И тот, и другой можно использовать для достижения тех же результатов, но новый класс создать проще, используя шаблон Windows Application (Registry). Необходимо просто предоставить имя и затем выбрать шаблон реестра. Далее необходимо предоставить имя и описание для пакета управления на экране имени и описания. Вводимое здесь значение – это значение, отображаемое в узле пакетов управления интерфейса пользователя Operations Manager.

Затем предоставьте описание приложения на экране Windows Application. Введенное здесь значение будет значением, отображаемое в узле атрибутов интерфейса пользователя Operations Manager. Далее, настройте насколько часто должно запускаться обнаружение. По умолчанию это происходит каждые 15 секунд – вероятно, слишком часто. Сбалансируйте потребность в быстром обнаружении с ударом по производительности, который может нанести слишком частое обнаружение. Как правило, нет особых причин запускать обнаружение чаще, чем раз в день.

Теперь заполните подробности, необходимые для обнаружения интересующего ключа реестра/значения. Существует несколько доступных типов атрибутов; тем, кто просто хочет проверить существование ключа, стоит использовать тип Bool.

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

Хорошо, так что мы реально создали после всего этого? Выполнили ли мы цель создания нового класса? В консоли разработки выберите узел модели службы и щелкните на классы. Отметьте, что был создан новый класс. Изучите его свойства, чтобы узнать больше об этом новом классе.

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

Значение реестра

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

Чтобы инициализировать мастер после завершения первоначального шаблона, перейдите к «Модель работоспособности» | «Обнаружения». На средней панели, щелкните правой кнопкой мыши и выберите «Создать» | «Реестр (отфильтрованный)». Записи будут теми же самыми, но на этот раз указано значение реестра.

Все просто! Пример окончится здесь, на создании новых целей. Но отметьте, что все еще требуется дополнительная работа для заполнения пакета управления MPO. MPO могут быть созданы либо через интерфейс пользователя диспетчера операций, либо напрямую в консоли разработки – оба способа работают нормально.

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

Вне зависимости от выбранного метода, был создан новый класс, который можно использовать для доставки правил. Как узнать, работает ли этот новый класс и обнаружение? Можно взглянуть на обнаруженную информацию памяти для нового класса и новый класс также появится как допустимая цель для нового монитора (показано на рис. 6).

Рис. 6. Новый класс как допустимая цель для монитора

Обнаружение посредством сценария

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

Поскольку это обнаружение на основе сценария, единственным применимым выбором является создание пустого пакета управления. Первым этапом в этом процессе является определение класса, который будет заполнен сценарием, вместе с представляющими интерес свойствами (атрибутами) класса. FileName, FileDirectory и FileDescription являются доступными свойствами, определенными этим классом, которыми можно управлять в сценарии, приведенном чуть ниже.

Вдобавок, свойство DisplayName наследуется от класса System.Entity и также может управляться сценарием. Отметьте, что только атрибуты, появляющиеся в этом списке могут управляться сценарием обнаружения, так что убедитесь, что здесь отображены все представляющие интерес элементы. Также обратите внимание на то, что при выборе каждого свойства (атрибута) подробные сведения об этом свойстве появятся справа. Не забудьте заполнить отображаемое имя для каждого свойства (атрибута). Если оставить их пустыми, то информация об обнаружении будет возвращена, но заголовки столбцов в среде OpsMgr, такие как представление обнаруженной ведомости, тоже будут пусты.

После определения класса можно создать обнаружение на основе сценария. Перейдите к «Модель работоспособности» | «Обнаружения». Щелкните правой кнопкой мыши, выберите «Создать» | «Сценарий» и создайте обнаружение. Здесь немало информации. Во-первых, общая вкладка позволяет назвать обнаружение и предоставить цель, на которой следует его выполнить. Помните, что цель нужно определять настолько конкретно, настолько возможно.

Для целей этой статьи подходит «компьютер Windows». На вкладке обнаруженных типов настройте тип объекта, который следует обнаружить. Отметьте, что имя обнаруженного типа совпадает с именем класса, определенным ранее.

Далее идет вкладка конфигурации, отображающая информацию, автоматически создаваемую при определении сценария. (Выберите «Настроить», чтобы увидеть сценарий и назначенное время его исполнения.) Также отметьте окно параметров (доступ к которому возможен путем выбора «Настройка» | «Сценарий» | «Параметры»). Взгляните на перечисленные параметры – я сошлюсь на них позже в этой статье.

Сценарий для управления процессом сбора обнаружений и подачи результатов OpsMgr показан на рис. 7. Это очень простой сценарий, но он предоставляет основу для ключевых элементов, необходимых для работа обнаружения на основе сценариев.

 Рис. 7. Сценарий обнаружения

Option Explicit
Dim oArgs
Set oArgs = WScript.Arguments

Dim oAPI

  'All of the work to submit discovery data is done in the context of
  'API's defined in the OpsMgr 2007 SDK.  Creating the oAPI object allows
  'access to the OpsMgr 2007 scripting environment
Set oAPI = CreateObject("MOM.ScriptAPI")

Dim SourceId, ManagedEntityId, targetComputer

  ' SourceId is the GUID of the discovery object that runs the script.
SourceId = oArgs(0)

  ' ManagedEntityId is the GUID of the computer class that is targeted by the script.
ManagedEntityId = oArgs(1)

  ' targetComputer is the Fully Qualified Domain Name
  ' of the computer targeted by the script. The FQDN
  ' is in Arg(2) of the command prompt.
targetComputer = oArgs(2)

Dim oFSO, oDiscoveryData, oInst

  'This operation sets the stage for creating new discovery data.  Note that the
  'values passed to the CreateDiscoveryData function are variables that are defined
  'by the command line when executed.  The parameters box was displayed earler.  This
  'is where the command-line parameters required by the CreateDiscoveryData object are 
  'defined and passed to the script.
Set oDiscoveryData = oAPI.CreateDiscoveryData(0, SourceId, ManagedEntityId)

  'This section defines objects needed to access the file system environment
Set oFSO = CreateObject("Scripting.FileSystemObject") 
If (oFSO.FolderExists("C:\WServer")) Then 

    'Assuming a folder called WServer was found on the root of the C drive, the script proceeds to create a new
    'class instance.  Once it's created, a number of property (attribute) values are filled in; note that all 
    'three of the properties (attributes) defined on the class are used in the script along with one property
    '(attribute) from the windows computer class.  Note the difference in how the script refers to properties 
    '(attributes) defined in the local class vs. a class that is accessed by reference.  Also note the Name field
    'as defined in the script.  Here the name is a friendly name that easily maps back to a known class name.  
    ' When the management pack is saved and imported into the Operations Console and the script delivered to the
    ' agents, these name values will no longer be friendly, they will be converted to the appropriate class GUID.  
    'Normally these converted values wouldn't be seen, but if the script directly on the agent is examined, 
    'the difference will be seen. Note that if the script attempts to define/use a property (attribute) 
    'that has not been defined in the referenced class, validation errors will be displayed.
  Set oInst = oDiscoveryData.CreateClassInstance("$MPElement[Name='Widget.Application.Script.Discovery.WidgetAppClass']$")
  Call oInst.AddProperty("$MPElement[Name='Windows!Microsoft.Windows.Computer']/PrincipalName$", targetComputer)
  Call oInst.AddProperty("$MPElement[Name='Widget.Application.Script.Discovery.WidgetAppClass']_
    /FileName$", "TestFileName.exe")
  Call oInst.AddProperty("$MPElement[Name='Widget.Application.Script.Discovery.WidgetAppClass']_
    /FileDirectory$", "TestFileDirectory")
  Call oInst.AddProperty("$MPElement[Name='Widget.Application.Script.Discovery.WidgetAppClass']_
    /FileDescription$", "TestFileDescription.exe")

    'Class Instance has now been created so the AddInstance method of the CreateDiscoveryData class is used to add
    'the completed instance.  From there the script returns the discovery data to OpsMgr for further processing.
  Call oDiscoveryData.AddInstance(oInst)
  Call oAPI.Return(oDiscoveryData)
End If

Импортирование этого пакета управления в OpsMgr ведет к обнаружению правильной системы, как показано на рис. 8. Отметьте, что каждое из свойств (атрибутов) определенных в сценарии, отображается в интерфейсе управления вместе со связанными значениями.

Рис 8. Обнаружение с помощью сценария

При взгляде на сценарий, можно увидеть, что значение для обнаруженного элемента можно передать прямо или через переменную. И помните о том, что если, как указывалось ранее, поле отображаемого имени для определенного свойства (атрибута) в классе можно оставить пустым, заголовки столбцов FileName, FileDirectory и FileDescription (см. рис. 8) также останутся пустыми.

Дополнительные соображения

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

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

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

• Рекомендуется запечатывать пользовательский пакет управления для использования в производстве.
• Запечатывание позволяет более жесткий контроль над версиями и изменениями.
• Запечатывание позволяет использовать одни процедуры эксплуатации для пользовательских и коммерческих пакетов управления. Необходимость различных процедур, таких, как для определения места размещения переопределений на пользовательских и коммерческих пакетов управления, вызывает массу путаницы.
• Классы, созданные в распечатанном пакете управления, будут видимы и пригодны для использования только другими MPO, хранящимися в том же пакете управления. Запечатывание позволяет использовать объекты вне зависимости от того, где хранится MPO.
• Библиотеку незапечатанных исходных пакетов управления можно держать под контролем администраторов OpsMgr для предотвращения случайных или ненамеренных изменений.

Полное понимание целей является ключевым для успеха при работе OpsMgr. Плакат, именуемый Rule and Monitor Targeting Best Practices («Рекомендации по определению целей среди правил и мониторов») доступен в формате PDF по адресу go.microsoft.com/fwlink/?LinkId=125048. Он должен стать очень полезной справкой для понимания различных целей и того, когда их стоит использовать.