Discovery для SNMP в Operation Manager 2007

При создании класса SNMP Network Device, разработчики Microsoft обделили нас многим нужным функционалом — Discovery, монитор с 3мя состояними и пр.
Из-за этого приходится придумыватьвсякие извращения. Н-р чтобы содавать правила для определнного типа устройств (как я делал это ранее для бесперебойников), приходилось:
1. Создавать группу
2. Ручками вносить в эту группу определнные устройства
3. Создавать монитор или правило выключенным
4. Делать Override созданному правилу или монитору для группы, чтобы включить правило.
 
Согласитесь, не совсем прозрачная конструкция. А всё потому, что целью (Target) можно указывать только классы. В нашем случае класс всегда один — SNMP Network Device. 
Кроме этого, группа получается статичной — при появлении нового устройства его нужно добавлять ручками. При большом кол-ве устройств это мягко скажем проблематично.
В SCOM 2007 мы имеем возможность создавать собственные классы. Но для каждого класса необходимо ограничить его членов. Для этого в SCOM 2007 существует Discovery. Если для агнетов это не проблема — у нас в наличии Discovery на базе реестра или WMI запросов, то вот с SNMP у нас таких инструментов нет.
Но мир, как говорится, не без добрых людей. Рафаэль Бурри (Rafael Burri) создал SNMP Discovery Provider for OpsMgr 2007, что позволяет нам строить собственные классы на базе SNMP Probe. К некоторому сожалению, сделан этот провайдер в виде запечатанного (sealed) MP, но есть подробная документация.
Данная разработка быстро получила развитие, и в скоре Скот Винтиннер (Scot Vintinner), а затем и сам Рафаель создали MP на основе этого провайдера.
 
В кратце, провайдер позволяет получить значение из устройства по указанному OID, проанализировать его, и по результату анализа добавить в тот или иной класс. Использование классов, в свою очередь, позволяет сильно упростить настройку мониторов и правил.
Реклама

Мониторинг ИБП APC в SCOM 2007. Часть 3я.

 
 
В предыдущих частях мы настроили получение SNMP-трапов на сервере, создали тестовое правило в SCOM2007, изучили MIB-дерево бесперебойников. Самое время применить полученные знания на практике.
 
Начнем с трапов, т.к. в первой части мы уже настроили одно тестовое правило для обработки трапов. Если правило до сих пор включено, вы должны получать кучу событий вот такого вида:
image
 
Это алерт, который генерируется из правила. Правило, в свою очередь, реагирует на трап, который приходит от бесперебойника при возникновении любого события, т.к. мы настроили правило на получение трапов с любым OID. Если таких сообщений приходит много (н-р как у меня), вы может сразу строить правила (Rules) и мониторы (Monitors), используя данные из алерта.
 
Для этого откройте алерт (двойным щелчком мыши), и перейдите на вкладку "Alert Context":
image
Нас интересует часть, выделенная красным. Эти данные получает SCOM 2007 из трапа. Самые важные данные — 3 и 4я строка.
В третьей строке вы видите понятное описание трапа, как его передает сам бесперебойник, в четвертой — OID трапа (см. часть2, описание трапов в MIB-дереве). Используя кнопки "Previous" и "Next" вы можете перемещаться между алертами и смотреть их описание.
Для примера возьмем алерт, который генерируется после прохождения самотестирования. Это одиночное событие, не влияющее на Health State (по русски — состояние системы) поэтому нужно только оповещать оператора об этом событии. "Alert Context" этого алерта выглядит следующим образом:
image
 

Правила (Rules)

Для оповещения в SCOM2007 служат алерты. Их можно генерить на основе правил (Rules) или мониторов (Monitors). Т.к. мониторы больше служат для отслеживания Health State, то в данном случае более логичным выглядит создание алерта на базе правила (Rule) — самотестирование никак не влияет на состояние бесперебойника.
Для этого необходимо (во многом шаги повторяют то, что мы делали в Части 1):
Перейти в консоли SCOM 2007 в секцию Authoring, выбрать "Authoring\Managment Pack Objects\Rules", нажать правой кнопкой мыши и в контекстном меню выбрать "Create a new rule…" image image
В мастере выбрать типа правила (Rule Type) "Alert Generating Rules\Event Based\Snm Trap (Alert)", а также выбрать MP (Managment Pack), отличный от Default, и нажать Next. image
На этапе "General" необходимо указать:
— "Rule Name"  = UPS: Self-test passed
— "Description" = ИБП успешно прошел самотестирование.
— "Rule Category" = Alert
— "Rule target" = SNMP Network Device (при выборе не забудьте установить переключатель в положение "View all targets")
— "Rule is enabled" = false (снять галочку)

