Monitor from sealed MP generated alert and I do not like its description …

Artikkeli
07/15/2008

… Is there anything I can do? Our usual answer was that not really and you need to create your custom monitor while disabling original one. I would like to take this opportunity and rephrase that answer with this post. First, couple of requirements must be met, before I can say, that there is a way to customize your alert.

1. Monitor defined inside of sealed management pack MUST be accessible outside of such MP. In other words this means that monitor MUST be public. This requirement might be already met for most of the monitors, especially when diagnostics, recovery are defined outside or when using this monitor as contributor for some random dependency monitor residing inside of the different management pack.

2. You should be familiar with authoring management pack thru direct XML editing. I know that sounds highly user unfriendly, but unfortunately, current version of Authoring Console doesn’t support overrides creation (this I heard will change in next release)

What else do we need to know? There is an override for monitor which is not FULLY visible thru UI. It is MonitorPropertyOverride and there are multiple properties that are override-able for monitor. Some of them you might be familiar with as they are accessiblethru UI (Generate Alert, Alert On State, Alert Priority, Alert Severity …).

Monitor overrides visible thru UI

There are multiple properties that are not displayed but override-able too. Those that I will explain here are AlertMessage and AlertParameter1 … AlertParameter10. In my guide I will use unsealed management pack. Only difference will be the fact, that my monitor and required overrides are defined within same MP. In your custom solution, you will likely follow best practice of having overrides in unsealed MP different than “default user”, probably in unsealed MP where overrides for similar ME type are stored.

Please REMOVE Overrides section from attached MP to repro next steps.

1. Let’s assume I have simple event monitor. This monitor picks event 111 from Application log and generates state change to “Warning”. Let’s also assume that I will have alert generated when state of the monitor is at least “Warning” and that I will match alert severity with monitor health. (None of this should be too strange as is already something you are required to specify when creating new unit monitor).

2. After writing event 111 into Application log, state change is recorded and alert is raised as showed in the next picture.

Raising warning event

Alert with original description

3. This was all possible because runtime simply followed what was defined inside of AlertSettings for my sample the monitor. Here is XML fragment of that section.

<AlertOnState>Warning</AlertOnState>

<AlertPriority>Normal</AlertPriority>

<AlertSeverity>MatchMonitorHealth</AlertSeverity>

<AlertParameter1>$Target/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$</AlertParameter1>

<AlertParameter2>$Data/Context/DataItem/EventDisplayNumber$</AlertParameter2>

</AlertParameters>

</AlertSettings>

4. Let’s look closer what particular parts mean. It is rather simply, really. Attribute AlertMessage says that there is StringResource with ID equal to Microsoft.SystemCenter.Community.SimpleEventBasedMonitor_AlertMessageID. It also says (somewhat indirectly, but clearly) that such MP element is defined within same management pack (reason is that it is not preceded by MPReferenceAliasName! ). If you inspect attached MP, you will see that following is present.

5. As every resource, there will be DisplayString associated with that MP element. It is defined as follows inside of my sample MP.

<Name>Alert raised for Demo Event Based Monitor</Name>

<Description>This is original alert description. Provides info that target is {0} and that this alert was raised for event ID {1}</Description>

</DisplayString>

6. We can observer that Description part of this display string is what is displayed by UI after SDK performed string replacement. It might be obvious what was the replacement using. Yes, it was using AlertParameters section from alert settings definition.

How do I customize my alert description?

1. New AlertMessage needs to be created. Its display strings must use correct language used with locale of server installation. AlertMessage and its data is what I would call “static” SDK data. It can be part of “any” management pack. It is only imported into operational database and is used by SDK when alert is retrieved. One MUST be aware of parameter replacement, especially if alert parameter values or order are to be changed. In the section above I showed original AlertMessage and its display strings, here is value that I want to use next time alert is generated:

<Name>Alert raised for Demo Event Based Monitor with overriden alert description</Name>

<Description>This is OVERRIDEN alert description. It shows that I'm able to override AlertMessageID (which is ultimately how SDK retrieves description) as well as alert parameters. So new description provides info that event description is {0}.</Description>

</DisplayString>

2. Now having this data in DB is just a first step. We need to help runtime to understand the need to use it next time alert for monitor is generated. This is where overrides come to place. The initial override which is needed is override for AlertMessage. Runtime must use GUID representing this new description when creating alert data. To get such GUID, querying table StringResource is required after new alert message was imported into DB.

Query database to get alert message ID

Once GUID is retrieved from DB, it can be used. As you can see below, override is using my demo monitor, it is used with context of original monitor target and its value is holding GUID representation of alert message I want to use.

</MonitorPropertyOverride>

Please observe, when compared with original alert description, that I changed what my alert parameter (which is to be replaced) is. So once again, runtime needs help to recognize what is/are parameters to be used with next generated alert. This is done by AlertParameter override. Indexing of alert parameters is 1-10, while indexing of replacement strings is {x} where x is 0-9. Please be aware of that, otherwise you have unexpected result! In my example, override is again using my demo monitor in proper context (original target, but grouping and all other nice things related to overrides are allowed, but out of scope of this post). Its value is replacement I want to use when retrieving value from input data type, but it can be any string including static constant string really.

<Value>$Data/Context/DataItem/EventDescription$</Value>

</MonitorPropertyOverride>

3. If successfully followed this guide, next alert generated by monitor will use customized alert description like visible in next picture. Again, it is important to understand that this customization will not be visible until new active alert and it doesn't affect already present or resolved alerts!

Alert with overriden description

RECAP

1. Customization of alert description is possible for alert generated by “public” monitor.

2. This work is not for “faint of heart”. Big effort including DB query is required.

3. Using un-documented overrides (AlertMessage, AlertParameters) as well as understanding SDK replacement is required as main success driver.

I hope this guide can help some of you. I’m not aware any work happening on our side, to simplify this process by allowing our authorization tools to understand and use this. I might be wrong but it is possible these steps will be required when customizing monitor in next release too. I will also try to post more guides like this about some hidden treasures of our product in the future, permitting my time and bandwidth. Enjoy!

Microsoft.SystemCenter.Community.Monitors.xml

Comments

Anonymous
July 17, 2008
WHAT I FAILED TO MENTION in this post is that no configuration replacement is allowed in override values. Only replacement that works is dynamic replacement. Here is what this means. $Target and $MPElement replacements are not working with override value, only $Data works because replacement is performed by module and not by runtime! This is important information, sorry to leave it out!

Jaa

Monitor from sealed MP generated alert and I do not like its description …

Comments

Lisäresursseja