Главная System Center, Новое System Center Operations Manager 2007 — Пакеты управления
  • System Center Operations Manager 2007 — Пакеты управления

    В прошлых статьях я не раз упоминал пакеты управления (management pack, МП). Пришло время поговорить о них поподробнее, т.к. пакеты управления – один из ключевых элементов OpsMgr. МП — кирпичики, из которых складывается система. Без пакетов управления OpsMgr – голая программная оболочка. Именно из пакетов управления OpsMgr узнает, что и как ему надо выполнять, что и где отображать в интерфейсе и т.д. Фактически пакет управления – это модуль описания, содержащий правила построения системы и ссылки на библиотеки сборок.

    Концепция модульности давно используется различными компаниями для своих продуктов. Компания Microsoft не осталась в стороне от этого процесса, модули используют во многих решениях компании, начиная от операционной системы и заканчивая такими продуктами, как Sharepoint. Везде модули имеют разную реализацию, но все служат одной цели – расширять функционал базового продукта. OpsMgr целиком основан на модулях – все компоненты системы реализованы с помощью пакетов управления, от базовых функций до конкретных пакетов управления для определенных систем.

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

    Общие принципы

    Все установленные МП можно посмотреть из консоли OpsMgr: Administration -> Management Packs. Пакет управления может быть в двух состояниях: подписанный (sealed) и не подписанный (unsealed).




      Подписанный Не подписанный
    Сущность Представляет собой откомпилированный файл Представляет собой обычный документ XML
    Экспорт Нельзя экспортировать обычными средствами Можно сохранить из консоли OpsMgr в виде обычного XML-документа
    Изменение Нельзя править. В том числе нельзя сохранять в них созданные правила, мониторы, переопределения и пр. Можно изменять как из консоли OpsMgr, так и «руками» после экспортирования.
    Импорт Нельзя импортировать пакет, имеющий такое же имя и версию. Можно импортировать пакет, имеющий такое же имя и версию. При этом имеющий МП будет перезаписан.
    Ссылки На подписанный пакет можно ссылаться из других МП На не подписанный МП нельзя ссылать из других МП

    Отдельно хотелось бы пояснить последний пункт. Например, если вы создали свою группу в каком-либо пакете, то все остальные объекты, использующий эту группу (переопределения, представления и пр.), необходимо также сохранять в этом же МП.

    Установка и удаление пакетов управления

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

    Общие рекомендации при установке МП:

    1. Не импортируйте сразу много пакетов, старайтесь импортировать за один раз МП, относящиеся к одной роли. Так вам проще будет бороться с возникающими алертами, настраивать МП и поможет избежать проблем с производительностью.
    2. ВСЕГДА читайте документацию, идущую с МП. Некоторые пакеты требуют дополнительной настройки или имеют особенности в работе, которые затем могут сказаться на вашей среде.
    3. Старайтесь тестировать новые МП до того, как они будут установлены в основную среду.
    4. ВСЕГДА создавайте новый МП для хранения переопределений для каждой роли.
    5. Старайтесь ничего не сохранять в МП «Default Management Pack»

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

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

    Системные пакеты управления

    При установке OpsMgr происходит установка нескольких не подписанных пакетов управления.

    Первый я уже упоминал, это «Default Management Pack». В него интерфейс системы предлагает сохранять все изменения, сделанные в консоли OpsMgr (но как я уже говорил, делать этого категорически не рекомендуется). Кроме этого в нем сохраняются следующие настройки OpsMgr:

    1. Active Directory Integration
    2. Представления, расположенные в корне консоли (поэтому не стоит создавать новые представления в корне)

    Второй пакет управления, это Client Monitoring Overrides Management Pack. В нем хранятся настройки Client monitoring-а (сбор ошибок и пр.).

    Третий пакет, это Notifications Internal Library. Как понятно из названия, в нем хранятся настройки оповещений.

    Резервное копирование

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

    Структура и состав пакета управления

    Как я уже говорил, OpsMgr основан на SML (Service Modeling Language), а так как этот язык целиком и полностью описывается с помощью XML, то вполне логично, что и пакеты управления в OpsMgr также описаны с помощью XML. В этой связи понимание основ XML и XPath критично для изучения и понимания структуры МП и дальнейшей работы с OpsMgr.

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

    1. Manifest – содержит метаданные МП, такие как название, идентификатор, номер версии и ссылки на другие МП.
    2. TypeDefinitions – содержит определение классов, отношений, типов данных, модулей и пр.
    3. Monitoring – содержит определение обнаружений, мониторов, правил, задач, переопределений.
    4. Templates – содержит определение шаблонов, т.е. частей МП, на основе которых можно строить части МП. Не описана в статье, т.к. представляет интерес только разработчикам.
    5. Presentation – содержит определение всего того, что отвечает за интерфейс: папки, представления, консольный задачи и пр. С точки зрения понимания принципов работы OpsMgr не несет особой полезной информации. Оставлено на самостоятельное изучение.
    6. PresentationTypes – содержит определение различных элементов, использующихся в интерфейсе: изображений, типы представлений, наборы страниц и страницы. Не описана в статье, т.к. представляет интерес только разработчикам.
    7. Reporting – содержит определение отчетов и всего что с ними связано (наборы данных, ресурсы и пр.). В данной статье не описано, т.к. описание отчетности требует отдельной большой статьи.
    8. LanguagePacks – содержит локализованные строки для одного или нескольких языков.

    Только первая секция является обязательной, все остальные являются опциональными.

    Общая структура пакета управления такова:

    <ManagementPack xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:xsl=”http://www.w3.org/1999/XSL/TransformContentReadable="true">
      <Manifest></Manifest>
      <TypeDefinitions></TypeDefinitions>
      <Monitoring></Monitoring>
      <Templates></Templates>
      <Presentation></Presentation>
      <PresentationTypes></PresentationTypes>
      <Reporting></Reporting>
      <LanguagePacks></LanguagePacks>
    </ManagementPack>

    Секция Manifest

    Данная секция является заголовком, и содержит в себе секции Identity, Name и Reference:

    <Manifest>
      <Identity>
        <ID> Microsoft.Windows.Library</ID>
        <Version>6.1.7221.0</Version>
      </Identity>
      <Name>System Library</Name>
      <References>
        <Reference Alias="ReferenceAlias">
          <ID>Vendor.Product.Library</ID>
          <Version>1.0.0.0</Version>
          <PublicKeyToken>454e34a47d158347</PublicKeyToken>
        </Reference>
        <Reference Alias="System">
          <ID>System.Library</ID>
          <Version>6.1.7221.0</Version>
          <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
        </Reference>
      </References>
    </Manifest>
    

     

    Identity

    Содержит ID и версию МП. ID каждого пакета управления, а также каждого объекта в пакете управления, должны быть уникальным в рамках одной группы управления OpsMgr. Поле ID является текстовым полем и, по сути, является внутренним именем объекта. Данное поле может содержать только латинские буквы, цифры, знак точки и подчеркивание. Т.к. данное поле должно быть уникальным, хорошим тоном является именования МП по принципу «НазваниеКомпании.Продукт.ПредназначениеМП», (все объекты внутри данного МП именуются по такому же принципу). Примеры поля ID: «Microsoft.SystemCenter.Library», «Microsoft.Windows.Library». Если вы изучали пакеты управления, то могли встретить ID объектов, содержащие GUID-ы, например «MomUIGeneratedRulea7a54a3b6553407ea739f6bcf1275e8» или «SC_9f38539c90fb4f3b830ee3986d436412_Service_f68310d70f1a4adf9903170a0179e83b_ItemPopulation». Это означает, что данный объект был создан из консоли OpsMgr.

    Версия пакета управления состоит из четырех секций, разделенных точкой, например «1.0.0.0». В OpsMgr нельзя использовать одновременно несколько пакетов с одинаковым ID и разными версиями.

    Name

    Содержит отображаемое имя данного пакета управления

    Reference

    Содержит ссылки на другие пакеты управления. Alias – это имя МП, которое будет использовать в тексте данного МП. Version – минимальная версия пакета, PublicKeyToken – публичный ключ пакета. Как уже говорилось выше, ссылаться можно только на запечатанные (sealed) пакеты.

    Ссылка на другие пакеты необходима для того, чтобы использовать объекты, определенные не только в данном МП, но и в другом. Как было сказано в статье, посвященной моделированию, все классы в OpsMgr должны наследоваться от других классов. Например, класс Microsoft.Windows.Computer наследуется от класса System.Computer. Класс System.Computer определен в МП System.Library, а вот класс Microsoft.Windows.Computer определен в МП Microsoft.Windows.Library. Для того чтобы иметь возможность ссылать на класс, в МП Microsoft.Windows.Library добавлена ссылка на System.Library (см. пример выше).

    Когда вы работаете с консолью OpsMgr, все ссылки добавляются автоматически, и их нельзя изменить из консоли. Например, сохраняя в своем МП переопределение для монитора, который определен в МП Microsoft.Windows.Library, OpsMgr автоматически добавит ссылку на Microsoft.Windows.Library в ваш МП.

    Посмотреть, какие ссылки добавлены в МП можно из раздела Administration -> Management Packs -> Свойства необходимого МП -> вкладка Dependency.

    Еще одно важно замечание – удалить МП, на который есть ссылки из других МП нельзя. Именно поэтому крайне не рекомендуется ничего не сохранять в Default Management Pack. Представим ситуацию – у нас установлены пакеты управления для Exchange 2003. Вы создаете переопределение и сохраняете его в Default Management Pack. В этот момент в него добавляет ссылка на МП Exchange 2003. Проходит время, и вы обновляете свой Exchange 2003 до Exchange 2010, устанавливаете новые МП, и хотите удалить старые. Но система не даст вам этого сделать, т.к. в Default Management Pack имеется ссылка на МП Exchange 2003. Именно поэтому основная рекомендация: отдельная роль – отдельный МП.

    Секция TypeDefinitions    

    Данная секция предназначена в основном для разработчиков пакетов управления и содержит определение классов и отношений (секция EntityTypes), модулей (секция ModuleTypes), типов данных (секция DataTypes), типов мониторов (секция MonitorTypes), схем (секция SchemaTypes) и ссылки на RunAs-аакаунты (секция SecureReference, в данной статье не описана). Информация, представленная в этих секциях, крайне важна для общего понимания принципов работы OpsMgr и поиска ответов на вопросы «почему это так работает?».

    EntityTypes

    В данной секции находятся определения классов и их свойств (секция ClassTypes), а также отношения (секция RelationshipTypes).

    <EntityTypes>
      <ClassTypes>
        <ClassType ID="Vendor.Product.ClassName" Accessibility="Public" Abstract="false"
    
          Base="ReferenceAlias!Base.Class.Id" Hosted="false" Singleton="false">
          <Property ID="PropName" Type="string" Key="false" CaseSensitive="false" Length="256" 
    
            MinLength="0" />
        </ClassType>
      </ClassTypes>
      <RelationshipTypes>
        <RelationshipType ID="Vendor.Product.RelationshipName" Accessibility="Public" 
          Abstract="false" Base="System!System.Containment">
          <Source>Vendor.Product.ClassName</Source>
          <Target>Vendor.Product.AnotherClassName</Target>
        </RelationshipType>
      </RelationshipTypes>
    </EntityTypes>
    

    Секция ClassType определяет класс и его свойства. Атрибуты данной секции определяют параметры данного класса, описанные в статье о моделировании служб. Обратите внимание на атрибут Base. Данная запись означает, что класс Base.Class.Id определен в другом МП, алиас которого равен “ReferenceAlias”, ссылка на который определена в секции Manifest (см. пример в описании этой секции).

    Все остальные атрибуты говорят сами за себя, и были подробно описаны в прошлых статьях.

    ModuleTypes

    Прежде чем описать данную секцию, необходимо пояснить принцип работы OpsMgr «изнутри». Все процессы, происходящие в OpsMgr, такие как мониторы, правила, обнаружения, диагностические задачи и задачи восстановления, объединены в один термин – workflow. Workflow всегда состоит из определенных шагов, или модулей (modules). Данные модули определяют поведение workflow и порядок передачи данных внутри workflow. Все модули делятся на 4 вида:

    1. Data Source – данные модули генерируют данные, в общем случае являются точкой входа для всего workflow. Примером Data Source могут служить различные провайдеры событий (Windows Log Events, WMI Events и т.д.), планировщики (Schedulers). Данные модули не имеют входных данных, но генерируют выходные данные.
    2. Probe Action – данные модули имею как входные данные, так и выходные. Probe-модули получает данные из внешних (по отношению к OpsMgr) систем, и передают их в качестве выходных данных. Примером Probe-модулей служат модули получения данных из реестра, модули, получающие данные из скриптов, модули, получающие данные с помощью WMI-запросов и т.д.
    3. Condition Detection – данные модули также имеют входные данные и выходные. Они получают на вход данные, анализируют их, и по результатам анализа возвращают обработанные данные. Примером таких модулей могут служить различные фильтры значений, консолидаторы и пр.
    4. Write Action — данные модули предназначены для воздействия на объекты OpsMgr: запись данных в операционную базу, запись данных в отчетную базу, создание оповещения и др. Если Write Action присутвует в workflow — он всегда последний модуль в workflow.

    Для примера возьмем монитор, проверяющий некий объект OpsMgr. Мониторы я описывал в прошлой статье, напомню, как выглядит в общем случае выполнение монитора:

    1. Монитор запускает по расписанию
    2. Получает некие данные о проверяемой системе
    3. На основе неких параметров выносится заключение о состоянии «здоровья» объекта

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

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

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

    Базовые модули реализованы либо с помощью управляемого кода (managed code), либо не управляемого (unmanaged или native). При этом сощдание базовых модулей не доступно сторонним разработчикам, т.е. их можно встретить только в системных МП.

    Кроме выходных данных, каждый модуль должен иметь конфигурационные параметры. Эти параметры устанавливают поведение данного модуля. Например, для планировщика в качестве параметров передают расписание и дни исключения, для скриптового модуля – тело скрипта и параметры скрипта. При определении модуля указывается, какие параметры может принимать данный модуль. Параметры хранятся в виде XML-схемы.

    Некоторые (или все) параметры могут объявляться как переопределяемые (Overrideable), именно они затем появляются в интерфейсе OpsMgr, когда мы создаем переопределение.

    Теперь можно вернуться собственно к определению секции ModuleTypes. В этой секции в основном определяются именно композитные модули, которые затем используются для работы в workflow:

    <ModuleTypes>
      <DataSourceModuleType ID="Module1.ID" Accessibility="Public" Batching="false">
        <!-- Конфигурация модуля, XML-схема его параметров -->
        <Configuration>
          <xsd:element xmlns:xsd="http://www.w3.org/2001/XMLSchema" name="Param1" type="xsd:string" />
          <xsd:element xmlns:xsd="http://www.w3.org/2001/XMLSchema" name="Param2" type="xsd:int" />
        </Configuration>
        <!-- Часть параметров может быть переопределяемой, ссылка $Config/Param2$ соответствует параметру, определенному выше  -->
        <OverrideableParameters>
          <OverrideableParameter ID="Param2" Selector="$Config/Param2$" ParameterType="int" />
        </OverrideableParameters>
        <ModuleImplementation Isolation="Any">
          <!-- Данный модуль композитный, т.е. использует другие модели, ниже идет ссылка на них и передаются их параметры  -->
          <Composite>
            <MemberModules>
              <DataSource ID="Scheduler" TypeID="System!System.Discovery.Scheduler">...параметры модуля...</DataSource>
              <DataSource ID="Probe" TypeID="Windows!Microsoft.Windows.RegistryProbe">...параметры модуля...</DataSource>
            </MemberModules>
            <!-- Composition определяет последовательность выполнения модулей  -->
            <Composition>
              <Node ID="Probe">
                <Node ID="Scheduler" />
              </Node>
            </Composition>
          </Composite>
        </ModuleImplementation>
        <OutputType>Microsoft.Windows.RegistryData</OutputType>
      </DataSourceModuleType>
      <!-- Другие типы модулей. Их описание пропущена для экономии места  -->
      <ProbeActionModuleType ID=" Module2.ID " Accessibility="Public" Batching="false">...</ProbeActionModuleType>
      <ConditionalDetectionModuleType ID=" Module3.ID " Accessibility="Public" Batching="false">...</ConditionalDetectionModuleType>
      <WriteActionModuleType ID=" Module4.ID " Accessibility="Public" Batching="false">...</WriteActionModuleType>
    </ModuleTypes>
    
    MonitorTypes

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

    При определении типа монитора указывается:

    1. Количество и название состояний. Как уже говорилось при описании мониторов, мониторы могут быть с двумя или тремя состояниями (секция <MonitorTypeStates>).
    2. Схема параметров монитора. Описание данной схемы производится таким же образом, как и у модулей (секция <Configuration>).
    3. Список модулей, которые входят в данный тип монитора и их параметры (секция <MonitorImplementation>).
    4. Порядок, по которому выполняются модули (секция <RegularDetections>)
    5. Опционально, порядок, по которому выполняются модули, в случае вызова монитора «по запросу» (секция <OnDemandDetections>)

    Наличие секции <OnDemandDetections> в общем случае означает, что монитор будет поддерживать пересчет состояния (Recalculate state).

    Одно из состояний может иметь атрибут NoDetection=«true».Наличие данного атрибута означает, что для данного состояния нет правила, по которому вычисляется его состояние. Такие мониторы помечаются в системе как Manual Reset.

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

    <UnitMonitorType ID="CheckStateByScriptType" Accessibility="Public">
      <MonitorTypeStates>
        <MonitorTypeState ID="HealthState" />
        <MonitorTypeState ID="WarningState" />
        <MonitorTypeState ID="CriticalState" />
      </MonitorTypeStates>
      <Configuration>
        <xsd:element xmlns:xsd="http://www.w3.org/2001/XMLSchema" name="Frequency" type="xsd:unsignedInt" />
        <xsd:element xmlns:xsd="http://www.w3.org/2001/XMLSchema" name="ScriptBody" type="xsd:string" />
        <xsd:element xmlns:xsd="http://www.w3.org/2001/XMLSchema" name="Arguments" type="xsd:string" />
        <xsd:element xmlns:xsd="http://www.w3.org/2001/XMLSchema" name="HealthyExpression" type="Expression" />
        <xsd:element xmlns:xsd="http://www.w3.org/2001/XMLSchema" name="WarningExpression" type="Expression" />
        <xsd:element xmlns:xsd="http://www.w3.org/2001/XMLSchema" name="CriticalExpression" type="Expression" />
      </Configuration>
      <MonitorImplementation>
        <DataSource ID="Scheduler" TypeID="System.Scheduler">
          <!—На самом деле параметры этого модуля несколько сложнее, но я упростил их -->
          <Interval Unit="Seconds">$Config/Frequency$</Interval>
        </DataSource>
        <ProbeAction ID="RunScript" TypeID="Microsoft.Windows.ScriptPropertyBagProbe">
          <!-- тоже самое и тут, список параметров сокращен для удобства -->
          <Arguments>$Config/Arguments$</Arguments>
          <ScriptBody>$Config/ScriptBody$</ScriptBody>
        </ProbeAction>
        <ConditionDetection ID="HealthFilter" TypeID="System!System.ExpressionFilter">
          <Expression>$Config/HealthyExpression$</Expression>
        </ConditionDetection>
        <ConditionDetection ID="WarninghFilter" TypeID="System!System.ExpressionFilter">
          <Expression>$Config/WarinngExpression$</Expression>
        </ConditionDetection>
        <ConditionDetection ID="CriticalFilter" TypeID="System!System.ExpressionFilter">
          <Expression>$Config/CriticalExpression$</Expression>
        </ConditionDetection>
        <RegularDetections>
          <RegularDetection MonitorTypeStateID="HealthState">
            <Node ID="HealthFilter">
              <Node ID="RunScript">
                <Node ID="Scheduler"/>
              </Node>
            </Node>
          </RegularDetection>
          <RegularDetection MonitorTypeStateID="WarningState">
            <Node ID="WarninghFilter">
              <Node ID="RunScript">
                <Node ID="Scheduler"/>
              </Node>
            </Node>
          </RegularDetection>
          <RegularDetection MonitorTypeStateID="CriticalState">
            <Node ID="CriticalFilter">
              <Node ID="RunScript">
                <Node ID="Scheduler"/>
              </Node>
            </Node>
          </RegularDetection>
        </RegularDetections>
      </MonitorImplementation>
    </UnitMonitorType>
    

    В данном случае монитор, созданный на основе данного типа монитора, будет работать следующим образом:

    1. Монитор будет запускать раз в $Config/Frequency$ секунд
    2. При каждом выполнении будет запускать текст скрипта $Config/ScriptBody$, и этому скрипту будут передаваться параметры $Config/Arguments$.
    3. После этого результат выполнения скрипта будет передан в фильтр HealthFilter, т.к. состояние HealthState у нас стоит первым в списке.
    4. Если фильтр вернет данные, то состояние монитора будет установлено в HealthState.
    5. Если нет – данные из модуля скрипта передаются на фильтр WarninghFilter, т.к. состояние WarningState стоит вторым в списке.
    6. Далее по той же логике, что и с HealthState.
    SchemaTypes

    Параметры модулей (соответственно правил, мониторов и прочих workflow) могут быть переданы не только в виде простых типов (строка, число, дата и пр.), но и в виде XML. В этом случае в качестве типа (type) при определении параметра указывается имя схемы (в примере с типом монитором я использовал такой подход, когда определял параметры HealthyExpression, WarningExpression и CriticalExpression). Схемы задаются заранее в секции SchemaTypes. Например, вот так выглядит схема, определяющая возможные типы запуска службы Windows:

     

    <SchemaType ID="Microsoft.Windows.ServiceControlManager.StartupTypeDefinitionsSchema" Accessibility="Internal">
      <xsd:simpleType xmlns:xsd="http://www.w3.org/2001/XMLSchema" name="WindowsServiceStartupType">
        <xsd:restriction base="xsd:string">
          <xsd:enumeration value="Auto" />
          <xsd:enumeration value="Demand" />
          <xsd:enumeration value="Disabled" />
        </xsd:restriction>
      </xsd:simpleType>
    </SchemaType>
    

    В модуле это будет выглядеть следующим образом:

     

    <DataSourceModuleType ID="Module1.ID" Accessibility="Public" Batching="false">
      <Configuration>
        <IncludeSchemaTypes>
          <SchemaType>Microsoft.Windows.ServiceControlManager.StartupTypeDefinitionsSchema</SchemaType>
        </IncludeSchemaTypes>
        <xsd:element xmlns:xsd="http://www.w3.org/2001/XMLSchema" name="Param1" type="xsd:string" />
        <xsd:element xmlns:xsd="http://www.w3.org/2001/XMLSchema" name="ServiceStartUpType" type="WindowsServiceStartupType" />
      </Configuration>
    

                

    DataTypes

    В данной секции определяются типы, которые используются в модулях в виде входных и выходных данных. Определение типа дынных представляет собой ссылку на внешние классы (сборка .NET или неуправляемый код).

    Секция Monitoring

    Данная секция содержит в себе описание всех workflow, доступных в OpsMgr: обнаружений, мониторов, правил, задач и переопределений.

    Discoveries

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

    1. Цель (Target) обнаружения, т.е. на экземплярах какого класса будет запускаться данное обнаружение (атрибут Target)  
    2. Необходимо ли запускать обнаружение на безагентных (agentless) системах (атрибут Remotable)  
    3. Поиск каких классов, свойств классов и отношений производится (секция <DiscoveryTypes>).
    4. Источник данных – композитный модуль специального типа, который запускает процесс обнаружения, а затем сопоставляет данные с классами, со свойствами класса и с отношениями (секция <DataSource>).
    5. В случае, если источник данных вернул данные, которые соответствуют типам, заявленным для этого обнаружения в п.2, считает что объекты присутствуют на данном экземпляре.

    Обычно модуль, который служит в качестве источника данных для обнаружения, носит соответствующее название, например: Microsoft.Windows.Discovery.RegistryProvider, Microsoft.Windows.TimedPowerShell.DiscoveryProvider.

    Для примера приведу полностью обнаружение, которое ищет класс Microsoft.Windows.Server.Computer на объектах класса Microsoft.Windows.Computer:

    <Discovery ID="Microsoft.SystemCenter.DiscoverWindowsServerComputer" Enabled="true"
    
         Target="Windows!Microsoft.Windows.Computer" ConfirmDelivery="false" 
         Remotable="true" Priority="Normal">
      <Category>Discovery</Category>
      <DiscoveryTypes>
        <DiscoveryClass TypeID="Windows!Microsoft.Windows.Server.Computer" />
      </DiscoveryTypes>
      <DataSource ID="DS" TypeID="Windows!Microsoft.Windows.WmiProviderWithClassSnapshotDataMapper">
        <NameSpace>\\$Target/Property[Type="Windows!Microsoft.Windows.Computer"]/NetworkName$\ROOT\CIMV2</NameSpace>
        <Query>SELECT NumberOfProcessors FROM Win32_ComputerSystem WHERE DomainRole &gt;1 and DomainRole &lt;4</Query>
        <Frequency>86400</Frequency>
        <ClassId>$MPElement[Name="Windows!Microsoft.Windows.Server.Computer"]$</ClassId>
        <InstanceSettings>
          <Settings>
            <Setting>
              <Name>$MPElement[Name="Windows!Microsoft.Windows.Computer"]/PrincipalName$</Name>
              <Value>$Target/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$</Value>
            </Setting>
          </Settings>
        </InstanceSettings>
      </DataSource>
    </Discovery>
    

    Как видно, данное обнаружение выполняет запрос к WMI, который выбирает компьютеры с ролью Standalone Server и Member Server (ограничение DomainRole > 1 and DomainRole < 4), и в случае получения не пустого ответа (т.е. наличие хотя бы одной строки и столбца) передает в OpsMgr, что на данном экземпляре класса Microsoft.Windows.Computer есть объект класса Microsoft.Windows.Server.Computer. Получение свойства NumberOfProcessors здесь выбрано лишь потому, что на всех компьютерах оно гарантированно будет иметь какое-то значение. Значение свойства DomainRole легко можно найти в документации.

    Rules

    Правила (rules) служат для запуска workflow внутри OpsMgr, не влияющих на состояние здоровья (health) объектов. Это их ключевое отличие от мониторов. Т.е. если вам необходимо производить проверку некоего объекта без влияния на состояние его здоровья, или запускать некие процессы – вам необходимо пользоваться правилами. Правила используются в OpsMgr для следующих целей:

    1. Сбор информации и запись её в операционную и\или отчетную базы данных. В основном это сбор данных о производительности или событий (Events).
    2. Генерация оповещений (alerts).
    3. Запуск любых внутренних процессов, таких как обслуживание баз данных OpsMgr и прочие.

    Отдельно хочется остановиться на п.2. Генерация оповещений оставлена в OpsMgr для совместимости – в MOM не было понятия «мониторы», и все предупреждения генерировались правилами. Старайтесь как можно реже использовать такие правила, т.к. сгенерированные ими оповещения никогда не закроются автоматически, в отличие от мониторов, которые могут закрываться автоматически, когда объект переходит в состояние «здоров». Хотя конечно есть ситуации, когда не желательно влиять на здоровье объекта, но получать оповещение необходимо.

    Список всех правил вы можете посмотреть в консоли, Authoring -> Management Pack Objects -> Rules.

    При определении правила указывается следующая информация:

    1. Цель (атрибут Target)  
    2. Необходимо ли запускать правило на безагентных (agentless) системах (атрибут Remotable)  
    3. Источник данных, один или несколько (секция <DataSource>)
    4. Опционально, фильтр (секция <ConditionalDetection>). Применяется в основном при генерации оповещений или для отсеивания ненужных событий. 
    5. Модуль записи, один иле несколько (секция <WriteActions>). Обычно применяется три типа модулей: запись в операционную БД, запись в отчетную БД и генерация оповещения.

    Для примера полностью приведу определение правила, которое собирается данные производительности:

     

    <Rule ID="Microsoft.SystemCenter.NTService.CollectPercentProcessorTime" Enabled="true"
          Target="Microsoft.SystemCenter.OwnProcessNTService" ConfirmDelivery="false"
          Remotable="true" Priority="Normal" DiscardLevel="100">
      <Category>PerformanceCollection</Category>
      <DataSources>
        <!-- Модуль, который собирает данные из счетчиков Windows по расписанию -->
        <DataSource ID="DS" TypeID="Microsoft.SystemCenter.NTService.Frequency.RawPerfCounterProvider">
          <!-- параметры данного модуля -->
          <ServiceName>$Target/Property[Type="Microsoft.SystemCenter.NTService"]/ServiceName$</ServiceName>
          <ObjectName>Process</ObjectName>
          <CounterName>Percent Processor Time</CounterName>
          <InstanceProperty>Name</InstanceProperty>
          <ValueProperty>PercentProcessorTime</ValueProperty>
          <Frequency>600</Frequency>
          <ScaleBy>$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/LogicalProcessors$</ScaleBy>
        </DataSource>
      </DataSources>
      <WriteActions>
        <!-- Модуль, который записывает данные в операционную базу данных -->
        <WriteAction ID="WriteToDB" TypeID="SC!Microsoft.SystemCenter.CollectPerformanceData" />
        <!-- Модуль, который записывает данные в отчетную базу данных -->
        <WriteAction ID="WriteToWarehouse" TypeID="SCDW!Microsoft.SystemCenter.DataWarehouse.PublishPerformanceData" />
      </WriteActions>
    </Rule>
    

    Для сравнения, тот же монитор в интерфейсе консоли OpsMgr:

    Tasks

    Задачи (tasks) – это workflow, которые запускаются по требованию, в ручном режиме. Обычно задачи запускаются из консоли, их можно увидеть в секции Action:

    Задачи, доступные из консоли, делятся на 2 вида: консольные и агентные . Отличаются они тем, что первые запускаются на том компьютере, где запущена консоль, и, что немало важно, с правами текущего пользователя. Агентные же запускаются на стороне агента, и с правами Action Account (обычно это System). Не надо пояснять, какие последствия могут быть от неправильного и несанкционированного использования таких задач. Поэтому обратите внимание на этот аспект, когда будете планировать роли в OpsMgr. Подробнее об этом я надеюсь описать в статье, посвященной безопасности в OpsMgr.

    В секции Tasks описываются только агентные задачи. Консольные задачи описываются в секции Presentations.

    При описании задачи передается следующая информация:

    1. Цель (атрибут Target). В данном случае цель определяет при выборе какого объекта в консоли будет появляться данная задача. 
    2. Write-модуль или Probe-модуль. Зависит от того, изменяет ли данный модуль состояние системы или нет. Например, получение информации о запущенных процессах – это probe, а вот перезапуск службы – это write.

    Для примера приведу полностью определение задачи «Stop SQL Server Service»:

    <Task ID="Microsoft.SQLServer.2008.DBEngine.StopService" Accessibility="Internal"
          Enabled="true" Target="SQL2008Core!Microsoft.SQLServer.2008.DBEngine"
          Timeout="300" Remotable="false">
      <Category>Maintenance</Category>
      <WriteAction ID="WA" TypeID="System!System.CommandExecuter">
        <ApplicationName />
        <WorkingDirectory />
        <CommandLine>net stop $Target/Property[Type="SQL!Microsoft.SQLServer.DBEngine"]/ServiceName$ /y</CommandLine>
        <TimeoutSeconds>300</TimeoutSeconds>
        <RequireOutput>true</RequireOutput>
        <Files />
      </WriteAction>
    </Task>
    
    Monitors

    Данная секция содержит определение мониторов: unit-мониторов и rollup-мониторов. Unit-мониторы подробно были описаны в секции MonitorTypes, поэтому здесь остается только продемонстрировать описание монитора.

    При описании unit-монитора передается следующая информация:

    1. Цель (атрибут Target). В данном случае цель определяет, на экземплярах какого класса будет запускать монитор. 
    2. Родительский монитор – один из aggregate rollup-мониторов (атрибут ParentMonitorID). 
    3. Ссылку на тип монитора (атрибут TypeID)  
    4. Необходимо ли запускать обнаружение на безагентных (agentless) системах (атрибут Remotable)  
    5. Настройки генерации оповещений (секция <AlertSettings>)
    6. Описание состояний и соответствие состояниям типа монитора (секция <OperationalStates>)
    7. Параметры типа монитора (секция <Configuration>)

    Приведу пример определения монитора, проверяющего состояние с помощью скрипта. Он основан на типе монитора, описанного ранее:

    <UnitMonitor ID="MyScriptMonitor" Accessibility="Public" Enabled="true"
                 Target="Windows! Microsoft.Windows.Computer"
                 ParentMonitorID="SystemHealth!System.Health.ConfigurationState"
                 Remotable="true" Priority="Normal" TypeID="CheckStateByScriptType"
                 ConfirmDelivery="false">
      <Category>ConfigurationHealth</Category>
      <OperationalStates>
        <OperationalState ID="ObjectIsOK" MonitorTypeStateID="HealthState " HealthState="Success" />
        <OperationalState ID="ObjectIsWarn" MonitorTypeStateID="WarningState" HealthState="Warning" />
        <OperationalState ID="ObjectIsDown" MonitorTypeStateID="CriticalState" HealthState="Critical" />
      </OperationalStates>
      <Configuration>
        <Frequency>900</Frequency >
        <!-- Естественно, что в реальных условиях основные параметры должны иметь значения, но я их пропустил -->
        <ScriptBody />
        <Arguments />
        <HealthyExpression />
        <WarningExpression />
        <CriticalExpression />
      </Configuration>
    </UnitMonitor>
    

    Кроме этого, в данной секции определяются Aggregate rollup мониторы и dependency rollup мониторы.

    При описании aggregate мониторов передается следующая информация:

    1. Цель (атрибут Target). 
    2. Родительский монитор – один из aggregate rollup-мониторов (атрибут ParentMonitorID). 
    3. Необходимо ли запускать обнаружение на безагентных (agentless) системах (атрибут Remotable)  
    4. Политика сбора здоровья (секции <Algorithm>)
    5. Настройки генерации оповещений (секция <AlertSettings>)

    При описании dependency мониторов передается следующая информация:

    1. Цель (атрибут Target). 
    2. Родительский монитор – один из aggregate rollup-мониторов (атрибут ParentMonitorID). 
    3. Отношение (атрибут RelationshipType)  
    4. Монитор, на который идет ссылка (атрибут MemberMonitor)  
    5. Необходимо ли запускать обнаружение на безагентных (agentless) системах (атрибут Remotable)  
    6. Политика сбора здоровья (секции <Algorithm>, <MemberUnAvailable> и <MemberInMaintenance>)
    7. Настройки генерации оповещений (секция <AlertSettings>)
    Diagnostics и Recoveries

    Задачи диагностики и задачи восстановления являются workflow, запускаемыми по событию. Эти задачи привязаны к монитору. Данные workflow запускаются, когда монитор переходит в указанное состояние. Например, монитор состояния службы может иметь восстанавливающую задачу, настроенную на переход монитора в состояние critical, которая будет пытаться запустить данную службу. Восстанавливающие и диагностические задачи запускаются только один раз, в момент смены состояния. Если эти задачи закончились не удачей, повторной попытки запуска не будет.

    Эти задачи могут иметь выходные данные, которые затем записываются в базу данных и доступны в Health Explorer. Например, в случае выполнения консольной команды записывается вывод этой команды:

    В интерфейсе консоли OpsMgr настройка диагностических и восстанавливающих задач находится в свойствах каждого монитора:

    Задачи могут запускать автоматически, либо вручную (см. на первом рисунке ссылка на задачи. При её нажатии задача запуститься снова).

    Из консоли OpsMgr доступно создание восстанавливающих и диагностических задач, основанных на выполнение команды или скрипта (vbs).

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

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

    К примеру, если одна и та же служба постоянно «падает» и на её монитор настроена восстанавливающая задача, вы можете пропустить сообщения об остановке службы, т.к. алерты будут автоматически закрываться. В этом случае полезно настраивать оповещения на почту, или, что не самый оптимальный вариант и не рекомендуется делать, настраивать алерт таким образом, чтобы он не закрывался автоматически.

    С точки зрения определения диагностические и восстанавливающие задачи отличаются тем, что в первом случае используется Probe-модуль, а во втором – Write-модуль.

    Любая из задач может содержать модуль Conditional Detection, что позволяет запускать соответствующие задачи только по определенному фильтру.

    При описании данных задач передается следующая информация:

    1. Цель (атрибут Target)  
    2. Монитор, для которого создается данная задача (атрибут Monitor)  
    3. Для восстанавливающих задач можно указать, необходимо ли производить перерасчет (recalculate) состояние (атрибут ResetMonitor). Монитор должен поддерживать пересчет состояния. 
    4. При переходе в какое состояние необходимо выполнять монитор (атрибут ExecuteOnState)  
    5. Необходимо ли запускать задачи на безагентных (agentless) системах (атрибут Remotable)  
    6. Соответствующие модули (секции <ConditionalDetection> и <WriteAction> для восстанавливающих, и секции <ConditionalDetection> и <ProbeAction> для диагностических)  

    Пример восстанавливающей задачи, запускающий службу OpsMgr SDK:

    <Recovery ID="Microsoft.SystemCenter.SDKService.AutomaticallyRestart"
              Accessibility="Internal" Enabled="true"
              Target="SCLibrary!Microsoft.SystemCenter.RootManagementServer"
              Monitor="Microsoft.SystemCenter.SDKService.ServiceMonitor" ResetMonitor="false"
              ExecuteOnState="Error" Remotable="false" Timeout="300">
      <Category>Maintenance</Category>
      <WriteAction ID="RestartService" TypeID="System!System.CommandExecuter">
        <ApplicationName>%Windir%\System32\net.exe</ApplicationName>
        <WorkingDirectory />
        <CommandLine>start OMSDK</CommandLine>
        <TimeoutSeconds>300</TimeoutSeconds>
        <RequireOutput>true</RequireOutput>
      </WriteAction>
    </Recovery>
    
    Overrides

    Переопределения (overrides) – это тот функционал OpsMgr, которым вы будете пользоваться очень часто. Переопределения позволяют влиять на выполнение любого workflow в системе путем изменения значения его параметров или свойств. К примеру, мы можем отключить определенный монитор на определенной группе объектов, мы можем изменить частоту выполнения определенного правила и т.д.

    Когда я описывал типы модулей, я упомянул секцию <OverrideableParameters>. Именно это секция отвечает за то, такие параметры данного модуля можно переопределить. При создании переопределения для workflow (правила, монитора, обнаружения и т.д.) система собирает все параметры, объявленные как переопределяемые, для всех модулей данного workflow. Еще одно свойство добавляется в любом случае для всех workflow – это свойство Enable, отвечающее за то, разрешен ли запуск данного workflow. Я не случайно употребил два разных термина – параметр и свойство, с точки зрения OpsMgr «Enabled» это именно свойство workflow и описывается в отдельной секции.

    В качестве цели переопределение может использовать:

    1. Класс. В этом случае переопределение будет действовать на все экземпляры данного класса, и все экземпляпы классов-потомков. В интерфейсе консоли это соответствует пунктам меню For object of a class и For all object of another class
    2. Конкретный экземпляр класса. В этом случае переопределение будет действовать только на данный объект, и все расположенные в нем объекты (см. host-отношения). В интерфейсе консоли это соответствует пункту меню For specified object of a class
    3. Группа. В отличие от workflow, переопределение производит разворачивание группы. В этом случае переопределение будет действовать на объекты в данной группе, а также на все объекты, находящие в этих объектах (см. host-отношения)

    Хотелось бы привести пример, поясняющий фразу «находящийся в объекте». Возьмем класс DNSServer и DNSZone. Между ними установлены host-отношения, определяющие, что экземпляр DNSZone расположен на экземпляре DNSServer. Существует монитор «DNS Zone Resolution Monitor», который нацелен на класс DNSZone. Если мы создадим группу, в которую включим несколько объектов класса DNSServer, и создадим переопределение для монитора «DNS Zone Resolution Monitor», которое будет нацелено на эту группу, то данное переопределение будет действовать на все зоны DNS, расположенные на серверах в этой группе. Данное поведение позволяет настраивать переопределение любых workflow на группы компьютеров, т.к. очень многие объекты OpsMgr имеют host-отношения с классом Windows Computer. К примеру, если мы хотим отключить обнаружение DNS-серверов на всех серверах, где у нас есть SQL, нам не нужно создавать отдельную группу, в которую включать экземпляры класса Windows Server Computer, а мы смело можем в качестве цели выбрать существующую группу SQL Servers, в которую входят экземпляры классы Windows Computer.

    Описание секции Overrides достаточно объемное за счет того, что создается дополнительная секция для каждого типа workflow, поэтому полный список всех возможных вариантов я приводить не буду. Кроме этого, в отличие от workflow, вряд ли вам захочется смотреть параметры ваших переопределений в тексте МП. Для этого есть гораздо более удобные способы, которые я уже описывал.

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

    Но дело в том, что в этом случае OpsMgr не дает нам выбрать пакет, в который мы сохраняем это переопределение, а по умолчанию сохраняет его в Default Management pack. А, как я уже не раз писал, делать этого не рекомендуется. Именно поэтому не используйте эту возможность, вместо этого пользуйтесь пунктом Override the Monitor ниже.

    Секция LanguagePacks

    Если вы вместе с чтением данной статьи заглядывали в текст МП (на что я очень надеюсь), вы наверное заметили, что нигде ранее не встречалось «понятных», названий мониторов, правил, обнаружений и т.д., таких, каких мы их видим в консоли OpsMgr. Везде, в каждом объекте лишь указан ID (внутреннее имя).

    Дело в том, что Microsoft использовала очень интересный подход в локализации продукта. Данный подход впервые был реализован в OpsMgr, и получил продолжение в линейке System Center, сейчас такой же способ локализации используется SCSM.

    Решение заключается в том, что все объекты (классы, свойства классов, имена мониторов правил, представлений и т.д.) имеют свои уникальные имена, а в специальной секции хранится соответствие между внутренним именем и отображаемым именем (и если нужно описанием). Причем таких секция может быть несколько – по числу используемых языковых сред. В принципе, ничего революционного в этом решении нет, и оно давно используется в программировании. Новизна состоит в том, что всё это легко кастомизируется и хранится в виде обычного XML. Те, кто хоть раз сталкивался с ресурсными библиотеками и пробовал их изменять, думаю, меня поймут.

    Секция <LanguagePacks> как раз и отвечает за хранение этой информации. Данная секция имеет несколько дочерних секций <LanguagePack>, у которой есть два атрибута:

    1. ID – определяет код языка (например ENU, RUS, GER и т.д.)  
    2. IsDefault – определяет, что данная секция является основной.

    Вот так выглядит часть описания класса NTService:

    <LanguagePacks>
      <LanguagePack ID="ENU" IsDefault="true">
        <DisplayStrings>
          <DisplayString ElementID="Microsoft.SystemCenter.NTService">
            <Name>Windows Service</Name>
            <Description>Windows Service</Description>
          </DisplayString>
          <DisplayString ElementID="Microsoft.SystemCenter.NTService" SubElementID="Description">
            <Name>Description</Name>
            <Description>Description</Description>
          </DisplayString>
          <DisplayString ElementID="Microsoft.SystemCenter.NTService" SubElementID="DisplayName">
            <Name>Display Name</Name>
            <Description>Display Name</Description>
          </DisplayString>
        </DisplayStrings>
      </LanguagePack>
      <LanguagePack ID="RUS" IsDefault="false">
        <DisplayStrings>
          <DisplayString ElementID="Microsoft.SystemCenter.NTService">
            <Name>Служба Windows</Name>
            <Description>Служба Windows</Description>
          </DisplayString>
          <DisplayString ElementID="Microsoft.SystemCenter.NTService" SubElementID="Description">
            <Name>Описание</Name>
            <Description>Описание службы</Description>
          </DisplayString>
        </DisplayStrings>
      </LanguagePack>
    </LanguagePacks>
    

    Атрибут ElementID как раз и указывает, ID какого элемента определяется ниже. В секции RUS нет определения подэлемента DisplayName, поэтому при отображении будет использоваться значение из секции ENU, т.к. она объявлена секцией по умолчанию (IsDefault=«true»)

    Но данный подход имеет как плюсы, так и минусы, которые необходимо держать в уме. Дело в том, что OpsMgr определяется текущий язык с помощью системной функции GetUserDefaultUILanguage. Данная функция возвращает код языка текущего интерфейса Windows. Т.е. если у вас используется Windows 7 RUS, то при запуске консоли будет использовать русская секция. А вот если вы запустите консоль на Windows Server 2008 ENG, то консоль будет использовать английскую секцию. В реалиях российского ИТ ситуация, когда используют разные языковые версии операционных систем, повсеместна. «Да и ладно, ничего страшного, ведь всё равно мы используем английскую версию OpsMgr и английские версии пакетов управления, и у нас всё равно присутствует только ENU-секция» скажут многие. Данное утверждение верно ровно до того момента, пока вы не начнете создавать свои объекты – правила, мониторы, распределенные приложения, группы и прочее.

    Смоделируем ситуацию. В вашей инфраструктуре есть сервер OpsMgr с установленной консолью. Следую рекомендациям лучших собаководов, вы установили на нем английскую версию операционной системы. На вашей рабочей станции, и рабочей станции вашего начальника, установлена русскоязычная операционная система (или установлен и включен русский MUI, что в данном случае равноценно) и консоль OpsMgr. Вы со своей рабочей станции запускаете консоль, и создаете группу серверов для тестирования переопределения, назвав её «Some Servers». По доброй ИТ-шной традиции, вскоре эта группа из тестовой превратилась во вполне продакшен-группу. Для того, чтобы не забыть что это за группа, её надо бы переименовать. Вы запускаете консоль на сервере (ну просто под рукой была консоль сервера, так сложилось), и переименовываете её в «FrontEnd Exchange Servers» и даете ей внятное описание. С чувством выполненного долга заносите это всё в документацию и уходите домой счастливый и довольный, надеясь на премию. Однако вместо премии на следующий день вас ждет разъяренный начальник с претензиями «опять нифига не сделали, только отписку какую-то накатали. Вот где эта группа? Нету! Опять чушь пишешь!». Премия идет мимо. Но разобраться то надо, почему сделанная вчера работа не сохранилась. Вы запускаете консоль на своей рабочей станции, и действительно – группы «FrontEnd Exchange Servers» нет в списке. Зато вы замечаете, что по-прежнему присутствует старая группа «Some Servers».

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

    Также обратите внимание, что описание оповещений (alerts) также сохраняется в языковой секции.

    Хранение пакетов управления

    Как я уже говорил, все пакеты, как подписанные, так и не подписанные, хранятся в базе данных в виде XML. Расположены они в операционной базе данных (по умолчанию «OperationsManager») в таблице ManagementPacks. Она имеет несколько полей, самые интересные из них это:

    1. MPName – внутреннее имя пакет (ID)  
    2. MPFriendlyName – отображаемое имя пакета
    3. MPVersion – версия пакета
    4. MPXML – текст пакета управления

    В связи с тем, что все пакеты хранятся в виде XML, я предпочитаю изучать пакеты управления именно из базы данных. Этому способствует тот факт, что SQL Management Studio умеет отображать XML, полученный из БД, в виде форматированного и подсвеченного текста.

    Базовый запрос для получения всех пакетов выглядит следующим образом:

    select MPName, MPFriendlyName, CONVERT(xml, MPXML)
    from ManagementPack

    Вы получите список всех МП, установленных в системе и ссылки на их XML-код:

    Несколько изменив запрос, мы можем получить все не подписанные МП:

    select MPName, MPFriendlyName, CONVERT(xml, MPXML)
    from ManagementPack
    where MPIsSealed = 0

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

    При использовании запроса к БД алгоритм упрощается. Т.к. мы уже знаем, что все названия объектов хранятся в виде отдельных элементов в XML-документах, мы можем выполнить вот такой запрос (на примере монитора MSSQL «Service Pack Compliance»):

    select MPName, MPFriendlyName, CONVERT(xml, MPXML)
    from ManagementPack
    where MPXML like '%>Service Pack Compliance<%'

    В итоге мы получает форматированный текст пакета, находим в нем ID типа монитора по названию в секции LanguagePacks (просто копируем название и ищем с помощью Ctrl-F), находит определение этого типа монитора (точно также через Ctrl-F) и изучаем его структуру.

    Заключение

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

    В данной статье я описал основные компоненты, входящие в пакеты управления. Надеюсь, эта информация пригодится вам в изучении принциров работы OpsMgr. Если вы хотите полностью изучить структуру пакетов управления, вам помогут такие сайты как AuthorMPs и официальный сайт Operations Manager 2007 Management Pack Development Kit.

    Антон Гриценко ака FreemanRU

    opsmgr.ru

