SQL Server Magazine

Imagine a fault-tolerant and scalable Web-based application environment that's simple to administer. Picture yourself relaxing at your desk while your servers manage themselves and report any problems that occur. Microsoft Application Center 2000 facilitates the easy creation of Web clusters and the deployment of applications and COM+ components. The software also provides load-balancing capabilities, balancing loads at the server or component level. And Application Center's inclusion of advanced monitoring capabilities through Microsoft Health Monitor 2.1 provides peace of mind. To start monitoring your clusters and automating responses to events and collected data, you need a detailed analysis of Application Center's monitoring capabilities.

Introducing Health Monitor
Health Monitor collects data and configures actions in response to that data. To create this monitoring and reporting environment, you need to configure four primary components: an action, a threshold, a data collector, and a data group. Together, these components make up a monitor. The data collector defines what information the software collects, and how often. The threshold determines the point at which Health Monitor reacts to that data, and the action is the reaction that takes place. To permit easy management and a reporting hierarchy, the software contains these components within data groups. Let's look closely at these components and how they interact to create a monitor.

Actions. An action must be available before you can apply it in a monitor, so you first need to configure an action. You can choose from five preconfigured actions: Email an administrator, Log to offline.log, Log to websitefailures.log, Take server offline, and Take server online. If none of these actions suit your needs, you can use the following templates to create a custom action:

• Command-line action: You specify a filename and any command-line options.
• Email action: You specify an SMTP server, message, and recipient.
• Text-log action: You specify the name of the .log file and the logged message.
• Windows event-log action: You specify the event type and text of the event that the Windows event log shows.
• Script action: You specify the script's type and name.

Because these custom actions include the execution of command-line instruction and scripting, a broad range of possibilities are available. An action also contains a configurable schedule that lets you determine when the action is available. Therefore, the software can generate specific actions depending on when a condition meets a certain threshold or can prevent an action from occurring at an inappropriate time. You can configure actions at the data collector level, the data group level, and the server level.

Thresholds. You configure a threshold in conjunction with a data collector. The threshold defines the point in the data collection at which a condition triggers (aka fires) an action. For example, the data collector might be collecting information about processor usage. Suppose you've set a threshold at 80 percent utilization. When processor usage reaches 80 percent, the monitor enters a warning or critical state, depending on the threshold's configuration. You can configure an action for either state.

You can specify how many times the threshold must be reached within a specific period of time before the monitor's state changes and the action is fired. This configurable parameter permits spikes in activity that don't represent a problem. Consider the processor example: You probably wouldn't be concerned about 80 percent processor-usage spikes during application deployment or other intensive tasks. However, you would be concerned if processor usage is continually running higher than 80 percent or spiking repeatedly during typical operation.

The software also lets you create multiple thresholds for different levels of processor activity. Therefore, you can separately configure warning behavior and critical behavior.

Data collectors. As you would expect, the data collector collects the data that the monitor uses. A data collector can be a performance monitor, a service monitor, a process monitor, a Windows event-log monitor, a COM+ application, an HTTP monitor, a TCP/IP port monitor, an Internet Control Message Protocol (ICMP) monitor, a Windows Management Instrumentation (WMI) instance, a WMI event query, or a WMI query. Each monitor's configurable parameters depend on the type of data collected. To achieve the functionality you want, you must accurately collect the correct data.

You can assign one or more configured actions and thresholds to a data collector. If a condition meets a threshold, the monitor enters a warning or critical state (depending on the threshold configuration) and the relevant action occurs. When you configure a data collector, you can define the point at which the monitor returns to a state of equilibrium—either when the condition no longer matches the configured threshold or when an administrator manually resets it.

Data groups. A data group is a container that holds configured monitors. It lets you separate your monitors for administrative purposes and lets you establish a reporting and monitoring hierarchy. When a monitor in a particular group enters a warning or critical state, the data group's state also changes, but you can assign different actions to respond to this change. For example, suppose a monitor changes state and experiences the Take server offline action. The monitor's change of state within its data group also changes the group's state, thereby firing the Email an administrator action at the data-group level. The action at the data-group level occurs regardless of which monitor changed state.

Health Monitor lets you nest data groups so that each parent inherits state changes from its child. The monitored server inherits state changes from the top-level data group, so you can configure an action that will take place if any data group changes state.

   Prev. page   [1] 2 3     next page