How to generate an alert directly from a script-based rule
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:
When you’re finished creating your rule, take a look at the properties > Configuration tab. You’ll see the following:
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.
In the Health Model, click on the Rules node. Create a new Custom Rule.
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.
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.
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.
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.
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.
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.
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.
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.
Now Edit your new Condition Detection module and click Configure.
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.
Click Ok, and now your module configuration looks like this.
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.
Edit your new Write Action, and click Configure.
Give it an alert name, and click on Alert Suppression.
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).
Configure alert suppression on PrincipalName, as follows.
Click Ok a few times to finish creating the rule. Save the management pack and export to your test management group.
Watch the alerts roll in. Notice repeat count is rising, due to my configuring suppression.
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
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
I hope this helps to launch you into a new world of authoring with the Authoring Console!
Comments
- Anonymous
January 01, 2003
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:
- A Data Source
- A Condition Detection
- 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
- Anonymous
January 01, 2003
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.