Про последние 2 параметра написано в блоге G14, и упоминалось в Части 1.

image
На этапе "SNMP Trap Provider" мы можем оставить опцию Use discovery community string включенной, если строка трапа совпадает со строкой поиска, или ввести строку самостоятельно (Use custim community string). Замечу, что строка должна быть такой, которую мы вводили на этапе настройки трапа (см. Часть 1).

Далее самое главное — указание OID. Его нам необходимо скопировать из Alert Context (см. выше). В нашем случае — OID = 1.3.6.1.4.1.318.0.10
В MIB-дереве он называется "upsDiagnosticPassed" и имеет вот такое описание:
image 

Замечание: SCOM 2007 хранит OID без ведущей точки. MIB-браузеры выдают OID с ведущей точкой. Обратите на это внимание.

image
На этапе "Configure Alerts" необходимо задать параметры:
— "Alert Name" = оставить без изменения (хотя можете и указать отличное от имени правила, но мне кажется так не очень удобно).
— "Alert description" = Можно задать любое значение. Также можно воспользоваться переменными подстановки. Кроме того, можно получить доступ к данным самого трапа (к той таблице, что мы видели в Alert Context). Для этого в поле описания надо добавить вот такую переменную: "$Data/Context/SnmpVarBinds/SnmpVarBind[#]/Value$", где # — это номер строки в таблице Alert Context, счет начинается с единицы:
image
Н-р если мы в описании напишем:
"Время с запуска UPS: $Data/Context/SnmpVarBinds/SnmpVarBind[5]/Value$",
то в консоли SCOM 2007 при возникновении алерта увидим вот такое описание:
"Время с запуска UPS: 57669040"
 
Далее по настройкам:
— "Priority" = Low
— "Severity" = Information
Замечание: для перевода строки в поле описания используйте сочетание клавишь Ctrl-Enter. В случае если вы просто нажмете Enter произойдет cоздание правила (сработает кнопка по умолчанию — "Create")
После указание всех параметров нажимаем Create, и ждем несколько секунд. Наше правило должно появится в списке в группе "SNMP Network Device". На время созданий правил советую ограничить область просмотра правил (Scope), дабы не перегружать консоль лишней информацией. Для этого в верхнем правом углу консоли нажать ссылку "Change Scope…" и выбрать "SNMP Network Device".
image
Т.к. мы создали правило выключенным, нам его надо включить. Включить нам его надо только для группы, которую мы создали в Части 1 — "APC UPS Devices".
Для этого жмем на созданном правиле правой кнопкой мыши, и в контекстном меню выбираем "Overrides\Overide the rule\For a group…" и выбираем группу "APC UPS Devices".
В появившемся диалоге отмечаем в столбце "Override" строку с параметром (Parameter Name) "Enabled", и меняем "Override Setting" на "true".
image image
Всё, на этом создание правила закончено. Вы можете зайти в веб-интерфейс UPS-а и форсировать самотестирование. В результате вы должны увидеть 2 алерта — один "Test APC Rule" с важностью Critical, второе — "UPS: Self-test passed" с важностью Information:
image
 

Мониторы (Monitors)

Следующим этапом будет создание алертов, которые вызваны изменение состояния бесперебойника. Изменение состояние может быть вызвано любым фактором, как внешним, так и внутренним. SCOM 2007 поддерживает 3 состояния: Healthy (всё хорошо), Warning и Critical (всё плохо). Для отслеживания статуса в SCOM 2007 служит Health State. Собственно меняют этот самый статус мониторы (Monitors). Но есть один нюанс — для SNMP доступен монитор, позволяющийся менять только 2 состояния. Логично предположить, что то будут пары состояния Healthy — Warning и Healthy — Critical (в случае, если вам всё-таки потребуется монитор с 3мя состояниями, придется использовать скрипты, но это большая тема для отдельной статьи).
Самый логичный (и легко воспроизводимый на практике) монитор с двумя состояниями для бесперебойников — это состояние "есть входящее питание"/"нет входящего питания". Давайте попробуем реализовать такой монитор.
 
