Command Shell Examples
Useful SQL Queries
How to generate an alert directly from a script-based rule - Jonathan Almquist on Operations Manager - Site Home - TechNet Blogs

How to generate an alert directly from a script-based rule

How to generate an alert directly from a script-based rule

  • Comments 2
  • Likes

This question has come up in more than a few conversations and threads, and in this particular thread I promised that I’d write a post to cover this.  I think the fundamental reason why many are bewildered by the fact that we “cannot” write a script-based rule that directly generates an alert, is because the Operations Console actually does not provide this type of rule to create in the Authoring space.

It’s fairly easy to generate an alert directly from a script-based rule.  But, since this type of rule (or wizard) is not provided in the Authoring space, we’ll need to resort to using the Authoring Console or directly editing XML in order to compose this workflow.

Why can’t we create this in the Operations Console?

If you’ve ever created a script-based rule in the Operations Console by selecting the Execute a Script type, as follows:

image

When you’re finished creating your rule, take a look at the properties > Configuration tab.  You’ll see the following:

image

We have a Scheduler module for a Data Source, and a Run Script module for a Write Action (aka, Response).  Yes, that’s exactly what was described by the rule type, Timed Command > Execute a Script.

No complaints here, unless you want to generate an alert.  In which case, we need another Write Action that is capable of generating an alert.  However, we are unable to add that as a Write Action in the UI.

Furthermore, in order to generate an alert, we’re probably looking for a condition.  In order to filter the condition we are trying to detect in our script, we definitely need a Condition Detection module as well.  Again, we are unable to add a Condition in the UI.

I can only imagine that the reason why this type of rule is not provided in the Operations Console is because there are just too many moving parts.  Besides, the Operations Console really isn’t designed to do advanced authoring.  If you’re curious about how to generate an alert directly from a script-based rule, you’ve moved beyond the capabilities of the Operations Console authoring space and it’s time to graduate to the Authoring Console.

Logic of a script-based rule that directly generates an alert

Now that we see the limitations of the Operations Console, let’s think about workflow logic so we can compose this in the Authoring Console.

Following is the workflow logic of a script-based rule that directly generates an alert.  This is a composite workflow, which means it is composed of more than one module to create the entire monitoring workflow.  This workflow will be composed of three different modules.

Data Source
We need a script to run at an interval.

Module

Script Property Bag Data Provider
Condition Detection
We need to filter the output of that script to tell the rule when to alert.

Module
ExpressionFilter
Write Action
We need a Write Action to generate the alert when the condition is met.

Module
Health.GenerateAlert


Composing our script-based rule

If you haven’t done so yet, first thing you’ll need to do is install the R2 Authoring Resource Kit, which includes the Authoring Console.

Launch the Authoring Console and create a new Empty Management Pack.

image

In the Health Model, click on the Rules node.  Create a new Custom Rule.

image

Give it a name and target something.  This is a tutorial about creating the rule, not about targeting best practices.  Obviously, you’ll have a better target when you go to create this rule for “real world” use.  For now, I’m targeting Windows Computer.

image

Click on the Modules tab.  You’ll notice we have our three types of modules we described in the workflow logic earlier; Data Source, Condition Detection and Write Action.  We’ll be creating each of these next.

image

Create the Data Source

Create the Data Source module and select the Script Property Bag Data Provider.  Give it a Module Id, and click Ok.

image

You’ll see your new Data Source module inserted into the workflow.  Now you’ll need to configure it with your script, so click Edit.

image

Going down the configuration elements, from top to bottom, should be fairly straight forward.  Interval is in seconds, so here I want to run the script every one minute.  I do not want to use SyncTime, so I leave this value empty.  I input the ScriptName value (this should exactly match your script name).  You can provide arguments, which are parameter elements you can pass into the script.  I’m not going to pass any parameters into this script in this tutorial, so I’m leaving it empty.  ScriptBody will contain your entire script  (we’ll input the script in a minute).  TimeoutSeconds will be how long your script will run until we consider it unresponsive and kill the script.

