Работа с алертами в System Center Operations Manager, используя свой коннектор

Терминология:
SCOM — вместо полного названия;
Алерт — то же самое, что alert. Просто хорошего аналога в русском языке нет.

Введение

В SCOM, в отличие от многих других систем мониторинга, алерт является самостоятельным объектом. В зависимости от настроек, проверка может быть уже зеленой, но алерт так и оставаться активным. Алерты используются и обрабатываются:

• оператором (человеком)
• стандартными коннекторами (например, Command Channel)
• внешними коннекторами (например, коннектор для синхронизацией с системой Service Desk)

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

Для создания коннектора, мы используем Powershell. Потому что:

• это проще чем на C#
• такой скрипт проще поддерживать/изменять

Также будут использоваться библиотеки SCOM SDK. Обычно они находятся в C:\Program Files\Microsoft System Center 2012 R2\Operations Manager\Server\SDK Binaries на любом сервере SCOM.

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

Прежде всего необходимо создать внешний коннектор, для этого тоже воспользуемся скриптом. Я не буду его подробно разбирать, так как эти же объекты мы будем использовать в основном скрипте. Главная часть в нем:

$connectorGuid = New-Object Guid("{6A1F8C0E-B8F1-4147-8C9B-5A2F98F10007}");              if ($action -eq "InstallConnector") { 	# подключение к SCOM     $mg = New-Object Microsoft.EnterpriseManagement.ManagementGroup($ManagementServer);     $icfm = $mg.ConnectorFramework;     $info = New-Object Microsoft.EnterpriseManagement.ConnectorFramework.ConnectorInfo;       $info.Description = "...";     $info.DisplayName = $ConnectorName;     $info.Name = $ConnectorName;      $connector = $icfm.Setup($info, $connectorGuid);       $connector.Initialize(); } 

GUID выбираем произвольный, главное, использовать в основном скрипте коннектора такой же. Кстати скриптом по ссылке можно и удалить коннектор.

Важно. После создания, коннектор станет доступен в графической консоли SCOM. Там можно настроить подписку на алерты — порядок действий почти такой же, как для стандартных коннекторов. Если этого не сделать, алерты в ваш коннектор попадать не будут.

Логика коннектора

Займемся основным скриптом. Начнем с того, что определим конфигурационные параметры:

# здесь я определяю путь с скрипту, так как там же будут библиотеки $ScriptPath = $MyInvocation.MyCommand.Path -replace $MyInvocation.MyCommand.Name; # имя одного из ваших серверов SCOM $ManagementServer = "scom.contoso.com"; # GUID вашего коннектора, который вы установочным скриптом $strGuid = "{6A1F8C0E-B8F1-4147-8C9B-5A2F98F10007}"; # email адреса для нотификаций $emailTo = 'azat.khadiev@contoso.com'; $emailFrom = 'scom@contoso.com'; # smtp server организации $Smtp = 'mail.contoso.com'; 

Email адреса и адреса серверов измените согласно инфраструктуре вашей организации.

# загружаем библиотеки SDK, которые лежат в той же папке что и скрипт $DLLs = ("Microsoft.EnterpriseManagement.Core.dll","Microsoft.EnterpriseManagement.OperationsManager.dll","Microsoft.EnterpriseManagement.Runtime.dll"); foreach ($lib in $DLLs) {     [Reflection.Assembly]::LoadFile($ScriptPath + $lib) | Out-Null } 

С помощью этих библиотек мы и сможем создавать объекты системы SCOM, тем самым работать с ней. Далее:

try {     # подключаемся к коннектору     $mg = New-Object Microsoft.EnterpriseManagement.ManagementGroup($ManagementServer);     $icfm = $mg.ConnectorFramework;     $connectorGuid = New-Object Guid($strGuid);     $connector = $icfm.GetConnector($connectorGuid);     # получаем все новые алерты     $alerts = $connector.GetMonitoringAlerts(); } catch {     Write-Host $_.Exception.Message.ToString();     exit 2; }  # помечаем алерты как обработанные $connector.AcknowledgeMonitoringAlerts($alerts); 

Помеченный таким образом алертом, не попадет более в наш коннектор, пока его не модифицируют — это либо смена статуса, либо изменение атрибута. Далее:

foreach ($alert in $alerts) {     try     {         # здесь главное действие над алертом, в нашем случае, отправка письма         $alertContext = [xml]$alert.Context;         $alertResolutionStateName = @{0="New";255="Closed"}; 		# контекст алерта это обычная xml, поэтому можно использовать XPATH         $monitorClass = $alertContext.SelectNodes("//Property[@Name='__CLASS']/text()").Value;          $subject = "This is an alert message from SCOM";         $emailBody = "`n" + $alertResolutionStateName[[int]$alert.ResolutionState] + "`n" + $alert.MonitoringObjectFullName + "`n" + $alert.TimeRaised + "`n" + $monitorClass;        		 		# отправляем сформированное сообщение         Send-MailMessage -SmtpServer $Smtp -Subject $subject -From $emailFrom -To $emailTo -Body $emailBody 		 		# здесь можем изменить алерт         #$alert.CustomField1 = "Notification sent.";         #$alert.Update();     }     catch     {         Write-Host $_.Exception.Message.ToString();     } } 

Тем самым мы отправили сообщение по каждому из алерту в SCOM. Не впечатляет, правда? Однако, обратите внимание на последние 3 строки в блоке try. Действительно, таким образом можно записать в атрибуты алерта какую-либо информацию или даже закрыть его (то есть установить статус Closed). Вот это уже интересней. Правда, есть один момент: если вы измените таким образом алерт, при следующем выполнении скрипта, он опять попадет в коннектор (так как изменился) и можно получить бесконечную обработку. Поэтому, перед модификацией, следует производить проверку алерта на соответствующее условие. В нашем примере, можно проверять, чтобы атрибут CustomField1 был пустой, в ином случае не производить модификацию.

Итак, в целом, наш коннектор готов. Один запуск скрипта обрабатывает все алерты, доступные в этот момент. Для постоянной работы, можно запустить его в бесконечном цикле или настроить регулярное исполнение в Task Scheduler. Это гораздо проще, чем поддерживать сервис написанный на C#.

Области применения

Вариант первый. В вашей организации есть система Service Desk. К ней есть API и вы с ним хорошо знакомы. Используя такой коннектор, вы можете настроить интеграцию между SCOM и вашей системой. При желании, она может быть двусторонней: при закрытии тикета — закрывать и алерт.
Вариант второй. В вашей организации инфраструктура поделена на зоны ответственности. Допустим, списки оборудивания и систем и списки ответственных консолидированы в одном документе. Используя такой коннектор и этот документ, можно обновлять атрибуты алерта определенной информацией. Таким образом, оператору будет проще правильность обработать его.

На этом все, спасибо за внимание.