Для воспроизведения данной ситуации достаточно вынуть питающий кабель из бесперебойника. В результате, при включенном тестовом правиле, вы должны получить алерт со следующим Alert Context:
image
Когда вы включите питающий кабель обратно, вы получите алерт со следующим Alert Context:
image
Замечание: для разных UPS сообщение с OID "1.3.6.1.4.1.318.2.3.3.0" (3я строка) может отличаться. В примере — для APC 15kV 3Phase.
 
Как видно, эти 2 события образуют пару. Первое событие переводит бесперебойник в логическое состояние Warning (или Critical, в зависимости от вашей инфраструктуры), второе событие возвращает бесперебойник в логическое состояние Healthy. Этих данных нам хватит, чтобы создать монитор (Monitor) со сменами состояний. Для этого нам надо:.
Перейти в консоли SCOM 2007 в секцию Authoring, выбрать "Authoring\Managment Pack Objects\Monitors", нажать правой кнопкой мыши и в контекстном меню выбрать "Create a monitor\Unit monitor" image
На этапе "Monitor Type" выбрать тип "SNMP\Trap Based Detection\Simple Trap Detection\Event Monitor — Single Event ans Single Event", а также указать MP (Management Pack) отличный от Default. image
На этапе General вводим:
— "Name" = "UPS: Input Power State"
— "Description" = любое понтяное описание
— "Monitor target" = SNMP Network Device
— "Parent monitor" = "Availability"
— "Monitor is enabled "= false (галочка снята)
image
На этапе "First SnmpTrapProvider":
— "Use discovery community string" (если у вас строка опроса не отличается от строки трапа)
— "Object Identifier" = 1.3.6.1.4.1.318.0.5
image
Этап "Build First Expression" используется для дополнительного анализа трапа, т.к. очень часто бывает так, что трапы передаются под одним OID, а в информации о трапе приходит состояние объекта. Так н-р работают трапы VMWare и некоторых производителей аппаратного обеспечения (серверов).
В нашем случае анализ не нужен, но (привет разработчикам) без создания хотя бы одного условия мастер не пустит нас дальше. В связи с этм необходимо создать условие:
1. Нажимаем на кнопку Insert
2. В столбце Parameter Name вводим "/DataItem/SnmpVarBinds/SnmpVarBind[4]/Value"
3. В столбце Operator выбираем "Equals"
4. В столбце Value вводим "1.3.6.1.4.1.318.0.5"
Т.е. фактическм мы еще раз проверили то, что входящий OID = "1.3.6.1.4.1.318.0.5". Напомню, что SnmpVarBind[4] означает 4ю строку в "Alert Context"
image
На этапе "Second SnmpTrapProvider" указываем:
— "Use discovery community string" (если у вас строка опроса не отличается от строки трапа)
— "Object Identifier" = 1.3.6.1.4.1.318.0.9
image
На этапе "Build Second Expression" делаем по аналогии с первым:
1. Нажимаем на кнопку Insert
2. В столбце Parameter Name вводим "/DataItem/SnmpVarBinds/SnmpVarBind[4]/Value"
3. В столбце Operator выбираем "Equals"
4. В столбце Value вводим "1.3.6.1.4.1.318.0.9"
image
На этапе "Configure Health" мы настраиваем состояние нашего бесперебойника. Как я и говорил, для SNMP в SCOM2007 доступно только два состояния. В соответствии с этим устанавливаем:
Для "First Event Raised":
"Operation State" = "UPS on battery"
"Health State" = "Warning"
Для "Second Event Raised":
"Operation State" = "UPS no longer on battery"
"Health State" = "Healthy"

Если для вашего окружение переход бесперебойника на питание от батарей является критичным событием — поставьте в "First Event Raised" "Health State" = "Critical"

