HP Operations Manager. Работа с сервисами

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

Создание простой заготовки сервиса

Сервис регистрируется принятием его конфигурационного файла. Конфигурационный файл сервиса это файл разметки XML, в котором отражаются все аспекты реализации сервиса. Для полного понимания этой темы необходимо, как минимум, изучить раздел “HPOM Service Navigator” руководства “Administrator’s Reference”.

В этом разделе публикации будет рассмотрен процесс создания и регистрации сервиса от простого примитива до вполне развитого прототипа.

Создание и регистрация файла конфигурации

В любом текстовом процессоре создать файл с любым значимым именем (test.xml) приблизительно такого содержания:

<?xml version="1.0" encoding="UTF-8"?>                  <1>
<Services                                               <2>
  xmlns="http://www.hp.com/OV/opcsvc"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.hp.com/OV/opcsvc
  /etc/opt/OV/share/conf/OpC/mgmt_sv/dtds/service.xsd"> <3>
    <Service>                                           <4>
      <Name>general</Name>                              <5>
      <Label>My General Service</Label>                 <6>
      <Description>Service prototype</Description>      <7>
    </Service>
</Services>

Обязательное объявление типа и кодировки текста
Обязательное объявление корневого элемента
Обязательное перечисление пространств имён
Обязательная секция объявления сервиса (хотя бы один сервис должен быть определён)
Обязательное имя. Используется для ссылок на этот сервис
Необязательная метка. Используется в Java GUI / Service Navigator
Необязательное описание

Далее работы ведутся в интерфейсе командной строки сервера HPOM:

Проверить конфигурационный файл

[root@hpom OV]# cd /opt/OV/OpC/examples/services/
[root@hpom services]# opcservice -check ./test.xml
The file ./test.xml is OK. (SVC10-108)

Зарегистрировать сервис

[root@hpom services]# opcservice -add ./test.xml
Successfully added service file ./test.xml (SVC10-111)

Проверить список сервисов

[root@hpom services]# opcservice -list
Service: general

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

[root@hpom services]# opcservice -assign opc_adm general
Successfully assigned services to operator opc_adm (SVC10-113)

После этого в операторской консоли Java GUI в разделе “Services” должен появиться сервис с меткой “My General Service”.

Первые эксперименты с сервисом

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

Проверка командой opcsvcattr:

[root@hpom ~]# opcsvcattr svc_id=general name=ov_label1 value="Works"
<?xml version='1.0' ?>
<Results>
  <OK/>
</Results>

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

Для активации процесса opccustproc1:

[root@hpom ~]# cd /opt/OV/contrib/OpC/opccustproc/      <1>
[root@hpom opccustproc]# cp ./opccustproc1 /opt/OV/bin/OpC/
[root@hpom opccustproc]# cp ./libopccustproc1.so /opt/OV/lib64/
[root@hpom opccustproc]# ovcreg -add ./opccustproc1.xml <2>
[root@hpom opccustproc]# opcsv -start                   <3>
[root@hpom opccustproc]# opcsv -status                  <4>
...
OMU Custproc 1            opccustproc1     (3984) is running

Скопировать необходимые файлы
Зарегистрировать процесс opccustproc1
Перезапустить HPOM
Проверить процесс opccustproc1

С этого момента, если в сообщении присутствует указание имени сервиса, а поле “Message Type” установлено в значение “service_changes”, значение важности (severity) сообщения будет привязано к статусу сервиса. Для примера, рассмотренного в разделе “Пример развёртывания простой политики“, нужно изменить поля во вкладках “Start Actions → Message” и “End Actions → Message” (секция “Message Defaults”):

Service ID: general
Message type: service_changes

Теперь остановка процесса top на экспериментальном узле вызовет появление сообщения, которое, в свою очередь, изменит статус сервиса.

Создание составного сервиса

HPOM, по своей сути, представляет собой систему управления событиями. Событием же принято считать любое изменение состояния объекта управления в процессе его функционирования. В HPOM, путём настраивания и развёртывания политик на объекты управления, устанавливаются условия фиксирования значимых для управленческой задачи событий. Каждое зафиксированное таким образом событие в системе HPOM воплощается в соответствующее сообщение.

Всего в HPOM используются 5 степеней важности (значимости) событий/сообщений:

Normal
Warning
Minor
Major
Critical

Использование навигатора сервисов, как инструмента оптимизации управленческого процесса, имеет смысл только если сервисы будут иметь некую иерархическую структуру. Только в этом случае, покрытие объектов функцией управления будет по-настоящему впечетляющим. Как отмечалось ранее, в подобных иерархиях, как правило, нижние уровни сервисов привязаны к реальным событиям/сообщениям; статус же сервисов старших уровней вычисляется по состоянию сервисов нижнего уровня.

Определение статуса составного сервиса выполняется в два этапа:

По правилам распространения (Propogation Rules)
По правилам калькуляции (Calculation Rules)

Сам процесс распространения – это “продвижение” статуса дочернего сервиса на один уровень вверх по иерархии сервисов (не путать со степенями значимости). А вот правила этого распространения, в свою очередь, определяют как должна измениться степень значимости события при продвижении статуса по иерархии сервисов. В HPOM могут применяться следующие правила распространения статуса (состояния):

increase: поднимает степень значимости на один пункт
unchanged: оставляет степень значимсоти без изменений
decrease: понижает степень значимости на один пункт
ignore: игнорирует состояние сервиса; продвижение не выполняется
set to: строго устанавливает степень значимости статуса

По умолчанию, статус “продвигается” наверх с увеличением степени важности. Т.е. если у дочернего сервиса был статус “Warning”, то родительский примет его с увеличением степени значимости на один пункт, т.е. для калькуляции будет использоваться статус “Minor”. Статус “Normal” – всегда игнорируется, т.е. увеличения степени значимости при распространении статуса не происходит.

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

Most Critical: Самая высокая степень из списка вводных статусов и будет статусом сервиса. Частный случай правила “Single Threshold” (см. ниже)
Single Threshold: Выбирается самая высокая степень из тех вводных статусов, что прошли установленное пороговое значение. Частный случай правила “Multiple Thresholds” (см. ниже)
Multiple Thresholds: В отличие от предыдущего правила, где пороговое значение одинаково для всех степеней значимости, здесь для каждой из них назначается своё значение.

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

Замечание

Более развёрнуто о правилах определения статуса – в руководстве “Java GUI Operator’s Guide”

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

Проектирование сервиса

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

Составной сервис general:
- Сервис top. Связан с состоянием прикладного процесса top на каком нибудь из UNIX узлов
- Сервис telephony. Связан с состоянием сервиса Telephony на каком нибудь из Windows узлов
- Сервис telnet. Связан с состоянием сервиса Telnet на каком нибудь из Windows узлов
Сервисы нижнего уровня распространяют свои статусы по следующим правилам:
- top → increase
- telephony → unchanged
- telephony → decrease
Калькуляция выполняется по самому простому правилу: Most Critical

Таким образом, получается следующий файл конфигурации для сервиса general:

<?xml version="1.0" encoding="UTF-8"?>
<Services
  xmlns="http://www.hp.com/OV/opcsvc"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.hp.com/OV/opcsvc
  /etc/opt/OV/share/conf/OpC/mgmt_sv/dtds/service.xsd">

    <Service>
      <Name>general</Name>
      <Label>My General Service</Label>
      <Description>Service prototype</Description>
      <CalcRuleRef>most_critical</CalcRuleRef>
      <Source>
        <Composition/>
        <ServiceRef>top</ServiceRef>
        <PropRuleRef>increase</PropRuleRef>
      </Source>
      <Source>
        <Composition/>
        <ServiceRef>telephony</ServiceRef>
        <PropRuleRef>unchanged</PropRuleRef>
      </Source>
      <Source>
        <Composition/>
        <ServiceRef>telnet</ServiceRef>
        <PropRuleRef>decrease</PropRuleRef>
      </Source>
    </Service>

    <Service>
      <Name>top</Name>
      <Label>My Top Service</Label>
      <Description>Subservice prototype</Description>
    </Service>

    <Service>
      <Name>telephony</Name>
      <Label>My Telephony Service</Label>
      <Description>Subservice prototype</Description>
    </Service>

    <Service>
      <Name>telnet</Name>
      <Label>My Telnet Service</Label>
      <Description>Subservice prototype</Description>
    </Service>

    <PropRule>
      <Name>increase</Name>
      <Prop>
        <Increase>1</Increase>
      </Prop>
    </PropRule>
    <PropRule>
      <Name>unchanged</Name>
      <Prop>
        <Unchanged/>
      </Prop>
    </PropRule>
    <PropRule>
      <Name>decrease</Name>
      <Prop>
        <Decrease>1</Decrease>
      </Prop>
    </PropRule>

    <CalcRule>
      <Name>most_critical</Name>
      <CalcMostCritical/>
    </CalcRule>

</Services>

Установка сервиса

Регистрация сервиса:

[root@hpom services]# opcservice -check test2.xml        <1>
[root@hpom services]# opcservice -list                   <2>
Service: general
[root@hpom services]# opcservice -remove general         <3>
[root@hpom services]# opcservice -add test2.xml          <4>
[root@hpom services]# opcservice -list                   <2>
[root@hpom services]# opcservice -assign opc_adm general <5>

Проверка файла
Вывод списка сервисов
Удаление предыдущего сервиса general
Регистрация сервиса
Назначение сервиса пользователю

Остаётся добавить две политики наблюдения за состоянием сервисов Windows с привязкой их к соответствующим сервисам.