Комментарии

  1. Антон, спасибо за статью! Очень не хватает такой информации, и хоть я уже развернул решение, и изучил «Mastering SCOM2007» от Sybex — все равно куча нового и понятно изложено. Продолжайте, пожалуйста!

  2. С нетерпением буду ждать продолжение данных серий статей по scom

  3. Коллеги, прошу прощения, но видимо в ближайшее время масштабного ничего не будет, даже есть даже вероятность (хотя конечно мне бы не хотелось), что следующая статья увидит свет только после Нового Года.

  4. Хочу спросить, будут какие то кардинальные изменения в новой версии scom по начинке mp пакетов?

  5. Скорее всего да...

  6. Антон.

    использование авторинг тулз для создания и редактирования МП более чем достаточно.

    имхо.

  7. Во-первых, смотря для чего.

    Во-вторых, использование авторинга подразумевает знание XML-схемы МП.

  8. [...] схеме пакетов управления OpsMgr, вы можете прочесть мою статью про пакеты управления OpsMgr, чтобы понимать о чем идет [...]

  9. имеет ли значение на какой управляющий сервер импортировать МП — на MS или на RMS?

  10. нет. Импорт идет в БД, а не на сервер

  11. Хорошая статья. Вся структура xml на ладони. Что нельзя сделать в консоли, можно руками попраить в пакетах.

  12. Очень полезно и просто все расписано, так держать!

Опубликовать

Я не робот.