For this tutorial, your configuration should look like this.

image

 

 

 

 

 

 

 

 

Before leaving this screen, we need to click Edit in order to input our script.  Clicking Edit will popup an XML editor.  You can use Notepad if you do not have an XML editor.  You should see something like this.

image

Notice that I highlighted ScriptBody.  Replace this part with your entire script.  I included a basic script below that will work in this tutorial.

' #Include File:MyScript.vbs
Option Explicit
Dim oAPI, oBag, sMyScriptValue
Set oAPI = CreateObject("MOM.ScriptAPI")
Set oBag = oAPI.CreatePropertyBag()
sMyScriptValue = "AlertCondition"
Call oBag.AddValue("MyScriptPropertyName", sMyScriptValue)
Call oAPI.Return(oBag)
' #Include File:MyScript.vbs

Now your XML should look like this.

image 

Note that we’re creating a Property Bag named MyScriptPropertyName, and we’re assigning it a value AlertCondition.  Your script will obviously have some logic, and could possibly create multiple Property Bags that could contain any number of values.  Just keep in mind that what you’re evaluating in your script is the output that will be evaluated in the Condition Detection module next.

Close the editor and click Save.  Click Ok on the module configuration screen, and we’ll configure the Condition Detection module next.

Create the Condition Detection

Click on Create for the Condition Detection module, and select the ExpressionFilter module.  Give it a name and click Ok.

image

Now Edit your new Condition Detection module and click Configure.

image

 

 

This is where we configure our alerting condition.  Remember, in our script we create a Property Bag named MyScriptPropertyName with a value of AlertCondition.  This is the output of the Data Source module, so it is also the input of the Condition Detection module.  This is because a workflow will pass it’s output to the next module in the workflow.

Configure the expression as follows.

image

Click Ok, and now your module configuration looks like this.

image

Click Okay.

Write Action

Click Create for the Write Action module type, and select the Health.GenerateAlert module.  Give it a name and click Ok.

image

Edit your new Write Action, and click Configure.

image

Give it an alert name, and click on Alert Suppression.

image

This is where we can suppress alerts if we want, which is usually a good idea for rules (unless you want potentially thousands of unique alerts for the same problem).

image

Configure alert suppression on PrincipalName, as follows.

image

Click Ok a few times to finish creating the rule.  Save the management pack and export to your test management group.

image

Watch the alerts roll in.  Notice repeat count is rising, due to my configuring suppression.

image

Wrap up

At the beginning of this post, I showed you what a script-based rule looks like when created in the Operations Console.

Created in Operations Console
image

In the Operations Console, if we look at the properties of the rule we just created by using the Authoring Console, you’ll be able to put together what we were missing and how these modules actually needed to be switched around quite a bit.

Created in Authoring Console
image 

I hope this helps to launch you into a new world of authoring with the Authoring Console!

I do not moderate this blog anymore. If you have a question regarding this post, send me a message.

Comments
  • Good stuff Jonathan, thanks.  Would you be able to do this using a scheduler module to only have the script run on a fixed weekly schedule?  Maybe add System.Scheduler data source in addition to the Script Property Bag Data Provider in your example?  Or could you go another route, and instead of building a custom rule, build a new Timed Script rule, and add a Write Action?  Thanks.

  • Hi Layne,

    You could definitely do what you're asking.  This example just goes to show that we can generate an alert directly from a script-based rule.  How you arrive at the final write action, which is the actual alert generation module, is up to you.

    If you go back to the section, "Logic of a script-based rule that directly generates an alert", you'll see that it's possible to incorporate any number of modules.  The requirement and logic is that there must be:

    1. A Data Source

    2. A Condition Detection

    3. A Write Action

    Either one of these things could be composite, meaning that they can each be built from several different modules.

    I think the question now would be:

    How do you create any of these to be a composite of different modules?

    The anser to that is:

    Use the Type Library space in the Authoring Console.

    Hope that helps,

    -Jonathan