Operations Manager Management Pack Authoring - Classes and Relationships
This document is part of the Operations Manager Management Pack Authoring Center.
Classes
The main element of a service model is a class. This represents some object being managed. It could represent a computer, a database, a service, a disk, an application, or any other kind of object that requires monitoring. A management pack may define any number of classes to represent the application it is monitoring in addition to using existing classes in other management packs and management pack libraries.
Each monitored object that appears in the Operations console is an instance of a particular class. All instances of a class have a common set of properties and a common means of being monitored. Each of these instances is created by a discovery that uses logic specific to the particular class to identify the instances and collect the values of their properties.
Properties
All instances of a particular class will share a common set of properties. The values for these properties are provided by discoveries and can vary among different instances. Properties are used to represent details of the object, such as a unique name, configuration settings, and other details that may be interesting to the user or that are required for monitoring scenarios.
Key Properties
A key property uniquely identifies each instance of a particular class. If a property is marked as a key property, each instance of the class must have a unique value, and the value may not be null. For hosted classes, the value must only be unique for all instances of the class that have the same hosting parent. For unhosted classes, it must be unique for all instances of the class in the management group. Hosting relationships are discussed more in the Relationships section.
Classes do not always require a key property. A key property is only required if more than one instance of a class is expected for a single parent. If only a single instance is expected, a key property is not required but may still be defined.
For example, SQL Database Engine has a key property of Instance Name because a single computer can have more than one instance of SQL Server installed. When there are multiple instances on a particular computer, each instance must have a different value for Instance Name in order to clearly distinguish between the different objects. The IIS Web Server class, by contrast, does not define a key property because there can be only one instance installed on any computer.
All objects have a Path Name property that is calculated from the object’s key property or properties and those of its hosting parent(s). For unhosted objects, the Path Name will be the key property of the class itself. The Path Name can be used to uniquely identify any instance of a class in the management group.
Base Classes and Inheritance
Every class must specify a base class that identifies an existing class that the new one will specialize. The management pack libraries that are included with Operations Manager contain several classes that can be used as the base for custom classes in management packs. A management pack will typically have at least one class inheriting from a library class and potentially other classes inheriting from classes in the same management pack.
The concept of a base class can be illustrated with the Windows Server Operating System management pack. This management pack includes classes representing logical disks installed on the agent computer. The following diagram shows the classes Windows Server 2003 Logical Disk and Windows Server 2008 Logical Disk. These classes are both based on Logical Disk (Server) that is defined in the Microsoft.Windows.Server.Library mp file. Logical Disk (Server) is in turn based on Logical Disk, which itself is based on Logical Device, and so on through Logical Hardware, Logical Entity, and finally Entity. All classes can trace a similar inheritance path and will always end up at Entity, which is the root of the class structure in Operations Manager. This is the only class that does not have a base class, and all other classes eventually inherit from it.
Entity has a single property named Display Name. This is inherited by all classes inheriting from it. All classes eventually inherit from Entity. That is why all classes have a Display Name property. No other classes in this example have properties until Logical Device, which defines Name, Description, and DeviceID. DeviceID is specified as the key property. These properties are all inherited by Logical Disk and Logical Disk (Server). Logical Disk (Server) then adds the additional properties Size, Drive Type, and File System. The bottom-level classes that are specific to the version of operating system inherit the entire set of properties provided by those classes above them in the inheritance tree. This concept is illustrated in Viewing Classes in the Consoles.
In addition to inheriting its properties and relationships, any monitoring targeted at a class will be inherited by any other classes that use it as a base. Additional monitoring and discovery can be added to the new class, and any management pack objects targeted at the new class will apply only to the new class and not the base class.
Class Types
Most classes have one or more instances identified and created through the discovery process. These are also known as concrete classes because they actually have instances. Abstract classes and singleton classes are special kinds of classes that behave differently and are used for particular scenarios.
Abstract Classes
Abstract classes have no instances and exist only to act as a base class for other classes. All properties and relationships that are defined at the abstract class level are inherited by child classes and do not have to be defined again. Any monitoring objects targeted at the abstract class are similarly inherited by lower-level classes. Most of the classes that are defined in management pack libraries are abstract, since they are only provided to act as base classes for classes that are defined in custom management packs.
Abstract classes are used where there is a common set of properties, relationships, monitoring, or grouping that can be defined across all further specializations of a class. In the previous example, all of the classes shown above Windows Server 2003 Logical Disk and Windows Server 2008 Logical Disk are abstract. They exist only for the lower-level classes to inherit from.
Singleton Classes
Singleton classes are used when there is one and only one instance of a class. The class is the instance and always exists. No discoveries can be defined for singleton classes. Their single instance is instead being created when the management pack is installed. Similarly, a key property is not required for a singleton class, since it will only ever have a single instance. Common uses of singleton classes are for Groups and Distributed Applications, because there is only a single instance of these classes required throughout the management group.
Relationships
Relationships are defined between classes to indicate an association between a particular instance of one class and the particular instance of another. There are three types of relationship as listed below and detailed in the following sections.
- Hosting relationship
- Containment relationship
- Reference relationship
Hosting Relationship Type
The most important and most restrictive relationship between classes is the hosting relationship. A class hosted by another class is called a hosted class, and an instance of the class is called a hosted object. If a class is not hosted by another, it is called an unhosted class, and an instance of the class is called an unhosted object.
When one object is hosted by another, that object relies on its hosting parent for its very existence. If the hosting parent is removed, the hosted child will also be removed. For example, a logical disk cannot exist without the computer that it is installed on. Therefore, the Logical Disk class is hosted by the Windows Computer class. This means that every instance of the Logical Disk class must have an instance of the Windows Computer class to host it. If a computer is removed from the management group, any instances of the Logical Disk class hosted by it will also be removed.
A hosted object can have only one hosting parent, but one parent can host multiple children. For example, a particular disk can be installed on only a single computer, but one computer can have several disks installed.
Hosted objects are affected by their hosting parents in the following ways:
| Identity | As described in Classes, an object is identified by its key property. If the object is unhosted, the value of its key property must be unique for the whole management group. For hosted classes however, the key property value must be unique only for all objects that have the same hosting parent. To uniquely identify a hosted object, the key property of both the object and the object’s parent are required. For example, the key property of the Logical Disk class is Device ID. Every computer in a particular environment will have a logical disk that has a Device ID of C: and possibly several other common disk letters. Because every disk object requires a unique value for its key property, the Logical Disk class cannot be unhosted. It is hosted by the Windows Computer class that has its own key property of Principal Name, which is the computer’s name. The key property only has to be unique for the hosting parent. In this case, this means that the Device ID only has to be unique for each computer. This makes logical sense, because a particular computer cannot have two disks that have the same Device ID. The path for each Logical Disk instance will be the computer name followed by the Device ID, as shown in the previous diagram. |
| Managing Agent | If an object is hosted, it will be managed on the same computer as its hosting parent. If it has an instance of the Windows Computer class as a hosting parent (meaning that the object’s class is either hosted directly by the Windows Computer class or has the Windows Computer class somewhere in its tree of hosting parents), the object will be managed by the health service on that computer. For example, the Logical Disk class is hosted by the Windows Computer class. This means that each Logical Disk object will be managed on the computer where the disk is installed. If an object is unhosted, by default it is managed by the agent on the Root Management Server. For example, groups are unhosted classes, and any monitors or rules targeted at a group are run on the RMS. |
| Available Properties |
Any workflows targeted at a class have access to that class’s properties in addition to the properties of any of its hosting parent(s). For example, a script in a monitor using the Logical Disk class as its target might require the name of the computer. Because an object can have only one hosting parent, we know the computer that hosts any particular instance of the Logical Disk class. The monitor can access the properties of the targeted object and the properties of that target’s hosting parent. |
The SQL Server management pack provides another example of hosting relationships. The hosting relationship between the Windows Computer class, the SQL 2008 DB Engine class, and the SQL 2008 DB class is shown here.
The SQL 2008 DB Engine class represents an instance of SQL Server 2008 installed on a particular computer. Because a database can be installed on only a single database engine, the SQL 2008 DB Engine class hosts the SQL 2008 DB class. There can be several databases with the same name in a management group, but any databases installed on a particular instance of the SQL Server class must have a unique name. The database engine, in turn, is hosted by the Windows Computer class. There can be several SQL Server instances with the same name in a management group. Each one on a particular computer must have a unique name.
Because there are two hosting relationships, the path name for each database will be the computer name followed by the instance name followed by the database name. An example is shown in the following diagram.
Containment Relationship Type
The containment relationship type is less restrictive than the hosting relationship. It declares that one class is related to another class, although one is not required for the other.
Containment relationships are typically used for one of two purposes:
| Health rollup |
Dependency monitors mean that the health of one object depends on the health of another object and can be associated with either a hosting or a containment relationship. If one object depends on the health of another, but the two are not in a common hosting relationship, a containment relationship between the two should be created. |
| Group membership |
Objects are included in a group through a containment relationship between the group and the member object. |
Unlike a hosting relationship, a containment relationship is many-to-many. This means that one object can contain multiple objects, and a single object can be contained by multiple other objects. For example, one group can contain multiple objects, and a single object can be a member of multiple groups.
Containment Relationship and Health State:
For SCOM 2012 R2, containment Relationship can be created between the objects managed by the same health service(Management Server or agents) unless the source object is managed by the All Management Servers resource Pool. Groups and classes used for health rollup are typically unhosted. This means that they are managed by the All Management Servers resource Pool so that they can roll up health from objects managed by different agents. A relationship can be discovered between objects managed by different agents, but any dependency monitor and health rollup associated with that relationship will not work as expected.
Reference Relationship Type
The reference relationship is the most general of the available relationship types. A reference relationship is used when the parent and child classes are not dependent on one another; for example, a database could reference another database that it is replicating. One database is not dependent on the other, and the objects are discovered separately. Health rollup cannot be performed across reference relationships.
Should Manage Relationships
Instances of hosted classes are managed on the same agent computer as their hosting parent. Instances of unhosted classes in System Center Operations Manager 2007 are managed on the Root Management Server. Instances of unhosted class in System Center 2012 Operations Manager are managed by the All Management Servers resource pool. This means that the instance is managed by one of the management servers in the pool. There is no guarantee which management server will manage the instance, and it may change to another management server at any time.
There are circumstances where you may want to control the agent that manages a particular instance. In these cases, you can use a ShouldManage relationship to specify where the instance should be managed. ShouldManage relationships are only valid for unhosted classes since an instance of a hosted class must be managed on the same agent as its hosting parent.
When you discover an instance of a ShouldManage relationship using a discovered object as the source of the relationship, the object and any objects that it hosts are moved to be managed on either another agent or resource pool, depending on the type of relationship discovered.
There are two kinds of ShouldManage relationships as described below.
Health Service Should Manage Entity
The Heath Service Should Manage Entity relationship allows you to specify a particular agent that will manage a discovered object. In order to use this relationship, you discover an instance of the Microsoft.SystemCenter.HealthServiceShouldManageEntity containment relationship using the Health Service of the agent as the source and the object as the target. This is typically done with a discovery script. An example of such a script is provided in the MPAuthor.Discovery sample management pack. A portion of this script is provided below.
Set oAPI = CreateObject("MOM.ScriptAPI")
Set oDiscoveryData = oAPI.CreateDiscoveryData(0, SourceId, ManagedEntityId)
Set oUnhostedInstance = oDiscoveryData.CreateClassInstance("$MPElement[Name='MPAuthor.Discovery.UnhostedComponent']$")
oUnhostedInstance.AddProperty "$MPElement[Name='MPAuthor.Discovery.UnhostedComponent']/Name$", sComputerName
oDiscoveryData.AddInstance(oUnhostedInstance)
Set oHealthServiceInstance = oDiscoveryData.CreateClassInstance( "$MPElement[Name='SC!Microsoft.SystemCenter.HealthService']$" )
oHealthServiceInstance.AddProperty "$MPElement[Name='Windows!Microsoft.Windows.Computer']/PrincipalName$", sComputerName
oDiscoveryData.AddInstance oHealthServiceInstance
set oShouldManageInstance = oDiscoveryData.CreateRelationshipInstance("$MPElement[Name='SC!Microsoft.SystemCenter.HealthServiceShouldManageEntity']$")
oShouldManageInstance.Source = oHealthServiceInstance
oShouldManageInstance.Target = oUnhostedInstance
oDiscoveryData.AddInstance oShouldManageInstance
oAPI.Return(oDiscoveryData)
Management Action Point Should Manage Entity
The Management Action Point Should Manage Entity relationship causes an instance to be managed by a resource pool other than the All Management Servers pool. This relationship is only valid in a System Center 2012 Operations Manager management group because this is the first version of Operations Manager that supports resource pools. The object is then managed by one of the management servers in the pool.
Creating a Management Action Point Should Manage Entity relationship is similar to creating a Heath Service Should Manage Entity relationship with the only difference being that the source of the relationship should be an instance of Microsoft.SystemCenter.ManagementActionPointShouldManageEntity.
Practices to Avoid
The following are common practices that should be avoided when defining classes and relationships.
Creating Too Many Classes
Creating too many classes can result in needless complexity with minimal value. A good rule is to use the least number of classes to achieve the desired monitoring results. Other than abstract classes, if a class is not going to be the target of any rules or monitors, it probably should not be created. Also, if two application components are similar, consider modeling them with a single class, possibly by using a property that can hold the values for any differences.
Creating Classes for Volatile Objects
Classes should represent objects that are fairly static. They are created and removed by administrators of the managed computers and not created frequently through automated processes. Examples include an application installed on a server, a database, and a Web site. Generally, a new instance of a class should not be expected most of the times that a discovery for that class runs. Too much volatility can result in excess load on the Root Management Server and lead to error messages from too frequent updates to the Operations Manager database. Other than performance considerations, it is also typically not useful to have health measurements for objects that appear for a short time.
For example, consider a Voice over IP application. You may want to create a class representing a telephone call. A monitor targeted at the class would measure the quality of each call and report an error state if there is a decrease in the quality level of the call. This is a questionable design, because telephone calls are constantly created and destroyed. In fact, discovery for the class would have to be run very frequently; otherwise, most of the calls would never be discovered. For those calls that were discovered, by the time that an administrator was able to respond to a message generated by a monitor, the telephone call would likely have ended.
A better solution for this scenario would be to target monitors at a class created for the application installation on the server. It might be used as a target for a monitor measuring the health of calls and detecting any error events that indicate a problem with a particular call. Any health state would be associated with the application itself, and any alerts could include an identifier for a particular call should a problem are detected.
Properties that Update Too Frequently
Properties should change rarely after they are first discovered. After initial discovery of an object, discovery data is sent from the agent to the Root Management Server only when a configuration change is detected. If properties frequently change, discovery data is sent to the Root Management Server every time that discovery is run and results in excess load. Frequent updating can also affect configuration reports that detect changes in property values.
The most common cause of this issue is a model that stores performance data or health state in a property, which is not a recommended practice. For example, if an object performs some kind of replication, you might consider creating a property to hold the last replication time. But this kind of performance data should not be stored in a property. A better solution would be to collect a numeric value, such as the number of minutes or hours since the last replication, as performance data. This data could be collected with a rule for tracking it on a graph in the console or in a report. A monitor could also be created comparing the collected performance value with a numeric threshold to set the health state according to the time since the last successful replication.