Selecting a Target for a Workflow
One of the required properties that you must specify when creating a workflow (rule, monitor, or task) is a target which specifies the class that the workflow will run against. Most management groups will have a large list of classes (provided by all of the installed management packs) that can act as potential targets, and selecting the most appropriate one is critical to the proper operation of the workflow.
Implications of a Target
To select an appropriate target, you should start by understanding its effects on the workflow. The different implications to consider are as follows.
Which agents the workflow will run on and how many copies of it will execute on each
A management pack is deployed to any agent that manages at least one instance of a class that is used as a target on at least one included workflow. Once the management pack is deployed, the agent will load a separate copy of each workflow for each instance of its target class. This means that if there are multiple instances of the target class on the agent, as may be the case with such classes as Logical Disk or IIS Web Site, then the agent will load multiple copies of the same workflow. Workflows included in the management pack that are targeted at objects not managed by the agent will not be run by that particular agent.
The number of copies of the workflow that can be expected on any given agent must be taken into account when defining the workflow. If a particular rule or monitor has the potential to have multiple copies running on a single agent, then it has the potential to generate multiple alerts or collect multiple pieces of data when only a single one is desired.
For example, a rule may be defined to generate an alert in response to a particular event in the Windows event log. A common strategy for this scenario is to target Windows Operating System and use the Event Source and Event Number to specify the desired event. This typically works as expected since there will always be only a single instance of Windows Operating System on any agent. In this case, only a single copy of the rule is loaded, and the Event Source and Event Number are sufficient criteria to uniquely identify the event. If the same rule targets a class with multiple instances on an agent, however, then a separate alert would be created for each copy of the rule in response to a single event. In this second case, a property on the target class would need to be included in the rule’s expression to specify which copy of the workflow should generate the alert.
To illustrate this example, the SQL Server 2008 Monitoring management pack includes a rule called Script : Failed to login that indicates that a monitoring script failed to login to a particular database. It determines this error has occurred by a particular event in the Operations Manager event log. This rule is targeted at Microsoft SQL Server 2008 Database which can have multiple instances on a particular agent – one for each database on that server. If only the Event Number and Event Source were specified, then a separate alert would be created for each database since the criteria in each copy of the rule would match the details specified for the event. In order to specify which copy of the rule should generate the alert, the expression in the rule also specifies that the Event Description must include the name of the database. It does this by using the DatabaseName property of the target object. Each copy of the rule resolves this variable when loaded by the agent so that only the copy of the rule matching the database name specified in the event will generate an alert.
Which target variables will be available for expressions and alert descriptions
Variables that resolve to the value of a property of the target object may be used in the alert description or in an expression of a monitor or rule. Only properties of the target class and of that class’s hosting parent(s) will be available. In the above example, the criteria of the rule includes the database name which is a property of the target SQL Server 2008 Database class. If another class such as SQL 2008 DB Engine had been used as the target, the database name property would not have been available.
Which object health state, alerts, and collected data will be associated with
Any health state, alert, or performance data generated by a rule or monitor is associated with the object that the particular copy of the workflow was running against. In the above example, SQL 2008 DB Engine could have been used as the target since the rule would have been loaded on any agent running SQL Server 2008. The alert created from the rule though would be associated with the SQL Server itself has opposed to the individual database. This would have a significant affect any notifications, reports, or views specific to the particular object.
In the case of a monitor, the target will determine which object’s health state will be affected. If a monitor measuring the health of a database were targeted at SQL 2008 DB Engine, the state of the SQL Server would be affected, but the state of the database itself would not. An availability report would show that the server was unavailable for the period that the monitor was in a critical state, while the same report executed for the database itself would show no down time. In this case, the monitor would need to be targeted at the SQL Server 2008 Database class in order to set the state for the intended object.
Targeting Groups
While groups can be the target of a workflow, this will most likely not result in the desired functionality. The workflow will not enumerate the contents of the group but will attempt to run against the group object itself. Since groups are managed by the Root Management Server, any workflows targeted at them will be loaded only on that server.
If you want to have a workflow run only against the members of a particular group, you can use the following method.
Create the rule or monitor with a target appropriate for the objects contained in the group.
Disable the rule or monitor by unchecking the Enabled box.
Once the rule or monitor has been created, create an override to enable it for the group.
Viewing Classes and Objects
The Discovered Inventory view in the Operations Console can be useful in selecting an appropriate target for a particular workflow. This view will list all instances of a specified class with its entire set of properties. This shows which instances of the class are managed by different agents, how many instances each agent is managing, and what properties the class has available. Any workflows targeted at the selected class will be run against each of the objects listed in the view. If no instances are listed for a particular class, then none have been discovered on any agents. Any workflows targeted at these classes would not be run.
You can view the discovered inventory for a particular class using the following procedure.
In the Operations console, click the Monitoring button.
In the Monitoring pane, select Discovered Inventory.
In the Actions pane click Change Target Type.
In the Select Items to Target dialog box, select the class to view, and then click OK.
Creating classes
If you are creating a workflow for an application that does not have a management pack, you may need to create a custom class to act as a target. Without such a class, you would need to target a general class like Windows Operating System which would work but would have the negative consequences noted above.
You cannot directly create new classes in the Operations Console. This functionality requires use of the Authoring Console as documented in the Management Pack Authoring Guide. If an application has a Windows service though, then the Windows Service Management Pack Template can be used to create a class that can be used for such a target. This template will identify all agents with the specified service installed and create an object managed by each of these agents. Any workflows targeted at the resulting class will similarly be run by these agents. Use of this template can provide a quick and effective means of providing a class suitable for monitoring for custom applications or packaged applications that do not have a management pack.
See Also
Concepts
Creating Rules
Creating Monitors
Variable Notation
How to Create a Windows Service Monitor
Management Pack Classes