Notes on System Center Operations Manager : Alerting

OpsMgr 2007 R2 - Alert Storm Recognition (possible rule misconfiguration) for SDK alert

MSutara — Tue, 29 Sep 2009 21:18:47 GMT

I described the mitigation for alert storm in the one of my previous post. This mitigation is included out of the box with current deployment of OpsMgr 2007 R2 after system management packs were imported.

As I failed to remember this post (which talks about how to insert alerts from SDK), I also failed to realize that this alert suppression feature will not work unless a change to your custom management pack is made.

I was reminded by Markus, that I need to provide an update in order for this feature to work properly for SDK inserted data generating too much alerts within short period of the time.

History of SDK inserted alert requirements:

When we designed this SDK feature, we decided that it is best for MP (and connector) author to make a copy of condition detection module System.Connectors.GenericAlertMapper, publisher write action System.Connectors.PublishAlert and final composite module type System.Connectors.GenerateAlertFromSdkEvent into their own management pack.

That was the reason why we did not include such definition(s) inside of Microsoft management packs (well some things had changed since then so it is possible we will make this available as public module from one of our system MP in the future).

Management pack with sample modules can be also downloaded directly by clicking this.

Unfortunately this decision has a negative impact on “alert storm mitigation” feature which was delivered as a part current OpsMgr release. This is because implementation of this feature included minor change in the configuration of the module converting input data type to alert (System.Connectors.GenericAlertMapper).

By seeing your current implementation still working, it is clear that such change was not breaking backward compatibility.

Unfortunately, if configuration is not changed for your modules generating alert for SDK inserted data as well, runtime will not initialize component responsible for alert storm recognition and suspension.

Customization needed:

It is required to change the version for all referenced system management packs to OpsMgr R2. This ensures that MP will not be imported to previous releases of OpsMgr where feature is not implemented and would cause alert generating workflow unload. (This is because of failure during configuration processing while loading a module responsible for alert generation.)

<Version>6.1.7221.0</Version>

It is also required to add ManagementGroupName tag into configuration of the module(s). Highlighted areas in XML representation of module types should be self descriptive both for alert generating module as well as final composite module type.

<ConditionDetectionModuleType ID="System.Connectors.GenericAlertMapper" Accessibility="Internal" Batching="false" Stateful="false" PassThrough="false">
  <Configuration>
    <IncludeSchemaTypes>
      <SchemaType>Health!System.Health.AlertSchema</SchemaType>
    </IncludeSchemaTypes>
    <xsd:element name="Priority">
      <xsd:simpleType>
        <xsd:restriction base="xsd:integer">
          <xsd:minInclusive value="0" />
          <xsd:maxInclusive value="2" />
        </xsd:restriction>
      </xsd:simpleType>
    </xsd:element>
    <xsd:element name="Severity">
      <xsd:simpleType>
        <xsd:restriction base="xsd:integer">
          <xsd:minInclusive value="0" />
          <xsd:maxInclusive value="2" />
        </xsd:restriction>
      </xsd:simpleType>
    </xsd:element>
    <xsd:element name="ManagedEntityId" type="xsd:string" />
    <xsd:element name="AlertName" type="xsd:string" minOccurs="0" maxOccurs="1" />
    <xsd:element name="AlertDescription" type="xsd:string" minOccurs="0" maxOccurs="1" />
    <xsd:element name="AlertOwner" type="xsd:string" minOccurs="0" maxOccurs="1" />
    <xsd:element name="AlertMessageId" type="xsd:string" minOccurs="0" maxOccurs="1" />
    <xsd:element name="AlertParameters" type="System.Health.AlertParameters" minOccurs="0" maxOccurs="1" />
    <xsd:element name="Suppression" type="System.Health.Suppression" minOccurs="0" maxOccurs="1" />
    <xsd:element name="WorkflowId" type="xsd:string" />
    <xsd:element name="Custom1" type="xsd:string" minOccurs="0" maxOccurs="1" />
    <xsd:element name="Custom2" type="xsd:string" minOccurs="0" maxOccurs="1" />
    <xsd:element name="Custom3" type="xsd:string" minOccurs="0" maxOccurs="1" />
    <xsd:element name="Custom4" type="xsd:string" minOccurs="0" maxOccurs="1" />
    <xsd:element name="Custom5" type="xsd:string" minOccurs="0" maxOccurs="1" />
    <xsd:element name="Custom6" type="xsd:string" minOccurs="0" maxOccurs="1" />
    <xsd:element name="Custom7" type="xsd:string" minOccurs="0" maxOccurs="1" />
    <xsd:element name="Custom8" type="xsd:string" minOccurs="0" maxOccurs="1" />
    <xsd:element name="Custom9" type="xsd:string" minOccurs="0" maxOccurs="1" />
    <xsd:element name="Custom10" type="xsd:string" minOccurs="0" maxOccurs="1" />
    <xsd:element name="ManagementGroupName" type="xsd:string" />
  </Configuration>
  <ModuleImplementation Isolation="Any">
    <Native>
      <ClassID>2325018e-eef4-41a3-8c17-db831b85c93b</ClassID>
    </Native>
  </ModuleImplementation>
  <OutputType>Health!System.Health.AlertUpdateData</OutputType>
  <InputTypes>
    <InputType>System!System.BaseData</InputType>
  </InputTypes>
