Applies To: System Center Operations Manager 2007
The process of defining a set of views starts by determining a set of each kind of view to provide a complete view of the health and availability of the managed application. After the required views are defined, you can determine a folder structure to organize the views.
The following are recommendations for when each kind of a view should be included in a management pack.
State views are the most important views to include in most management packs because they include a listing of the objects that are being managed. You can right-click the object in the Operations console and access all of the other kinds of views. However, these standard views only display information for the selected object. Custom views of each type can display information for multiple objects, and most management packs typically include a variety of other kinds of views in addition to State views.
A State view is typically defined for each class that is defined in the management pack. If multiple classes use the same abstract base class, a State view for the base class lists all instances of classes inheriting from it. This is useful if all these objects have to be viewed together. If not, you can create a separate State view for each class.
Any management pack that creates alerts from rules or monitors should have an Alert view that includes alerts just for the application. The criteria for this view typically are alerts that are not resolved (ResolutionState not equal to 255).
If the management pack collects events, it should have at least one Event view. The view should have criteria specific to a particular event. Event views with very general criteria can be inefficient and place an excessive load on the root management server. It is more efficient to have multiple views retrieving different, specific sets of events.
A Performance view can include multiple counters or a single counter. The data typically is available for multiple managed objects of the same class. It is a common practice to provide a single view with all performance counters for each significant class in the management pack. This lets the user analyze a variety of counters. In addition, you should create a separate Performance view for any performance counters that are especially important. A view typically is not created for every performance counter that the management pack collects because some might not be especially useful on a daily basis. You should define a separate view for important performance counters and let the others be available through more general Performance views.
While you can combine multiple performance counters in a single view, it might not be an effective strategy. Different counters that do not have similar values might not display well on the same graph. In this case, combine separate views for each counter into a Dashboard view. This still gives you a single view for related performance counters but uses a separate graph for each.
Because Diagram views are applied to objects instead of classes, they are less important to include in a management pack. A Diagram view is available for any managed object from a State view. There is no concept of a Diagram view for multiple instances of a class like the other kinds of views.
Diagram views are typically created for top-level objects in an application such as a distributed application. This provides a graphical representation of the health of the application itself as it is comprised of the health of its different components.
Task Status Views
A management pack with tasks typically includes at least one Task Status view to track when tasks are run.
Dashboard views are useful in combining related views. They usually are views related to a particular application element. For example, multiple performance views might be combined into a single Dashboard view to provide a complete view of the overall performance of an application. Different kinds of views can also be combined such as a State view that displays instances of a particular class that has an Alert view of listing the alerts associated with the same class.
Recommended Folder Structure
All management packs should have a single top-level folder with the name of the application. For a simple application, this might be the only folder that contains all views for the application. Complex management packs can benefit from multiple folders. They still have a single top-level folder together with all other folders created below it.
The following are common reasons why management packs use multiple folders:
If an application has a separate management pack for different versions, a separate folder can be created for each. Each of these folders would contain a similar folder structure and set of views for each version.
For example, the Active Directory Server Common Library management pack includes a top-level folder named Microsoft Windows Active Directory. This contains views and folders that are common to all versions of Active Directory. The views are targeted at abstract classes that the classes for the different versions use as a base class. The management pack for each version has its own folder underneath the Microsoft Windows Active Directory folder. This folder has a name specific to the version of Active Directory, such as Active Directory Server 2008. Each version-specific folder contains the same set of views and folders that use each targeted at classes specific to that version.
An application that has different services might use a separate folder to organize views specific to each service.
For example, the SQL Server management pack has views for different components of SQL Server such as databases, the SQL Agent, and replication. Folders are created for each of these to hold the views targeted at each class. This enables different operators to focus on the information for the application elements that they are interested in.
A management pack with many views might use folders to organize a set of folders of a particular type.
For example, the Microsoft Windows DNS Server 2008 management pack has many Event views for the different application events that it collects. Instead of putting these in the top-level folder together with views that contain more critical information, the management pack has an Events folder to hold the views.