Главная System Center, Новое System Center Operations Manager 2007 – Health Model
  • System Center Operations Manager 2007 – Health Model

    Данная статья продолжает цикл статей о OpsMgr 2007 R2, и в этот раз речь пойдет о модели здоровья. Кроме описанного ранее моделирования служб, OpsMgr использует еще одну модель – модель «здоровья» (Health Model). Каждый объект в системе OpsMgr имеет показатель «здоровья». Здоровье объекта определяется шестью состояниями: здоров (healthy ), предупреждение (warning ), критический (critical ), не проверяется (unmonitored ), в режиме обслуживания (Maintenance mode ) и «недоступен» ().

    Мониторы (monitors)

    Для воздействия на состояние объекта в рамках OpsMgr существуют мониторы (monitors), которые делятся на несколько видов: юнит-мониторы, Aggregate rollup-мониторы и Dependency rollup-мониторы.

    Модель здоровья строится по принципу «дерева», при этом нижележащие мониторы передают своё состояние по определенным правилам вышележащим.

    При инициализации любого объекта в системе ему присваивается статус Health, если данный объект имеет хотя бы один активный монитор, или Unmonitored, если для объекта не настроено ни одного монитора (их нет вообще или они отключены). После этого, по результатам проверки состояния объекта, выставляется состояние предупреждение (warning) или критический (critical). В случае если агент, который занимается обслуживание данного объекта, не доступен, объект помечается как «недоступный», при этом отображается последнее известное состояние объекта.

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

    Монитор может иметь как все три состояния (Health-Warning-Critical), так и какую-то пару состояний (Health-Warning или Health-Critical). Это определяется на этапе создания монитора.

    Unit-monitor

    Unit-монитор – это процесс, производящий некие действия, результаты которых оцениваются, и по этой оценке выставляется уровень здоровья данного монитора – Health, Warning или Critical. Unit-монитор обычно состоит из трех частей:

    1. Планировщик, который запускает монитор по определенному расписанию. Этого шага может не быть, если наблюдаемый объект поддерживает подписку на события (н-р журнал Windows или WMI Events)
    2. Процесс, получающий данные о проверяемом объекте
    3. Условие, которое по данным определяет состояние объекта

    Примером Unit-монитора могут служить:

    — выполнение WMI-запроса, и проверка состояния службы Windows

    — появление события с определенным ID и источником в журнале Windows

    — результат выполнения скрипта (vbs или powershell)

    — наличие строки в текстовом файле

    Т.к. unit-монитор обычно запускается по расписанию, перерасчет состояния происходит через промежутки времени, заданные в расписании. Если монитор настроен на запуск раз в 15 минут, и срабатывает условие, которое переводит его в состояние Critical, то обратно он вернутся только через 15 минут, даже если в реальности условие перехода наступило через 2 минуты. Исключением может служить, например, монитор, работающий с событиями в журнале Windows – он реагирует сразу, как только событие имело место.

    Пакеты управления содержат массу готовых и настроенных unit-мониторов, но администратор может добавлять их из шаблонов, идущих в комплекте с OpsMgr, тем самым влияя на модель здоровья. В OpsMgr существует огромное количество шаблонов unit-мониторов, они будут рассмотрены позже. Чаще всего используются мониторы, реагирующие на события в журнале Windows, и мониторы на базе скриптов. Кроме этого администраторы могут создавать свои unit-мониторы любой сложности с помощью Authoring Console.

    Aggregate rollup monitor

    В отличие от unit-мониторов, aggregate-мониторы не выполняют никаких действий, а лишь собирают состояния других мониторов, расположенных ниже в дереве здоровья, для выставления общей оценки объекта по какому-либо критерию. У любого объекта есть как минимум 4 aggregate-монитора: Availability, Configuration, Performance и Security. Например, для класса Windows Server 2003 Operating System определен еще один дополнительный aggregate-монитор Core Windows Services Rollup, определяющий общее состояние служб:

    Dependency rollup monitor

    Dependency-монитор также не выполняет никаких действий, а лишь передает сведения о здоровье другого объекта, от которого зависит проверяемый объект. Dependency-мониторы крайне тесно связаны с понятием «отношения», рассмотренным ранее. Думаю лучше пояснить работу Dependency-монитора на примере. Когда я описывал отношения, одним из примеров было отношение между лесом AD и сайтом. С точки зрения «здоровья» логично, что если что-то не так с сайтом, то это также должно отобразиться и на всем лесе. Dependency-монитор как раз и передает состояние здоровья сайта в схему здоровья леса:

    Для dependency-монитора мы можем выбрать в качестве ссылки те мониторы, которые нацелены на объект класса, с которым у исходного объекта есть отношения. На рисунке представлены возможные варианты настройки dependency-монитора для леса AD:

    Политики сбора здоровья (Health Rollup Policy)

    Для Dependency rollup и Aggregate rollup можно определить «политики сбора здоровья» — правила, по которым будет передаваться состояние ниже лежащих объектов в дереве.

    Для Aggregate rollup monitor можно лишь задать одно из двух значений: по худшему состоянию (worst state) или по лучшему (best state). Рисунок, который поясняет работу этой политики, размещен прямо в консоли:

    В качестве примера использования правила сбора по лучшему состоянию можно привести кластер – кластер считается «живым», пока хотя бы одна нода находится в рабочем состоянии.

    Для Dependency rollup monitor настроек гораздо больше. Кроме сбора по худшему или лучшему состоянию, доступен также сбор худшего значение от определенного процента объектов:

    Тут может возникнуть вопрос – откуда в Dependency-мониторе может взяться несколько объектов, если мы делаем ссылку на один монитор? Ответ достаточно прост: как уже говорилось выше, Dependency-мониторы строятся на базе отношений. И каждый объект может иметь отношения как с одним, так и с несколькими объектам. Например, возвращаясь к примеру с лесом и сайтом, мы имеем следующую ситуацию: у нас определены Containment-отношения между классами AD Forest и AD Site. Исходя из этого, мы можем для класса AD Forest создать Dependency-монитор, который ссылается на монитор Availability класса AD Site. Но в системе в одном лесе может быть несколько сайтов, поэтому при оценке здоровья будет использоваться состояние всех сайтов в данном лесе.

    Кроме правила определения состояния «лучший-худший», Dependency-монитор позволяет настроить реакцию на случаи, когда монитор, на который идеи ссылка, не доступен (unmonitored), и когда зависимый объект находится в состоянии обслуживания (Maintenance mode). Для каждого из состояний можно игнорировать этот монитор (Ignore), переводить монитор в состояние Warning или переводить монитор в состояние Critical.

    Health Explorer

    Главным инструментом для работы с моделью здоровья служит Health Explorer. В этой консоли сведены все мониторы для объекта. Health Explorer можно вызвать для любого объекта в системе. На рисунке представлен скриншот Health Explorer, вызванный для объекта класса AD Forest:

    Корневой элемент в дереве — Entity Health, это и есть общее состояние объекта. Все остальные элементы строятся по шаблону «Имя_правила – имя_объекта (класс_объекта) ». Например, элемент «Logical Disk Availability – C: (Windows Server 2003 Logical Disk) » следует понимать как монитор «Logical Disk Availability», который проверяет здоровье объекта с именем «C:», принадлежащий к классу Windows Server 2003 Logical Disk.

    Кроме этого, из Health Explorer можно посмотреть свойства любого монитора. Пример свойств Dependency-монитора AD Forest Availability Health Rollup Monitor:

    Как видно, данный монитор устанавливает зависимость от монитора Availability класса AD Site, а также имеет политику сбора, согласно которой монитор переходит в худшее состояние из 40% лучших сайтов J.

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

    Сброс состояния (Reset Health)

    В идеальных условиях, переход между состояниями монитора (здесь и далее речь идет о unit-мониторах) должен происходить после выполнения неких проверочных действий. Но мир ИТ далек от идеалов, и всегда находится момент, когда необходимо отойти от идеалов, и сделать всё через «запасный выход». Такая же ситуация может сложиться и с монитором, ведь легко можно представить, когда у нас есть критерий перехода монитора в состояние Critical, но нет правила, по которому мы могли бы вычислить, что с объектом уже всё в порядке. Часто такое поведение встречает, когда «здоровье» вычисляет по событиям в журнале операционной системы: мы имеет событие, которое говорит о том, что с сервером что-то случилось, а вот события, говорящее о том, что работоспособность восстановлена – нет.

    Для выхода из таких ситуаций монитор может быть создан с ручным сбросом (Manual Reset) и со сбросом по времени (Time Reset). Монитор с ручным сбросом может переходить в состояние Critical или Warning, но никогда автоматически не вернется в состояние Health. Для сброса состояния таких мониторов необходимо открыть Health Explorer, выбрать нужный монитор и нажать кнопку Reset Health. После некоторого времени, состояние монитора будет сброшено в Health. Также состояние можно сбрасывать с помощью скриптов на Powershell (готовых командлетов для этого нет) или с помощью сторонних программ (например GreenMachine).

    Мониторы со сбросом по времени работают следующим образом. В свойствах монитора указывается, через какое время состояние объекта будет сброшено в Health. Когда монитор переходит в состояние Critical (или Warning), запускается отчет. По достижении указанного промежутка времени, монитор сбрасывается в Health. Например, вот так будет меняться состояние монитора, настроенного на событие в журнале безопасности и сброс в Healh через 2 минуты:

    Обратите внимание, что в последнем случае сброс произошел через 4 минуты. Это связано с тем, что при появлении события, отчет зачинается заново.

    Быстро определить, каким образом происходит возврат монитора в Health можно в свойствах монитора: на вкладке Health в столбце «Monitor Condition» обычно описан тип возврата.

    Кроме сброса состояния, существует также возможность вычислить состояние на данный момент (recalculate state). При этом предпринимается попытка запустить монитор, и получить текущие данные о состоянии объекта. Но в реальной жизни это используется редко, т.к. далеко не все мониторы поддерживают пересчет состояния, и определить, поддерживает ли монитор пересчет состояния или нет, стандартными средствами нельзя.

    «Залипание» состояния

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

    Как видно, все unit-мониторы находятся в состоянии Health, а вот rollup-монитор в Critical. Reset Health здесь не поможет, и одно из средств – установить объект-хозяин в Maintenance Mode на минимальное время (5 минут). При выходе из Maintenance Mode происходит сброс всех мониторов объекта в Health.

    Заключение

    В данной статье мы кратко рассмотрели модель здоровья в OpsMgr. На поведение мониторов влияет несколько других компонентов OpsMgr, такие как упомянутый Maintenance Mode, а также overrides. Также при создании собственных мониторов важным является понимание нацеливания мониторов (targeting). Обо всем этом вы можете прочитать в сопроводительной документации к продукту, или позже в моих статьях.

    В следующей статье речь пойдет о пакетах управления (management packs) и компонентах, входящих в них.

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

    OpsMgr.ru

Комментарии

  1. Раздел «Политики сбора сдоровья», последний абзац:

    «...Dependency-монитор позволяет настроить реакцию на случаи, когда монитор, на который идеи ссылка, не доступен (unmonitored)»

  2. Спасибо, поправил. Как говорится, «на Ворд надейся...» 🙂

  3. Недавно выскочили 2 alert-RMS unavailable -что можно сделать в этом случае,

    и еще один-в БД OPSDB осталось очень мало места, а на диске, где эта opsdb

    120 gb свободного места-что бы это значило?

    Антон, а можно узнать-как вы планируете построить цикл статей? Чего еще от Вас ждать:))? мне очень нравится пока, так как Вы объясняете всю суть?

  4. 1. Приверить журнал Operations Manager на RMS на предмет ошибок

    2. Увеличить размер БД через SQL management Studio

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

  5. По-поводу залипших мониторов, кроме мэинтененс еще помогает ресет(Reset Health) самого нижнего в иерархии роллап-монитора.

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

Я не робот.