</ConditionDetectionModuleType>
 
<WriteActionModuleType ID="System.Connectors.GenerateAlertFromSdkEvent" Accessibility="Public" Batching="false">
  <Configuration>
    <IncludeSchemaTypes>
      <SchemaType>Health!System.Health.AlertSchema</SchemaType>
    </IncludeSchemaTypes>
    <xsd:element name="Priority">
      <xsd:simpleType>
        <xsd:restriction base="xsd:integer">
          <xsd:minInclusive value="0" />
          <xsd:maxInclusive value="2" />
        </xsd:restriction>
      </xsd:simpleType>
    </xsd:element>
    <xsd:element name="Severity">
      <xsd:simpleType>
        <xsd:restriction base="xsd:integer">
          <xsd:minInclusive value="0" />
          <xsd:maxInclusive value="2" />
        </xsd:restriction>
      </xsd:simpleType>
    </xsd:element>
    <xsd:element name="AlertName" type="xsd:string" minOccurs="0" maxOccurs="1" />
    <xsd:element name="AlertDescription" type="xsd:string" minOccurs="0" maxOccurs="1" />
    <xsd:element name="AlertOwner" type="xsd:string" minOccurs="0" maxOccurs="1" />
    <xsd:element name="AlertMessageId" type="xsd:string" minOccurs="0" maxOccurs="1" />
    <xsd:element name="AlertParameters" type="System.Health.AlertParameters" minOccurs="0" maxOccurs="1" />
    <xsd:element name="Suppression" type="System.Health.Suppression" minOccurs="0" maxOccurs="1" />
    <xsd:element name="Custom1" type="xsd:string" minOccurs="0" maxOccurs="1" />
    <xsd:element name="Custom2" type="xsd:string" minOccurs="0" maxOccurs="1" />
    <xsd:element name="Custom3" type="xsd:string" minOccurs="0" maxOccurs="1" />
    <xsd:element name="Custom4" type="xsd:string" minOccurs="0" maxOccurs="1" />
    <xsd:element name="Custom5" type="xsd:string" minOccurs="0" maxOccurs="1" />
    <xsd:element name="Custom6" type="xsd:string" minOccurs="0" maxOccurs="1" />
    <xsd:element name="Custom7" type="xsd:string" minOccurs="0" maxOccurs="1" />
    <xsd:element name="Custom8" type="xsd:string" minOccurs="0" maxOccurs="1" />
    <xsd:element name="Custom9" type="xsd:string" minOccurs="0" maxOccurs="1" />
    <xsd:element name="Custom10" type="xsd:string" minOccurs="0" maxOccurs="1" />
  </Configuration>
  <ModuleImplementation Isolation="Any">
    <Composite>
      <MemberModules>
        <ConditionDetection ID="Mapper" TypeID="System.Connectors.GenericAlertMapper">
          <Priority>$Config/Priority$</Priority>
          <Severity>$Config/Severity$</Severity>
          <ManagedEntityId>$Data/ManagedEntityId$</ManagedEntityId>
          <AlertName>$Config/AlertName$</AlertName>
          <AlertDescription>$Config/AlertDescription$</AlertDescription>
          <AlertOwner>$Config/AlertOwner$</AlertOwner>
          <AlertMessageId>$Config/AlertMessageId$</AlertMessageId>
          <AlertParameters>$Config/AlertParameters$</AlertParameters>
          <Suppression>$Config/Suppression$</Suppression>
          <WorkflowId>$MPElement$</WorkflowId>
          <Custom1>$Config/Custom1$</Custom1>
          <Custom2>$Config/Custom2$</Custom2>
          <Custom3>$Config/Custom3$</Custom3>
          <Custom4>$Config/Custom4$</Custom4>
          <Custom5>$Config/Custom5$</Custom5>
          <Custom6>$Config/Custom6$</Custom6>
          <Custom7>$Config/Custom7$</Custom7>
          <Custom8>$Config/Custom8$</Custom8>
          <Custom9>$Config/Custom9$</Custom9>
          <Custom10>$Config/Custom10$</Custom10>
          <ManagementGroupName>$Target/ManagementGroup/Name$</ManagementGroupName>
        </ConditionDetection>
        <WriteAction ID="WA" TypeID="System.Connectors.LibraryPublishAlert" />
      </MemberModules>
      <Composition>
        <Node ID="WA">
          <Node ID="Mapper" />
        </Node>
      </Composition>
    </Composite>
  </ModuleImplementation>
  <InputType>System!System.BaseData</InputType>