image
На этапе "Configure Alerts" можно включить оповещение при переходе монитора в какое-либо состояние. В данном случае это очень полезно — администратору в подавляющем числе случаев полезно знать, что пропало входное питание на бесперебойнике.
Для включения алерта необходимо:
1. Отметить галку "Generate alerts for this monitor"
2. Выбрать в поле "Generate alert when" в зависимости от того, в какое состояние вы настроили перевод монитора на предыдущем шаге — в Critical или Warning. В нашем примере нужно выбрать "The monitor is in a warinng heathy state"
3. Для данного правила рекомендую снять галку "Automatically resolve the alert when the monitors returns to a healthy state". Т.к. питание может пропадать на незначительное время, а знать об этом событии всегда полезно.
4. Alert Name установить в "UPS: Input Power Lost, switch to battery"
5. Severity (важность) лучше установить в соответствии с состоянием монитора — "Match monitor’s health"
6. В Alert Description добавить любую необходимую информацию. Не забыв, что можно добавить сведения из переменных и Alert Context
image
   
После создания монитора, не забудьте включить его с помощью Overrides.
 
В результате, Health State бесперебойника будет меняться на Warning при пропадании входного питания, и в консоли будет появляться алерт.
Но тут есть нюанс. В случае, когда мониторинг производится с помощью агента (на сервере, рабочей станции — не важно), то агент отвечает за гарантированную доставку событий на сервер SCOM 2007. В случае же с SNMP, событие может быть зарегестрированно только в момент его появления. Т.е. н-р если в момент отправки трапа не было связи между устройством и сервером-приемником трапов, данное событие останется "не замеченным". Что касается предыдущего примера, то в нем такая ситуация очень вероятна, т.к. обычно бесперебойник питает свитчи, через которые и проходят все пакеты от этого бесперебойника до сервера-приемника. При этом ситуация, когда после полного разряда батарей и отключения бесперебойника, будут обесточены и свитчи, крайне вероятна. А при включении питания и включении бесперебойника, будет сгенерирован трап, но он не сможет дойти до сервера, т.к. свитчам требуется время на включение. В связи с этим может возникнуть ситуация, когда состояние устройства "зависнет" в режиме "Warning" и не вернется в "Healthy", т.к. не получит второго трапа.
В этом случае нужно будет вручную, через Heath Explorer, сбросить состояние устройства.
 
В 4ой части пойдет речь о том, как собирать статистику по SNMP и сохранять её в SCOM 2007.

Memory Limits for Windows Releases

Найдено на сайте MS. Крайне полезная ссылка.

Мониторинг ИБП APC в SCOM 2007. Часть 2я.

 

"Между первой и второй перерывчик не большой". К сожалению, не всегда получается так, как мы хотим. К бесперебойникам вот смог вернуться только сейчас. За это время произошло многое, в том числе и по теме — у меня в появился доступ к серьезной 3х фазной модели APC — Smart-RT VT 15k.

Эта часть меньше будет посвещена SCOM, а в основном будет посвещена разбору MIB-файлов и тому, что и как передают бесперебойники через SNMP. Если первая часть была сплошной практикой, 2я скорее получится сплошной теорией.

Первое, с чего хочется начать — рассказать о том, что вообще можно передавать через SNMP (буду рассматривать только версии, поддерживаемые в SCOM 2007 — SNMP v1 и v2. Бесперебойники APC поддерживают также и SNMPv3). Устройство, поддерживающее SNMP, работает в 2х режимах — "приемника" и "передатчика". В первом случае некто в сети запрашивает у устройства информацию примерно в таком виде "устройство, вот тебе кодовое слово, скажи-ка, а какое значение у тебя сожержится по вот этому OID?". На что устройство может ответить н-р "287" или "ОК".

