Defining Discoveries
適用於: System Center Operations Manager 2007
After a set of classes and relationships is defined for an application, a method of discovering each must be defined. No instances of a class will be available for monitoring in Operations Manager until they are discovered.
Identifying Discoveries for Each Class
There are three basic questions that must be answered for each class requiring discovery.
What source or sources hold the data required to determine whether an instance should be created and to populate its properties? This defines the kind of discovery.
What agent hosts the required data source? This defines the target of the discovery.
How frequently should the discovery be run? This defines the interval of the discovery.
Basic Discovery Strategy
The discovery process for an application model composed of multiple classes will typically be performed in multiple steps, with each step including one or multiple discoveries. A basic set of classes is first discovered to identify the agents where the application is installed. These classes act as targets for successive discovery of other classes.
For the basic model described in Defining Classes and Relationships, discovery can typically be performed in three basic steps.
Discover application role classes to identify those agents with the application installed. This is typically performed with registry discoveries targeting a broad class, such as Windows Operating System.
Discover application components hosted by each role. This is typically performed with WMI or script discoveries targeting the hosting role class.
Populate groups. This is typically performed with group population discoveries targeting the group classes themselves.
Application Roles
The first step in the discovery process for an application model with multiple classes is typically to identify which agents the application is installed on. Because application installations are identified by the application role classes based on the Windows Computer Role class or the Windows Local Application class, these are typically the first classes discovered.
These discoveries will typically target a broad class, such as Windows Operating System, because the application could be installed on any computer in the environment. There is no way to know which computers the application is installed on until the discovery runs. If the application can only be installed on a particular version of Windows or if it can only be installed on a server or a client operating system, a slightly more refined target could be used. Examples include the Windows Server Operating System class for an application that could only be installed on a server or the Windows Server 2008 class for an application that could only be installed on a computer that is running Windows Server 2008.
Because discoveries of application roles are targeted at such a broad class, only registry discoveries should be used because they consume minimal resources. A heavier kind of discovery, such as a script, would put an unnecessary load on multiple computers that do not have an instance of the class being discovered. For most applications, a registry key is sufficient to at least confirm that the application exists. If certain properties must use another data source, such as a script, an additional discovery for the same class could be added that targeted to the class itself. This would guarantee that the more resource-intensive process runs only on those agents where it is required.
Application Components
After the application’s roles are discovered, the newly discovered objects can be used as targets for discoveries identifying application components. These classes are typically hosted by one of the application’s roles so that the hosting parent class can be used for the target. In addition to making sure that the discovery only runs on those agents where instances of the class being discovered are likely to be located, using the hosting parent as a target provides access to the hosting parent class’s properties by using $Target variables.
For example, suppose that a class named MyLocalApplication hosts a class called MyApplicationComponent. When an instance of MyApplicationComponent is discovered, it must provide a value for any key properties of MyLocalApplication because that is the class’s hosting parent. If the discovery for MyApplicationComponent targets MyLocalApplication, the discovery has access to all the properties of MyLocalApplication by using $Target variables.
Discoveries for application components typically use either WMI or script discovery. Registry discovery can be used if information about the application is stored there, but frequently another data source is required for this information. If a WMI provider for the application is available and the discovery does not require complex logic, a WMI discovery can be used. If more complex logic is required, a script can be used to access information from the registry, WMI, or any other data source that can be accessed from a script.
Group Population
After all other classes are discovered, group population may be performed because this discovery uses instances and properties that have already been discovered. Group population discoveries target the group class itself. Because groups are unhosted, they are managed by the Root Management Server. Any discoveries targeted at a group class will run on the RMS. This is appropriate because this is where group population discoveries are required to run so that the discovery can access information in the Operations Manager database.
Discovery Intervals
Most discoveries are run at set intervals, and this interval must be specified when the discovery is created. If the interval is too long, the user may have to wait an extended time until new instances or changes to existing instances are discovered. For example, a particular discovery for an application may be configured to run one time every 24 hours. When a new copy of the application is installed on a computer, it may take that long until the new instance appears in Operations Manager 2007 and monitoring begins.
Too short a time interval puts too much overhead on agents while providing minimal value. Also, if instances of the discovered class are expected to change frequently enough to warrant an aggressive discovery schedule, the design of the class may violate the best practices for classes as described here.
The following table provides recommended intervals for different kinds of discoveries.
| Discovery Type | Minimum Interval | Comments |
|---|---|---|
Registry |
5 minutes |
The interval for registry discoveries can be set very low with minimal effect, assuming that properties of the discovered objects rarely change. Because registry discoveries typically discover classes that change so rarely however, an interval of as much as 24 hours is often used. |
WMI Query |
4 hours |
Avoid the use of wildcard characters (*) in the query to return all properties. Should not be targeted at a broad class, such as Microsoft Windows Operating System. |
Script |
4 hours |
Should not be targeted at a broad class, such as Microsoft Windows Operating System. |