Targets

適用於: System Center Operations Manager 2007

Every monitor, rule, task, and discovery in System Center Operations Manager 2007 must have a target class. This is typically a class that is defined in the service model for the application but may be another general class such as Windows Operating System.

Effects of a Target

The target of a workflow has the following effects:

• Which agents the management pack is delivered to

• Which agents the workflow will run on and how many copies of it will be loaded

• Which target variables are available to the workflow

• Which object health state, alerts, and collected data will be associated with

Each of these topics is discussed in detail in the following sections:

Which agents the management pack is delivered to

When a management pack is installed or changed, it is delivered to any agent that manages at least one instance of a class that is used as a target on at least one included workflow. Workflows targeted at classes that have instances on the agent are not loaded. However, the complete management pack must be delivered to the agent.

Management pack delivery

Which agents the workflow will run on and how many copies of it will be loaded

As soon as 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, 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.

Workflow targeted at a single instance

The number of copies of the workflow that can be expected on any given agent must be accounted for when you define the workflow. Each copy of the workflow runs independently and includes its own set of variables. If a particular rule or monitor can potentially 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.

Workflow targeted at multiple instances

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 a single instance class based on Windows Computer Role or Windows Local Application and use the Event Source and Event Number to specify the desired event. This typically works as expected because there will always be only a single instance of the target class 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 that has multiple instances on an agent, however, a separate alert would be created for each copy of the rule in response to the single event. In this second case, a $Target variable would have to be included in the rule’s expression to specify which copy of the workflow should generate the alert.

To show this example, the SQL Server 2008 Monitoring management pack includes a rule named Script : Failed to login that indicates that a monitoring script could not log on 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 the Microsoft SQL Server 2008 Database class 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 because 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 they are loaded by the agent so that only the copy of the rule matching the database name that is specified in the event will generate an alert.

Which target variables are available to the workflow

A workflow has access to $Target variables for the properties of its target class and any of that class’s parent classes. If the workflow is targeted at a class based on Windows Computer Role for example, then properties of the Windows Computer class such as PrincipalName and IPAddress are available to the workflow since Windows Computer hosts Windows Computer Role.

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 earlier example, SQL 2008 DB Engine could have been used as the target because 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.

With 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. However, 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, whereas the same report executed for the database itself would show no downtime. In this case, the monitor would have to be targeted at the SQL Server 2008 Database class in order to set the state for the intended object.

Targeting Groups

Although 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 try to run against the group object itself. Because 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:

1. Create the rule or monitor with a target appropriate for the objects that are contained in the group.

2. Disable the rule or monitor on the Options tab of its Properties dialog box.

3. As soon as the rule or monitor is created, create an override to enable it for the group.