Ключевые понятия SNMP:
OIDObject Identifier. Уникальное индентификатор объекта в устройстве, содержащее значение. В чем-то сродни HTTP-строке — набирая нужный OID вы получаете нужную информацию.
Community String — то самое "кодовое слово", по которому устройство распознает, пользователь с каким уровнем доступа к нему обращается. Общепринятыми являются 2 значения — public (уровень доступа обычно только чтение) и private (кроме чтения может еще и записывать данные в устройство)
MIBManagement Information Base, полная структура всех OID устройства, с описанием типов возвращаемых значений, понятных строковых эквивалентов и пр.
SNMP Probe — значение, которое устройство отдает по запросу от какого-либо устройства в сети (значение также сопровождается командой — get, set и др.).
SNMP Trap — сообщение, отправляемое самим устройством на заранее заданный адрес в сети. Генерируется каким-либо событием на устройстве.
 
Данные, передаваемые бесперебойниками по SNMP, описаны в RFC 1628. В APC полностью реализовали данные рекомендации, поэтому всегда можно обратиться с первоисточнику для получения дополнительных данных.
 
Итак, вернемся к мониторингу. Для того, чтобы понять,где брать какие данные, нам понадобиться изучить MIB-файлы, которые идут с бесперебойниками. MIB-файл можно найти на компакт-диске от модуля управления, называется он "powernet386.mib".
Структура MIB-файлов не удобна для изучения в текстовых редакторах, к тому же существует большое кол-во MIB-browser-ов, которые в наглдяной древовидной форме показывают их содержимое, а также могут выполнять команды протокола SNMP.
В кач-ве MIB-браузера я использовал iReasoning MIB Browser Personal Edition, он полностью удовлетворяет всем потребностям при изучении MIB-структуры, при этом являясь бесплатным для персонального использования.
 

SNMP Probe

Начнем с SNMP-Probe-ов. Как уже говорилось, probe служит для получения информации от устройств по запросу. Для этого в протоколе SNMP есть следующие команды:
Get — получение конретного значения по указаному OID. Основной режим работы.
Get Next — получение значения со следующим (от указанного) по MIB-дереву OID.
Walk — получение значений всего MIB-дерева
Get Subtree — получение значений всех OID по MIB-дереву, расположенных ниже указаного OID
 
Для иследования очень полезна команда Walk, которая позволяет быстро вывести значения всех OID устройства, значащиеся в MIB-файле, и Get Subtree. 
 
В SNMP сущесвует 2 способа хранить информацию: в виде одиночных значений и в виде таблицы.
Для одиночных значений всё просто — мы задаем OID, и устройство выдает по этому OID какое-то значение.
Для табличных всё несколько сложнее. В таблице SNMP разные значения OID имеют:
— вся таблица
— запись таблицы (не путать со сторокой, запись таблицы — это просто описание набора столбцов)
— каждый столбец таблицы
— каждая ячейка таблицы
 
Для использования в SCOM2007 пригодны только одиночные значения и значения ячеек таблицы.
 
Первое, что нам надо сделать — загрузить MIB-файл. В iReasoning  заходим в меню File,  затем выбираем пункт Load MiBs. В появившемся диалоге находим файл powernet386.mib и жмем Open.

image

После этого в левом окне, в MIB-дереве должен появиться новый корневой раздел с именем PowerNet-MIB.iso.org.dod.internet.private.enterprises.apc. Далее в тексте при указании веток и листьев в MIB-дереве я буду использовать данный корневой раздел в кач-ве корня при указании в "плоском" нотации.
Для мониторинга нас в основном будет интересовать две ветки:
\products\hardware\ups
и
\SNMPv1 Traps

Первая содежит в себе практически все OID, которые нужны для мониторинга состояния UPS, вторая — все трапы с "понятным" описанием.

imageimage

Краткое описние ветки \products\hardware\ups:
Ветка содержит в себе OID, возвращающие состояние или значения всех параметров бесперебойника. Ветка имеет подветки для каждого из компонентов системы:

  • upsIdent —  параметры идентификации устройства (имя, версия прошивки и пр.)
  • upsBattery — параметры батарей (статус, прогнозируемое время работы и пр. )
  • upsInput — входные параметры (напряжение, кол-во фаз, частота)
  • upsOuput — выходные параметры (напряжение, кол-во фаз, нагрзука и пр.)
  • upsConfig — параметры настроек UPS-а (все настройки, доступные для бесперебойников APC)
  • upsControl — доп. параметры настройки, больше относящие к состоянию UPS
  • upsTest — настройки само-тестирования
  • upsComm — статус соединения
  • upsPhase — параметры по всем фазам бесперебойника
  • upsSyncCtrlGroup — настройки группировки устройств (честно говоря не разбирался)
  • upsState — флаги статуса устройства
  • upsOutletGroups — так и осталась для меня загадкой.
  • upsDiagnostics — данные OID получают некие диагностически данные.
