Management Packs
You can build a Service Model and Health Model by defining targets and creating monitors, rules, tasks and reports. These are all contained in a management pack for that application. When imported into Operations Manager, the management pack describes the application and tells Operations Manager how to discover and monitor it. Operations Manager is not aware of an application until its management pack is imported.
When you import the Active Directory management pack, you are importing a set of rules, discoveries, monitors and tasks, all of which provide Operations Manager with a view of how Active Directory works, and what is important to monitor in Active Directory.
Rules
Management pack rules collect data from various sources, such as Perfmon, EventLog, SNMP, and log files. That data is then stored in the Operations Manager database or Data Warehouse and can be used for reporting purposes. Optionally, for backward-compatibility reasons, some rules can generate alerts that are based on the collected monitoring data.
Targeting information tells Operations Manager on which agents and components to run rules to gather monitoring information. Rules always target classes; for example, you might target a rule to all SQL Server 2005 databases or to all Windows Server Operating systems. You should not target rules to groups; for additional information on targeting, see Changes Between Microsoft Operations Manager 2005 and Operations Manager 2007.
Monitors
Monitors are used to determine the health state of an application component and are integral part of the health model. Generally speaking, monitors are the "intelligence" of Operations Manager. They look at monitoring information and determine whether the application is healthy.
Monitors are state machines that can either be in one of two states (green or red) or in one of three states (green, yellow, and red). The monitor's state changes in response to the monitoring information that the monitor is using. For example, a monitor can be defined that captures the following information:
-
If a disk drive is over 90 percent full, the state is red and the disk drive requires investigation. To indicate this, an alert is generated.
-
If a disk drive is over 85 percent full, the state is yellow, but the situation does not require an operator's attention.
-
If a disk drive is less than 85 percent full, the state is green and the disk drive is healthy.
Although monitors and rules both collect monitoring data, the collected data is used very differently. Rules collect data that goes into either the Operations Manager database or into the Data Warehouse database. In contrast, monitors evaluate data from various instrumentation sources and only store state changes and alerts in the Operations Manager database and Data Warehouse. Monitor-collected data is never stored in the Operations Manager database or Data Warehouse and does not display in reports.
Consider the following scenario: You want to monitor memory usage on a server, generate an alert when it reaches a certain threshold, and have data available later so that you can report on memory usage over time. To implement this scenario, you need to do the following:
-
Create a collection rule to collect memory information for reporting.
-
Because collection rules do not generate alerts, you also need to create a unit monitor that monitors memory health and generates a health state change and an alert after the available memory crosses a threshold you define.
Types of Monitors
There are three different types of monitors in Operations Manager:
-
Unit Monitors
-
Aggregate Monitors
-
Dependency Monitors
Unit Monitor
Unit monitors, the fundamental monitoring components, are used to monitor specific counters, events, scripts, and services. You have the option to set the monitor to generate an alert.
Aggregate Rollup Monitor
An aggregate rollup monitor reflects the state of unit, dependency rollup, or other aggregate rollup monitors targeted to an object. You typically use an aggregate rollup monitor to group multiple monitors into one monitor and then use that monitor to set the health state and generate an alert.
Each target in Operations Manager 2007 contains the following top-level aggregate rollup monitors that you can use to group monitors of similar type for reporting purposes:
-
Availability
-
Configuration
-
Performance
-
Security
Dependency Rollup Monitor
A dependency rollup monitor rolls up health states from objects linked by either a hosting or a containment relationship. Hosting and containment relationships for a given target are defined in most Management Packs. A dependency rollup monitor can be used to make the health state of a particular object dependent on the health state of components that are either hosted or contained.
Dependency Monitors: Linking Health Models to Service Models
Operations Manager uses dependency monitors to implement the idea that when enough of one layer changes state, the layer above should change state.
Dependency monitors allow you to use a hosting or containment relationship to relate the state of one object (such as a hosted object) to the state of another object (such as a hosting object). Consider the following SQL Server model:
.gif)
There are two objects in the service model—a SQL Server 2005 object and a SQL Server 2005 Database object. These objects are in a hosting relationship; the server object hosts the database object. Each object has an associated set of monitors that monitor health aspects of the object.
.gif)
The dependency monitor allows health to roll up over the hosting relationship from the SQL Server Database object to the SQL Server object. Therefore, if the SQL Server Database object turns red, the information captured by the red state can indicate that the SQL Server object also must be red. For example, if the master database goes offline, this can affect the health state of the SQL 2005 database engine.
Interaction Between the State of a Monitor and Alerts
When an application needs attention, Operations Manager generates to-do items for administrators. These are called alerts, and they can be generated when a monitor changes states. When you get an alert in the console, it is an indication that a state change occurred requiring operator attention. Alerts are also used to notify operators who might not be looking at the console.
Using Diagnostic Actions and Recovery Actions
When a monitor changes state from a healthy (green) state to a warning (yellow) or critical (red) state, information is stored in the monitor about the cause of the state change. This information can be used for both manual and automatic diagnostic and recovery actions. To set diagnostic and recovery actions, click a monitor in the Health Explorer and select Properties.
When you create a diagnostic or recovery action, you have the following options:
-
The action runs automatically or requires an operator to run.
-
Running the action resets the monitor health to green.
.gif)
Some actions are better suited for running automatically than others. For example, if a disk is over 90 percent full, consider automatically running a task to delete temporary files on the drive to avoid requiring an operator to attend to the situation.
However, some actions should not be run without operator intervention. If a monitor changes to red when the CPU is over 90 percent utilized, a reasonable recovery action might be to halt the top five processes. Depending on what the computer being monitored is used for, you might not want for this recovery task to be done automatically. Instead, you might want to require an operator to check whether halting the top five processes is acceptable before running the task.
Tasks
A task is a user-initiated action from the Operations Console that is run on an Operations Manager agent. Which tasks are available depends on which management packs are installed. For example, Operations Manager comes with a core set of functionality that gives you the ping task. When you install the SQL Server management pack, it comes with a set of SQL-specific tasks, such as a task to start or stop the SQL Server agent. As with monitors and rules, tasks are targeted to classes. For example, the ping task is targeted to the Windows Computer class.