</WriteActionModuleType>

Enjoy alert storm mitigation (customization is possible as described in original post) after importing newly customized management pack!

What is new: OpsMgr 2007 R2 - Alert Storm Recognition (possible rule misconfiguration)

MSutara — Thu, 26 Mar 2009 07:51:00 GMT

What is new?

OpsMgr 2007 R2 Release candidate finally released and can be downloaded from Connect. What is new in this release? PLENTY! Some of you get a glimpse at those features while evaluating Beta, some will see most improvement for the first time … very exiting!

That is the reason why I would like to start small series where I comment on some of the changes or additions. With this post, I would like to mention a design change to suspend alert creation in order to prevent alert storm – yes, we did bring MOM2005 feature (at least for the rule) back!

Alert storm mitigation at glance:

I need to clarify we are not trying to solve generic data storm problem – that is vNext scenario. We were only addressing possible “rogue” alert generating rule to flood our operational DB and/or raise too many notifications.

Settings to recognize such problem are per agent (across all targeting instances) per individual management group (there are multiple groups settings in registry in multi-homed scenario). Default throttle settings are 50/60/10. This means that if one rule generates more than 50 alerts within 60s, such rule is suspended for 10 minutes (alert generation is disabled)

Option to customize threshold values still exist … Customization will not work in very special deployment scenario – having OpsMgr2007 R2 agent multi-homed to at least one management group monitored by OpsMgr2007 SP1 server (reason is that such agent is forced to use SP1 management packs – and those obviously miss new configuration required when threshold customization was requested). In order for runtime to recognize customized values, health service must be restarted!

When runtime recognizes that possible storm is happening, event 5399 is raised. Following is English snap of such event:

;// Suspend alert generating rule
;// %1 = management group name
;// %2 = workflow name
;// %3 = name of targeted instance
;// %4 = instance id
;// %5 = alert origin (name or message id)
;// %6 = count
;// %7 = time
;// %8 = disabled time

MessageId=5399
SymbolicName=MSG_HS_HM_ALERT_SUSPENDED
Severity=Warning
Language=English

A rule has generated %6 alerts in the last %7 seconds. Usually, when a rule generates this many alerts, it is because the rule definition is misconfigured. Please examine the rule for errors. In order to avoid excessive load, this rule will be temporarily suspended until %8.
%nRule: %2
%nInstance: %3
%nInstance ID: %4
%nManagement Group: %1.

OpsMgr 2007 R2 health monitoring will recognize this event and will raise an alert to notify operator about this problem. Alert needs to be manually closed when corrective action is taken or when conditions causing possible storm are mitigated

