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

Статья расчитана на людей, хорошо знакомых с продуктом 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 и вашей системой. При желании, она может быть двусторонней: при закрытии тикета — закрывать и алерт.
Вариант второй. В вашей организации инфраструктура поделена на зоны ответственности. Допустим, списки оборудивания и систем и списки ответственных консолидированы в одном документе. Используя такой коннектор и этот документ, можно обновлять атрибуты алерта определенной информацией. Таким образом, оператору будет проще правильность обработать его.

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