image

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

image

Из MIB-браузера можно сразу же получать реальные значения с SNMP-устройств. Для этого необходимо вверху, в поле "Address", ввести IP-адрес устройства (по умолчанию iReasoning используте строку "public" для получения информации и "private" для установки значений. Если у Вас устройство настроено по другому, нажмите кнопку "Advanced…" рядом с полем "Address", и введите нужные значения)

image

После этого можно использовать панель команд (слева от поля Address) для получения значений конкретных MIB. Н-р в MIB-дереве выберите лист \products\hardware\ups\upsIndent\upsIdentBasic\upsIdentBasicModel\, в панели команд из выпадающего списка "Operations:" выбрети "Get" и нажмите "Go". В центральной части вы должны увидеть таблицу с одной строкой:
image
Обратите внимание, что после того, как Вы выбрали лист, в панели команд в окне "OID" появился реальный OID этого листа, вместо псевдонима (Name), отображенного в столбце "Name/OID".

image

Для получения значений таблиц крайне удобна команда Get Subtree. Она позволяет узнать реальные OID каждой ячейки. Для этого надо необходимо выбрать лист табличного типа, в панели команд выбрать операции "Get Subtree", и нажать "Go".
В результате Вы получите ряд значений. На рисунке представлена часть вывода данной команды, вполненной на листе \products\hardware\ups\upsPhase\upsPhaseInput\upsPhaseInputPhaseTable.
Т.к. Smart-UPS VT 15 kVA — 3х фазный, мы видим 6ть значения одного и того же параметра. Как понятно из его названия — это входное напряжение на каждой из фаз. Чтобы узнать реальный OID данной ячейки, необходимо просто выбрать строку, и посмотреть в окно OID поля команд. Н-р для ячейки upsPhaseInputVoltage.1.1.1 OID = ".1.3.6.1.4.1.318.1.1.1.9.2.3.1.3.1.1.1", тогда как OID самого листа upsPhaseInputPhaseTable = ".1.3.6.1.4.1.318.1.1.1.9.2.3"

Для сравнение вывода, для этого же листа выберите команду "Table View" и нажмите "Go".

image

Думаю Вы несколько удивились тому, что вместо ожидаемых 3х строк увидели 6. Объяснение кроется в таблице \products\hardware\ups\upsPhase\upsPhaseInput\upsPhaseInputTable — некоторые бесперебойникм отдельно хранят данные по основному входу и по by-pass входу, т.к. на практики эти входы могут запитываться от разных источников.
Какие значения с основного входа, а какие с by-pass, можно узнать, выполнив команду "Get Subtree" на листе upsPhaseInputTable, и найти в таблице значений указанные на рисунке параметры.
В данном примере, 1й — это основной, 2й — by-pass. Эти же номера используются в таблице upsPhaseInputPhaseTable. Значения upsPhaseInputVoltage.1.X.X соотвествуют основному входу, значения upsPhaseInputVoltage.2.Х.Х — by-pass.

image

Следует заметить, что для однофазных UPS лист upsPhaseInputPhaseTable вообще не вернет значений. Вместо указанных таблиц для них необходимо использовать лист \products\hardware\ups\upsInput\upsAdvInput\upsAdvInputLineVoltage

К сожалению понять, какое из значений возвращает этот лист для 3х фазных UPS мне не удалось.

 
 
Вся остальныя работа сводится к поиску нужных листов в MIB-дереве и получению их OID.
Несколько поленых замечаний:
— используйте команду Get Subtree — она возвращает все возможные значения и пишет понятные имена в таблице, что позволяет быстро найти нужные значения.
— выучите комбинации "горячих клавиш" в MIB-браузере
 

SNMP Traps