Following is an example of customized threshold values. It shows customization 15/30/5 (15 alerts within 30 seconds will cause suspension for 5 minutes (300 seconds). It also shows where in registry such customization should be done. One must create “Alert Count”, “Alert Count Interval” and ”Alert Suspend Interval” under “HKLM\System\CurrentControlSet\Services\HealthService\Parameters\Management Groups\<name of MG>”.

I hope you enjoy this product as much as we hope you would. I always feel happy, this time I also feel rather confident about its quality and value! Questions, comments, feedback (anything) please let me know, I will try to continue this series often (so any things in particular, scream and I move it higher in my TODO list!)

How to: Reset monitor when closing alert?

MSutara — Tue, 03 Feb 2009 06:59:00 GMT

Not something I recommend, one would say I almost regret we did not prohibit closing alerts generated by monitor (especially when auto-resolve feature was used). But recently I learned about some ticketing systems closing alerts where it is unclear if issue was corrected, so I see some necessity to automate the action of resetting monitor health state to re-generate monitor state change when issue still present after ticket was closed.

Problem Description:

Again, as said, there may be legitimate situations where a customer needs to reset monitor health once an alert generated by its state change has been resolved. Such scenario would include automated ticketing systems resolving alerts without providing enough evidence that issue was indeed addressed, situation where operator resolves batch of alert without investigating their root cause (after network outage) and/or by mistake.

Recently I saw this type of request from multiple sources independently of each other so I decided to provide what I believe may be the only solution on how to achieve this functionality – OpsMgr connector.

Analyzing proposal:

OpsMgr connector is nice feature allowing subscribing to alert changes happening for members of specified group. It also allows reacting on such change, in our case by locating monitor associated with alert and requesting its state reset thru SDK call.

Note:
I will not discuss connector internals (registration, used subscription …) but will provide source code for possible reverse engineering of my implementation.

Solution:

Attached, you can find source code for my solution as well as binary you should copy into your RMS product folder. You need to initialize connector when you start it. Such action will import MP with group definition (if MP was not imported already), it creates connector and its subscription (again if such actions are necessary) and starts worker thread to receive monitor raised alerts.

You should see connector created (in Administration section of operations console) after successful initialization.

Currently connector uses group which is populated with instances of computer. This can be adjusted (steps described later) and you should be able to see all members after group calculation rule finishes (in Authoring section of the operations console).

Bellow is an example of alert raised by test event based monitor. When this alert is resolved, state of the monitor resets.

Customization:

As mentioned, this connector will respond to all alerts generated for any monitors which belong to the instance of Windows Computer. It is rather simple to customize the managed entity type you want to use though.

First export connector management pack:

Then edit management pack in XML editor of your choice. You need to change type used with relationship as well as group population rule:

After changes are saved and you imported your management pack, please restart connector application (initialization button will not overwrite changes to MP, but remove button will delete MP from OpsMgr when removing connector from your environment). You can see in the source code that worker thread starts in 3 minutes (to give group calculation time to populate group) and subscription uses 1 minute polling interval to retrieve all alerts as per subscription definition.

One more word of caution to be said is that connector like this may not be fully scalable in big environments and additional work could be needed. This post can serve as nice example and base stone for such more advanced application though.

DISCLAIMER:

Please evaluate in your test environment first! As expected, this solution is provided AS-IS, with no warranties and confers no rights. Use is subject to the terms specified at Microsoft. Future versions of this tool may be created based on time and requests.

HealthServiceWatcher alerts and connector.

MSutara — Wed, 15 Oct 2008 06:00:00 GMT

Recently I had heard from couple of customers (internal and external) about their trouble with ticketing alerts created from Health Service Watcher. Main complaint was related to the fact that alert is raised by instance of the watcher rather than instance...(read more)

Alert Severity and Priority use with override

MSutara — Mon, 17 Dec 2007 22:20:00 GMT

Some of you may know already that with Operations Manager SP1 RC we allow for overriding alert severity and priority. What is little unfortunate is inconsistency between creating alert generating rule and overriding especially as first uses string describing severity or priority used, while later simply expects integer value. Mapping between string and integer is what this post will try to explain.

Mapping:

Alert Severity – Its corresponding integer value

Critical – 2
Warning - 1
Information – 0

Alert Priority – Its corresponding integer value

High – 2
Medium – 1
Low – 0

Let’s assume we have following alert with severity CRITICAL:

Let’s override severity. As we can see effective value used for severity is 2 and priority is 1.

We can now override severity. Let’s pick incorrect value outside of allowed range to demonstrate the ability of runtime to adjust and generate corrected alert.

After such override was applied and configuration reloaded new values are used when alert should be raised. Following is sample of such alert.

We can see that new alert is raised with severity INFORMATION. Value of information as per mapping above is 0. So runtime had to adjust and used closest value to -1 which we used while overriding severity. In order to help with recognition of incorrect value used for severity or priority override, Operations Manager 2007 SP1 introduced new events (5404, 5405) to inform the user when runtime was unable to recognize used value and had to adjust to closest allowed one. There is also alert raised to allow OpsMgr2007 operator to recognize this problem without inspecting event log.

Sample alert:

Sample event (this raised alert above):

Event Type:             Warning
Event Source:          HealthService
Event Category:       Health Service
Event ID:                 5405
Date:                      12/17/2007
Time:                      11:16:25 AM
User:                      N/A
Computer:               CUPIDDP13D

Description:

Invalid value for alert severity used with configuration of the rule. It was outside of allowed range and had to be adjusted to closest valid value.

Alert: F2732EEA-A871-27EA-1639-143269DE3CEF
Workflow: MomUIGeneratedRule34de90f776f541db8ccb625bf338af58
Instance: OpsMgr Health Service
Instance ID: {4140A3FC-F165-F0BC-E036-4B2FFB93C622}
Management Group: marius

Used severity value: -1

How to troubleshoot:

There are a couple of options. Operator may remember the alert for which he used value “-1” in override and he needs to go back and use correct value from range as discussed in this post. In the case override was done long ago, or by someone, following steps could help to locate what the name and target for particular alert are and use that information to fix alert override thru authoring section of UI.

In the case of sample event used above one should run:

1. Open Windows Power Shell

2. Get and store monitoring object

$mo = Get-MonitoringObject –Id “4140A3FC-F165-F0BC-E036-4B2FFB93C622”

3. Get an alert rule to recognize where to change

$rule = Get-Alert -MonitoringObject $mo -Criteria "Id='f0ccb13e-22f1-47de-ba98-2c54975089dc'"

4. Retrieve name and target to adjust value for particular overridden alert property later

$rule.Name

$rule.MonitoringObjectFullName

Parameter replacements and its use with alert

MSutara — Mon, 10 Dec 2007 23:03:00 GMT

Many of you probably know already, that alert’s description can use parameter replacements to reference the value of any of the properties of the data type causing the alert to be raised in the first place. I tried to comment on some most commonly used data types and its XML representation in order to help with writing replacement XPath query, which then yields such value as a result of its execution (see older postings about parameter replacements and data item XML).

Unfortunately what I forgot to stress out is that alert description is the only place where such replacement works. Recently I saw couple of requests to help with a replacement inside of alert name (to customer the use of replacement seemed as a good way to create more unique alert names especially when there could be a multiple triggers raising such alert and proper suppression had been used in order to "preserve" the alert for each one of them).

Here is a sample of incorrect alert configuration causing replacement string being treated as constant alert name:

Here is a sample of above alert configuration inside of active alert:

Conclusion:

For alert, data replacement works only inside of alert description with release of Operations Manager 2007 and Operations Manager 2007 SP1.

Alert suppression (troubleshooting)

MSutara — Thu, 08 Nov 2007 00:42:00 GMT

Unfortunately there is no way to troubleshoot if alert suppression works as expected, especially in the case when dynamic value to suppress against was used. By dynamic value I mean replacement that runtime must try to do in the case of using $Data/<xpath expression to retrieve value of data type property>$ inside of “SupressionValue” tag.

We recognized this problem and tried to address it with SP1 release of Operations Manager 2007.

Brief reminder of how suppression works. Runtime retrieves the values defined inside of “SuppressionValue” tags and calculates hash based on combination of such values and workflow ID. This hash later allows for recognition if alert history count is to be incremented (which means that alert is suppressed) or if brand new alert should be raised.

Again, in the case of $Data/<xpath expression to retrieve value of data type property>$ runtime will evaluate XPath expression against XML representation of data type serving as an input for alert generating module. If such operation yields a result, value is added for hash calculation. If XPath expression doesn’t yield any result, runtime will need to use complete string “$Data/<xpath expression to retrieve value of data type property>$” as value for hash calculation. You can see that such string is treated as a constant and is not really affecting the calculation of the hash. This off course causes undefined behavior, especially in the case when XPath was supposed to yield unique value for better alert customization.

In order to help with troubleshooting, SP1 introduced an event (5402) written to “Operations Manager” event log. This event carries information which should help to recognize if property value replacement failed to yield result due to typo, non existence or some other reason. There is also alert raised to allow OpsMgr operator to recognize this problem without inspecting event log.

Sample event:

Event Type:   Warning
Event Source: HealthService
Event Category:       Health Service
Event ID:       5402
Date:            10/29/2007
Time:            9:26:27 AM
User:            N/A
Computer:     CUPIDDP13D

Description:
Parameter replacement during creation of the alert failed causing unexpected suppression used.

Alert: B5615F97-1D44-433F-D25C-2E8916D13498
Workflow: EventBased.Test.AlertFromEvent
Instance: sampleInstance
Instance ID: {BEC075CC-4008-5A4F-9D8D-6BC9C1012D36}
Management Group: sampleGroup

Failing replacement: $Data/UnreachableEventDisplayNumber$

How to troubleshoot:

1. Open Windows Power Shell

2. Get and store monitoring object

in case of sample events from above you run:

$mo = Get-MonitoringObject –Id “BEC075CC-4008-5A4F-9D8D-6BC9C1012D36”

3. Get a rule to recognize what management pack to change

in case of sample events from above you run:

$rule = Get-Rule -MonitoringObject $mo -Criteria "Name = 'EventBased.Test.AlertFromEvent'"

4. Retrieve management pack

in case of sample events from above you run:

$rule.GetManagementPack()

Resolution:

If management pack is sealed, please disable alert generating rule identified by the value of “Workflow” from event description. Then contact Management pack developer and request fix for alert suppression.

In the case it is your custom management pack, please correct XPath expression desired for alert suppression, where this supression is identified by “Failing replacement” inside of rule identified by “Workflow” from event description, increase version number and re-import corrected management pack.

In the case rule was created using authoring part of UI, please edit rule properties and correct XPath expression in suppression tab. Incorrect XPath is again identified by “Failing replacement” from event description.

Alert Suppression (beginning)

MSutara — Wed, 07 Nov 2007 22:49:00 GMT

Alert suppression is feature that allows for greater flexibility of alerts raised. So how was alert suppression feature designed? First we need to distinguish between types of alert that could be raised in Operations Manager 2007.

Monitor state change based alerts:

This type of alert is always suppressed by monitor ID. This in reality means that there is just one alert per monitor as long as state of that particular monitor fits condition for alert creation. Suppression of this type is not customizable

Rule generated alerts:

This type of alert is suppressed based on configuration defined for alert generating write action. Following is snippet of module definition and as expected, suppression is driven by tag “Suppression”.

<SchemaType>System.Health.AlertSchema</SchemaType>

</IncludeSchemaTypes>

<xsd:element name="Priority">

<xsd:simpleType>

<xsd:restriction base="xsd:integer">

<xsd:minInclusive value="0" />

<xsd:maxInclusive value="2" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="Severity">

<xsd:simpleType>

<xsd:restriction base="xsd:integer">

<xsd:minInclusive value="0" />

<xsd:maxInclusive value="2" />

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="AlertName" type="xsd:string" />

<xsd:element name="AlertDescription" type="xsd:string" />

<xsd:element name="AlertOwner" type="xsd:string" />

<xsd:element name="AlertMessageId" type="xsd:string" />

<xsd:element name="AlertParameters" type="System.Health.AlertParameters" />

<xsd:element name="Suppression" type="System.Health.Suppression" minOccurs="0" maxOccurs="1" />

<xsd:element name="Custom1" type="xsd:string" />

<xsd:element name="Custom2" type="xsd:string" />

<xsd:element name="Custom3" type="xsd:string" />

<xsd:element name="Custom4" type="xsd:string" />

<xsd:element name="Custom5" type="xsd:string" />

<xsd:element name="Custom6" type="xsd:string" />

<xsd:element name="Custom7" type="xsd:string" />

<xsd:element name="Custom8" type="xsd:string" />

<xsd:element name="Custom9" type="xsd:string" />

<xsd:element name="Custom10" type="xsd:string" />

</Configuration>

Where suppression type is defined as list of suppression values:

<xsd:complexType name="System.Health.Suppression">

<xsd:sequence>

<xsd:element name="SuppressionValue" type="xsd:string" minOccurs="0" maxOccurs="unbounded" />

</xsd:sequence>

</xsd:complexType>

As we can see, there is a possibility for Alert suppression to be ignored causing new alert created each and every time. This is achieved when tag “Suppression” doesn’t exist in configuration for alert rule.

Default suppression using workflow id is to be used when tag “Suppression” exists with empty tag “SuppressionValue”. This is causing same behavior as described for alert generated by monitor state change then.

Customized suppression using hash of defined values with workflow id is to be used tag “Suppression” exists with non empty tag “SuppressionValue”. This for example allows for alert to be raised each and every time different description of event exists. It also disallows for suppression across workflows though.

Conclusion:

1. No tag Suppression

· Result:
Suppression is ignored and new alert is raised all the time

2. Empty tag Suppression

· Example:

· Result:
Suppression is ignored and new alert is raised all the time

3. Empty tag SuppressionValue

· Example:

· Result:
Suppression is based on workflow ID which is same as suppression used for alert generated by monitor state change

4. Non empty tag SuppressionValue

· Example:

<Suppression>
<SuppressionValue>value</SuppressionValue>
</Suppression>

· Result:
Suppression is based on the hash calculated from “value” + workflow ID