If you think of a management pack as a kind of assembly then the manifest is very similar to an assembly. It defines the identity and version of the MP and also all other MPs that it is dependent on. Any MPs referenced must be sealed and they must be imported to an OpsMgr management group before this MP could be imported. If you want to use MPVerify to verify the contents of this MP, all referenced MPs must be available on your file system somewhere.
Illustration from Altova XML Spy
There are many different type definitions that are used by OpsMgr. Each of these has its own sub section in the Type Definitons section of the management pack.
Illustration from Altova XML Spy
Entity Types
This section defines types of objects to discover and monitor as well as relationships between these types of objects. In this section you effectively define your application structure for what you want to monitor.
Data Types
This section defines types of data that OpsMgr modules can use and pass between each other. The data type is a pointer to a native or managed implementation. For OpsMgr 2007, it is not possible for ISV’s or customers to extend the data types available in OpsMgr so this section would not be used.
Schema Types
If you define a new module type of monitor type, you must define the schema for that type. When the type is used the configuration provided must validate against the schema you specify. If schema elements are going to be used across multiple modules then it is easier to define the schema elements once and then reference those in multiple modules.
Module Types
Module types define the core monitoring capabilities of the OpsMgr product. In MOM 2005. There were a set number of types of monitoring out of the box e.g. you could monitor from the event log, WMI, perfmon etc. OpsMgr 2007 is an extensible monitoring platform. This means new types of monitoring can be plugged in at any time and existing monitoring definitions can be customized to suite your needs. The OpsMgr team defines the out-of-the box monitoring in a number of system libraries that are imported during setup. There are three types of module types
· Native
· Managed
· Composite
At this point we do not support adding new native and managed code module types. This may change in the future. However it is possible to define new composite module types that combine other modules in different workflows. Module types come in four types and this is explained more in the concepts section.
· Data Source
· Condition Detection
· Probe Action
· Write Action
Monitor Types
Monitor types use module types and define workflows out of them. When you create a monitor to monitor the state of a particular aspect of your application it uses a monitor type. Monitor types define the states that the monitor can be in and the conditions that cause each state. Optionally it can also define on demand detection so when reset is called the monitor can recalculate its current state without waiting for the next instrumentation to appear.
The monitoring section is where you use the types defined earlier in the management pack (or other reference management packs) to actually define the monitoring you want.
Illustration from Altova XML Spy
Discoveries
A discovery is a workflow that discovers one or more objects of a particular type. A discovery can discover objects of multiple types at one time. A discovery uses a single module that must be a data source module type.
Rules
A rule is a generic workflow that can do many different things. For example it could collect a data item, alert on a specific condition, run a schedule task at some specified frequency etc. Rules do not set state at all. They are primarily used to collect data to show in the console or reports and to provide stateless alerting. A rule is made up of one or more data source modules, zero or one condition detection module and one or more write action modules.
Tasks
A task is a workflow that is executed on demand and is usually initiated by a user using the OpsMgr console. It is not loaded by the HealthService until required. A task consists of a single probe action or write action module.
Monitors
A monitor is a state machine and ultimately contributes to the state of some type of object that is being monitored by OpsMgr. A monitor is one of three types:
· Aggregate (Internal roll up)
· Dependency (External roll up)
· Unit monitor
When a unit monitor is used it is defined from a specific monitor type. The monitor type defines the possible states and the monitoring logic.
Diagnostics
A diagnostic is an on demand workflow that is attached to a specific monitor. The workflow is either initiated automatically when a monitor enters a particular state or is initiated on demand by a user when the monitor is in a particular state. Multiple diagnostics can be attached to a monitor if required. A diagnostic should not change application state.
Recoveries
A recovery is an on demand workflow that is attached to a specific monitor or a specific diagnostic. The workflow is initiated automatically when a monitor enters a particular state or when a diagnostic has run, or on demand by a user. Multiple recoveries can be attached to a monitor if required. A recovery changes application state in some way.
Overrides
Overrides are used to change monitoring behavior in some way. There are many types of override available:
· Category
· Monitoring
· Rule Configuration
· Rule Property
· Monitor Configuration
· Monitor Property
· Diagnostic Configuration
· Diagnostic Property
· Recovery Configuration
· Recovery Property
· Discovery Configuration
· Discovery Property
Normally it is a customer work item to set overrides based on their environment not a MP Author. However there are some situations where it may be appropriate to define in a vendor created MP.
Templates are provided so that a user can walk through a wizard to define a set of monitoring. The template can created any number of MP elements based on the user input.
Illustration from Altova XML Spy
Templates do not define any monitoring until they are executed by the user or programmatically. Templates appear in a number of places in the OpsMgr console
· Management Pack Templates
· Rules Wizard
· Task Wizard
This section defines types that will be used by the OpsMgr console. Not all of these are extensible to the MP Author at this time:
View Types
When you create a new view in the monitoring space of the OpsMgr console you see a list of view types e.g. state view, event view, perf view. These view types are defined in management packs although the code is shipped with the console assemblies. We are currently not exposing the ability to create your own view types in OpsMgr 2007.
Images
A new image can be shipped with a management pack and shown in the console when a object of a particular type is shown to the user. So if you define a new class of object you may want to add images so that your object is easily recognizable, particularly in the diagram view.
UI Pages
All the wizard pages and property pages you see when you create a new object or bring up the properties of an object in the authoring space are defined in management packs. As with view types we are not currently exposing the ability to create your own UI pages in OpsMgr 2007.
UI Page Sets
A UI Page Set defines a flow of UI pages that should be used for a particular wizard or property page set. This page set can optional specify transformations for data when it is presented on pages and when it is saved as config. If you create your own composite module types and monitor types you may wish to build a page set out of the pages that we ship as part of the product.
The presentation section controls what the user will see in the Operations Console.
Illustration from Altova XML Spy
Console Tasks
Defines a task that runs on the computer the console is running on. This is different to a task in the monitoring section that is sent to the agent to be run.
Views
Views are defined of a specific view type and use criteria specific to the type of view being created. Views do not show up in the console until they are added to a folder.
Folders
Folders are used to organize the presentation of information in the console. They are used for:
· Views
· Rule and Task Wizard
· Unit Monitor Wizard
· Management Pack Templates
Folder Items
Folders are empty until items are added to them. This is done using a folder item that refers to the folder and the MP object that should be added.
Image References
An image reference ties an image and a type together. Usually they are used to attach one or more images to a particular class.
String Resources
String resources are used when a module or monitor needs to insert a localizable string. Since all localizable content is held in the language pack section of the management pack a string resource is used as a placeholder. When the information is presented in the console, it is substituted with the correctly localized text.
The main use of these strings is for alert name and descriptions on rules and monitors.
This section defines all things to do with reports.
Illustration from Altova XML Spy
Everything up to this point in the management pack has no localizable content in it. While localization is not a concern for many MP authors, if you are a vendor releasing to customers you may need to think about it. By keeping this section separate it is possible to ship multiple languages in a single management pack. For example a rule could have an English, French and German display name and description in the same MP. When the rule is shown in the console, the correct strings are shown depending on the locale of the console.
Language Packs consist of display strings and also knowledge articles.
Illustration from Altova XML Spy