Если SNMP Probe искать довольно просто — они все имеют понятные имена, то вот с Trap-ами всё обстоит гораздо сложнее.
Загруженное нами MIB-дерево имеет просто набор трапов (см. рис), даже без указания их OID. Для каждого OID нам придется сами его строить. Правило простое:
1. Берем корневой OID (".1.3.6.1.4.1.318")
2. Добавляем ему 0 в конце (получаем ".1.3.6.1.4.1.318.0")
3. Добавляем в конец Specific ID нужного трапа.
 
Значение Specific ID можно узнать, выбрав нужный трап и посмотрев в поле описания (слева внизу):
image
 
Казалось бы всё просто. Есть OID, есть описание (Descr), по ним можно смело строить правила (Rule) и мониторы (Monitors) в SCOM2007.
Но на практике всё не совсем так.
Возьмем н-р трап 77. Вот его описание:
image
Путем преобразования (см. выше) получаем его OID — .1.3.6.1.4.1.318.0.77
 
Во первых, само описание мало информативно. Во вторых, как видно из описания, в этом трапе может передаваться номер состояния, которое описывает, какой из параметров имеет неверной состояние.
Всё это придется учитовать при создании моинторов (Monitor) и правил (Rule) в SCOM2007.
 
Один плюс — многие трапы стоят парами — первый трап генерируется при сбойном значении, второй — при возвращении в нормальное состояние.
Н-р для трапа abnormalCondition парным трапом явлется трап abnormalConditionCleared. Его OID .1.3.6.1.4.1.318.0.78.
Такая "парность" окажется крайне полезной, когда мы начнем создавать мониторы (Monitors) в SCOM2007.
 
На сим всё. В 3ей части будем применять полученные знания для построения правил и мониторов в SCOM2007.
image

Ошибка «Module was unable to convert parameter to a double value» в SCOM2007

Проблема

После создания правила для сбора статистики с SNMP-устройств в Operations Manager 2007, Вы можете получить ошибку в журнале приложения на сервере SCOM2007:
Module was unable to convert parameter to a double value
Original parameter: ‘$data/SnmpVarBinds/SnmpVarBind[1]/Value$’
Parameter after $Data replacement: »
Error: 0x80020005
Details: Type mismatch.

 
а также алерт класса "Warning": "Generic Performance Mapper Module Failed Execution" с описание:
Module was unable to convert parameter to a double value
Original parameter: ‘$data/SnmpVarBinds/SnmpVarBind[1]/Value$’
Parameter after $Data replacement: »
Error: 0x80020005
Details: Несовпадение типов.
One or more workflows were affected by this. Workflow name: __Internal_name_of_rule_
Instance name: _IPAddress_
Instance ID: {XXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}
Management group: _Managment_group_name_

Причины

Данная проблема может возникать в двух случаях:
1. Вы создали правило (Rule) для сбора статистики типа (type) "Collection Rules\Event Based\SNMP Event"
2. Вы создали правило (Rule) верно, но устройтсво не возвращает значения по заданому OID

Решение

1. Запомните/запишите настройки правила (Rule).
2. Удалите правило (Rule)
3. Создайте правило (rule), и укажите тип правила (type of rule to create) "Collection Rules\Perfomance Based\SNMP Perfomance"
4. Подождите 2-3 интервала, указанных в поле Частота (Frequency) на этапе "SNMP Probe", затем проверьте на предмет ошибок и появления значений.
5. В случае, если ошибка повториться — проверьте любым MIB-браузером, верно ли задано значение OID и выдает ли устройтсво какое-либо значение по указанному OID. Значения для сбора статистики (Perfomance) не могут иметь отрицательных значений.

SPTraceView: средство от мигрени

 
Инструмент из разряда must have для разработчиков WSS/Sharepoint: SPTraceView.
Эта маленькая тузла съкономит Вам кучу нервов и времени при поиске решения для проблем класса "Почему эта фигня не работает???".
 
Программа запускается трее, и в реальном времени мониторит все события на локальном сервере с установленым WSS3 либо Sharepoint 2007.
Настройки программы очень богаты:
image image
image
 
Последние 2 окна удобны, если на одном сервере запущено нексолько сайтов WSS.
 
Имеется журнал:
image
 
Текущая версия: 0.9.7.1
Домашняя страница: http://hristopavlov.wordpress.com/sptraceview/