Monitor Your .NET Applications with Microsoft Operations Manager 2005

  • Article

 

James M. Conard
Microsoft Corporation

February 2005

Applies to:
Microsoft .NET Framework
Microsoft Operations Manager (MOM) 2005 and Management Packs

Summary: Learn about Microsoft Operations Manager 2005 architecture and create custom management packs for your .NET-based applications. (38 printed pages)

Download the associated code sample, Monitoring .NET Apps with MOM 2005.exe.

Contents

Introduction
MOM 2005 Architecture
MOM Editions
Management Packs
Northwind Application
Authoring the Northwind Management Pack
Summary

Introduction

After I moved to Redmond, Washington in August 2004, frequent earthquakes occurred in the immediate area around Mount St. Helens, an active volcano in Washington state. I was interested to learn that earthquakes are not new here; in fact, seismologists have been monitoring this area for decades. According to the Pacific Northwest Seismograph Network (http://www.pnsn.org), Mount St. Helens has experienced over 8,128 earthquakes in the last decade alone and they are still occurring. However, the increased size, number, and frequency of the quakes on September 23rd signified a period of "unrest" for the volcano. Although scientist can't predict when the earthquakes will occur, the data collected by digital seismographs has allowed government officials to issue volcano advisories to warn nearby residents about the threat of potential eruptions. Without today's digital seismographs and modern computer hardware, seismologists would be unable to collect quake information and identify trends.

In many ways, Microsoft Operations Manager (MOM) could be considered the seismograph of a data center. It is designed to allow system administrators to monitor the Windows Server platform, services such as IIS and Active Directory, server products such as SQL Server, Exchange, and BizTalk, and line-of-business applications. Like the seismograph, MOM is designed to monitor and collect events and filter the noise from critical changes in state that might signify a potential problem. MOM also provides the ability to generate alerts and notifications when these events or changes in state occur.

The latest version, MOM 2005, is the second major release of the product. It significantly improves on the fundamentals of the product, including setup, scalability, performance, reliability, and security. MOM 2005 also includes several new features such as State Monitoring, which provides the ability to view the current health state of individual components and the various roles of components that compose a system. For example, a component such as IIS has different roles such as Web server, FTP server, etc. With State Monitoring, the state of components and roles across multiple servers is consolidated into a single view so that system administrators can easily identify and drill into the root cause of problems.

As a developer, Microsoft Operations Manager is a technology that you've probably heard of but not given much thought to. After all, isn't MOM by definition an "operations" technology? Doesn't it only apply to those IT-type guys that deploy and monitor the applications? Yes, MOM is absolutely an operations technology that would typically be used by system administrators within an IT group. However, a manageable solution starts with an application that has been designed and developed for manageability. As the developer, you have more knowledge about your applications than anyone else. You know the expected behavior of your application, when changes in its state occur, and how it surfaces exceptions and tracing information. It is incredibly difficult to communicate this critical information to the system administrators and operations folks that need it to monitor and manage your application.

Microsoft Operations Manager can help address this challenge and help you build manageable solutions through the use of Management Packs. A Management Pack is a set of rules and configuration settings that define how to monitor a system. For example, a Management Pack might include an event rule that monitors the Application Event Log for event records and filters on error events coming from a specific source. The event rule could also specify that an administrator should receive an e-mail when the alert occurs.

By authoring custom MOM management packs, you can capture knowledge about your application and monitoring rules in a structured format that can be deployed with your application. Rather than providing systems administrators with "operations guides" or other static documentation, you can provide them with a MOM Management Pack that can be deployed and used to monitor your application.

In this article we'll learn about the architecture of MOM 2005 and walk through the steps necessary to build a simple MOM management pack for a custom .NET-based application. After reading this article, you will be able to build more manageable solutions by including custom management packs with your applications and hopefully make new friends with "those IT guys".

MOM 2005 Architecture

Before you begin authoring MOM Management Packs, it's important to understand the architecture, tools, services, and general behavior of MOM 2005. From a high level, MOM 2005 consists of the following six components:

  • Management Agents
  • Management Server
  • MOM Database
  • Consoles
  • MOM Connector Framework
  • MOM Reporting

The diagram in Figure 1 illustrates the relationship between these six components. Let's review these components in a little more detail and understand how MOM 2005 works to manage data centers.

Figure 1. MOM 2005 architecture

MOM Agents

A MOM management agent is a service that runs on servers being managed by MOM 2005. The management agent is responsible for monitoring the local machine and collecting operational data from a variety of sources such as event records in the Windows NT Event Log, performance counters, and WMI events. It can also collect information about the hosting machine, such as the version of the operating system, installed service packs, or values in specific registry keys. The data it collects depends on the monitoring rules that are stored in the MOM database after being defined by an Administrator or imported from a MOM management pack. As the data is collected by the agent, the agent performs some preliminary processing based on the configured rules and the data is forwarded to the MOM management server for processing and storage. Depending on the monitoring rules, the MOM Agent can also execute actions such as scripts or .NET code directly on the managed server in response to specific alerts.

MOM Management Server

The MOM Management Server is a designated server within a data center that acts as the central coordinator for MOM 2005. This server hosts the MOM WMI Provider, managed APIs, a local management agent, and two key runtime services: the MOM Service and Data Access Services (DAS). The MOM Service manages the lifecycle of management agents. It manages the install and uninstalls of agents, distributes the monitoring configuration to agents, and the monitors the health and availability of agents through heartbeats. Agents collect operational data and send it to the MOM Service on the Management Server. The MOM Service collects, filters, and consolidates the operational data, processes alerts, executes script or managed code in response to alerts, and finally inserts data into the MOM database through Data Access Services. Data Access Services are a set of COM+ components that facilitate data access operations to the MOM database for both the MOM Service and the consoles.

MOM Databases

MOM 2005 relies on a SQL Server database, named OnePoint, to manage both configuration and operational data. The configuration data includes all information used by MOM to manage systems, including artifacts such as monitoring rules, management scripts, computer attributes, and views used in the Operator Console. The operational data includes all of the "runtime" data collected by MOM agents, such as events and alerts.

MOM Consoles

MOM 2005 includes three different user interface tools that are designed for specific purposes and typically used by distinct roles within an organization.

  • Administrator Console—The Administrator Console is an MMC snap-in that allows a MOM administrator to configure all aspects of a MOM 2005 environment. For example, from this console an administrator can import or export management packs, define and configure monitoring rules, specify managed servers or computer discovery rules, and configure and deployment MOM agents.
  • Operator Console—The Operator Console is a .NET Windows Forms application that provides access to the data collected by MOM agents and stored in the MOM database. This tool is typically used by the systems administrator or IT operator responsible for day-to-day systems monitoring. From the Operator Console users can view events, resolve alerts, and see the current health/state for the systems they are monitoring.
  • Web Console—The MOM Web Console is a simplified, Web-based version of the Operator Console that provides the ability to view and work with a subset of the operations data. An IT operator could use the Web Console to view events, view and resolve alerts, and check system health. It allows operations data to be viewed remotely or in situations where the MOM Operator Console is not installed.

When authoring custom management packs, we will use the Administrator Console to define rules and other management pack artifacts. We will also use the Operator Console to view MOM events and alerts as we test our management pack.

MOM Connector Framework

Most enterprise organizations have at least one existing management platform, if not several. These platforms might include HP Openview, IBM Tivoli, or maybe an earlier version of MOM. Some organizations have "rolled their own" custom management tools. The MOM Connector Framework (MCF) is a set of Web services that can be used to provide bi-directional integration with MOM and other management tools.

MOM Reporting

MOM Reporting is actually a collection of components that together provide the ability to generate reports for event, alert, and performance data collected by MOM. MOM Reporting utilizes SQL Server 2000 Reporting Services as the reporting engine and framework. Consequently, SQL Server Reporting Services is a required prerequisite component for MOM Reporting. MOM Reporting includes an additional SQL Server database called the MOM reporting database. The MOM data warehouse, named SystemCenterReporting, is responsible for storing historical operational and configuration data for reporting and analysis. MOM reporting also provides over 100 predefined reports for the MOM data warehouse. However, since the reporting framework is SQL Reporting Services, you can easily create additional reports against the MOM data warehouse using the SQL Server report designer in Visual Studio .NET 2003.

MOM Editions

MOM 2005 is available in two different versions: MOM 2005 Workgroup Edition and MOM 2005 (Full) Edition. MOM Workgroup Edition is designed to manage smaller environments of up to 10 servers, and the Full Edition can scale up to 4,000 managed servers in a management group. Another significant difference is that the Workgroup Edition does not include MOM Reporting and the MOM Connector Framework.

You are probably wondering which edition to target when building a MOM management pack. MOM management packs are compatible with both editions of the product. The only constraint is if you plan to include SQL Reports with your management pack, the reports can only be used with the Full Edition.

Management Packs

As we discussed earlier, a management pack is a deployment unit that contains the MOM configuration settings and artifacts for monitoring and operating a system. Figure 2 illustrates the contents of a MOM Management Pack.

Figure 2. Management Pack contents

After these artifacts have been defined using the Administrator Console, they are exported into a Management Pack file. The Management Pack file can then be imported into the MOM database for another environment.

The following artifacts are used to monitor systems and process events and alerts:

  • Rules—Rules are the most fundamental artifacts in a management pack. MOM 2005 supports three types of rules: Event rules for collecting, analyzing, and responding to events from a system (or the absence of events), Alert rules for responding to MOM alerts, and Performance rules for collecting and analyzing performance data.
  • Provider Instances—MOM Data Providers enable access to different event sources, such as Windows NT Event Logs, Windows NT Performance Counters, and WMI. Rules contain references to provider instances, which are specific monitoring settings for a MOM data provider. For example, you could have a provider instance named "Audit Events" that would use the WMI provider to execute a query for a specific class of WMI events.
  • Rule Groups—Rule groups are used to categorize similar sets of rules together so they can be targeted to computer groups as a single unit.
  • Scripts—Scripts can be used for a variety of purposes including computer discovery, automated responses to alerts or events, and custom tasks. Scripts and associated metadata are defined using the Administrator Console and stored in the MOM Configuration database.
  • Computer Groups—Computer groups are collections of servers that are managed by MOM. Servers can either be statically assigned to computer groups or they can be dynamically discovered based on server discovery rules and added or removed to computer groups dynamically. Rule groups are associated with one or more computer groups to determine which servers apply the rules.
  • Notification Groups—Notification groups are groups of operator accounts that can receive notifications from MOM. An operator account defines a user that is interested in receiving notifications, along with their operating hours, and available notification methods. The notification methods supported by MOM include e-mails, pages, and external command-line utilities. Rules can reference to a Notification group and trigger notifications in response to an event or alert.

A management pack can also include artifacts that are used to operate a system by enabling administrators to view and act on monitoring data. These artifacts include:

  • Knowledge Base Information —Rule groups, rules, and other artifacts can include specific both product and company-specific information that can help administrators troubleshoot and resolve issues. By including information with rules, for example, a system administrator can view the Knowledge Base information directly in the Operator Console for the rule that caused a specific alert to be raised.
  • Views—Using the MOM Operator Console, users can define custom views of operations data. Views can filter operations data such as events and alerts so that users can isolate and "drill down" on relevant data. For example, a custom view could filter alerts for a specific application that are unresolved, occurred in the last 24 hours, and originated from a specific group of servers.
  • Tasks—Tasks are actions that a system administrator can initiate directly from the MOM Operator Console. Typically tasks are used to collect more information from a system or for correcting a problem. For example, a task could allow a systems administrator using the MOM Operator Console to restart an IIS Application Pool for a specific ASP.NET application on the server in which a corresponding alert occurred.
  • Diagrams—MOM provides built-in diagrams to display computer groups, individual servers, and their state. Management packs can also include custom diagrams to graphically show the health of a system.
  • Schemas & Relationships—The new MOM 2005 state monitoring functionality that we discussed earlier is based on schemas and relationships stored in the MOM database. These schemas and relationships define the roles for servers and components for each role. For example, the IIS Management Pack defines a role named IIS. The IIS role contains specific components, such as FTP, IISAdmin, and NNTP. A custom management pack could define custom roles, components, and their relationships.
  • Reports—As we discussed earlier, using the Full Edition of MOM 2005, custom reports against the MOM reporting database can be designed with SQL Server 2000 Reporting Services, and can be packaged and included with a MOM Management Pack.

A rule group is the only artifact that is explicitly required for a management pack. However, at a minimum, a management pack should also contain rules, provider instances, and computer groups.

Microsoft provides management packs for most Microsoft server products and technologies, including IIS, Active Directory, and SQL Server. Many more management packs are available from Microsoft partners for Microsoft products and non-Microsoft technologies such as SAP, Citrix Metaframe, and Veritas Backup Exec. Before creating your own management pack, it's a good idea to install a few of the Microsoft management packs so you can see how these artifacts are configured and used. You can view a complete list of available management packs and download management packs provided by Microsoft.

Northwind Application

Rather than build a simple command-line or Windows Forms application as the basis for a custom management pack example, we'll use an application that resembles the common characteristics, architecture, and patterns of a "real-world" .NET-based application. The Northwind application provides the ability to view, create, edit, and delete customer account records stored in the Northwind sample database included with SQL Server. Although the scope of our Northwind application is limited, it will serve as a scenario in which we can build on and extend in future articles.

The Northwind application consists of three layers. The user interface layer is an ASP.NET application that contains a few Web Forms for the user to view, create, update, and delete customer records. The Service Interfaces layer consists of a single ASP.NET Web service named AccountService that exposes operations for working with the customer account data. Instead of accessing the Northwind SQL Server database directly, the AccountService relies on a set of components that compose the data access layer. The architecture of the Northwind application is illustrated in Figure 3.

Figure 3. Northwind application architecture

For our example, the Northwind application includes exception-handling logic to catch exceptions and log them to the Windows Application Log. MOM 2005 collects the event log messages using event rules in our custom management pack. Let's take a look at the code in our Northwind application, focusing specifically on an example where the Northwind application logs events that we'll later consume with MOM. The entire source code for the application is included with the download for this article.

Logging Exceptions

There are several technologies available for logging exceptions and adding instrumentation to .NET-based applications. These technologies range from intrinsic classes in the .NET Framework to libraries such as the Enterprise Instrumentation Framework (EIF). To simplify our example and reduce the number of additional dependencies, we'll just use the intrinsic System.Diagnostics.EventLog class. As the name implies, the EventLog class provides the ability to read and write entries into the Windows Event Logs. In the Northwind application, we are using the EventLog class to create error events when an exception occurs within our application.

The following UpdateCustomer method demonstrates how to use the EventLog class. When invoked, the UpdateCustomer method contained in the CustomerGateway data access component is responsible for updating a specific customer record in the Northwind database. This method includes some data validation logic to check the CustomerID for the specified Customer. If the CustomerID is missing or an invalid format, then we'll simply create a new exception of the type System.ApplicationException and throw it up the call stack. The UpdateCustomer method includes a catch block where we'll catch and log any exceptions that occur. When we catch an exception in this method we're simply calling the static WriteEntry method on the EventLog class to create a new entry in the Application event log that will contain all of the information from the exception. Notice that we specify an event source name of "Northwind" and the entry type is an error. Later when we build our management pack, we'll configure MOM to use this event source name and the error entry type to filter events in the Application log.

public void UpdateCustomer(Customer dtoCustomer)
{
   try
   {
      if ((dtoCustomer.CustomerID == null) ||            (dtoCustomer.CustomerID.Length == 0))      {         throw new ApplicationException(            "CustomerID must be specified.");      }      else if (dtoCustomer.CustomerID.Length > 5)      {         throw new ApplicationException(            "CustomerID must be between 0 and 5 characters");      }      
      //Build the query to update a Customer record
      const string const_strUpdateCustomer = 
            "UPDATE Customers SET CompanyName='{1}',"
            + " ContactName='{2}', ContactTitle='{3}', "
            + " Address='{4}', City='{5}',"
                + " Region='{6}', PostalCode='{7}', "
                + " Country='{8}', "
            + " Phone='{9}', Fax='{10}' "
            + " WHERE CustomerID = '{0}'";
      
      object[] objParameters = new object[11];
      objParameters[0] = dtoCustomer.CustomerID;
      objParameters[1] = dtoCustomer.CompanyName;
      objParameters[2] = dtoCustomer.ContactName;
      objParameters[3] = dtoCustomer.ContactTitle;
      objParameters[4] = dtoCustomer.Address;
      objParameters[5] = dtoCustomer.City;
      objParameters[6] = dtoCustomer.Region;
      objParameters[7] = dtoCustomer.PostalCode;
      objParameters[8] = dtoCustomer.Country;
      objParameters[9] = dtoCustomer.Phone;
      objParameters[10] = dtoCustomer.Fax;

      string strQuery = 
             String.Format(const_strUpdateCustomer, objParameters);

      //Execute the SQL Update statement
      SqlHelper.ExecuteNonQuery(
             SqlClientUtil.NorthwindConnectionString,    
             CommandType.Text, strQuery);
   }         
   catch (System.Exception excp)
   {
      //Log the exception to the Application Event Log
      System.Diagnostics.EventLog.WriteEntry("Northwind", 
       "The following exception occured: " + excp.ToString(), 
       System.Diagnostics.EventLogEntryType.Error);

     //Throw the exception back to the caller
      throw excp;
   }
}

Authoring the Northwind Management Pack

Now that we have a simple .NET application to monitor, we can begin authoring our management pack. In order to keep our example simple, our management pack will include a minimal set of artifacts:

  • Rule Group—Single rule group to contain the event, alert, and performance rules for the Northwind application.
  • Event Rule—Single event rule to capture error events that are logged to the Windows Application Log by the Northwind application.

As we discussed earlier, MOM Management Packs can be created using the Administrator Console. The MOM 2005 Resource Kit also includes a tool called the Management Pack Wizard that can be used to generate an initial management pack for monitoring Windows Services and Windows Performance Counters. For this article, we'll use the Administrator Console so we can learn some of the MOM 2005 concepts and terminology as we build the management pack.

Before we create any of the management pack artifacts, we should first turn on the authoring mode in the Administrator Console. Authoring mode allows us to view and set configuration options that are specific for management packs intended for export and deployment into another environment. To enable authoring mode, simply expand the Management Packs node in the tree view in the Administrator Console, right-click the Rule Groups folder in the tree, and select Authoring Mode from the context menu.

Creating the Northwind Rule Group

The first step in creating a management pack is to define a new rule group. Just as it sounds, a rule group is used to group and organize rules into a hierarchy. Every management pack must include at least one top-level rule group. Rule groups are assigned to computer groups to determine which servers will run the contained rules and process monitoring data. Therefore, it's important to carefully design a flexible rule group hierarchy, especially when you're working with hundreds of rules or a complex, multi-tier application.

We'll create a new top-level rule group for the Northwind application. To create a rule group in the Administrator Console, right-click the Rule Groups folder and select New Rule Group. The new rule group wizard opens, as shown in Figure 4. We'll give our rule group a name of "Northwind" and a brief description. By default, rule groups are enabled when they are created. If a rule group is disabled, then all of its contained rules will also be disabled. However, the Enabled flag will not affect any child rule groups or their rules.

Figure 4. Rule Group Properties - General dialog box

The second step in the Rule Group wizard, shown in Figure 5, allows us to enter company knowledge for our Rule Group. There are two different forms of knowledge in MOM 2005: vendor/product knowledge and company knowledge. Vendor knowledge is product documentation that is created by the vendor or the author of the management pack. Company knowledge consists of company-specific notes system administrators might capture based on their experience monitoring the application. This step in the Rule Group wizard is used to capture company-specific knowledge. We'll leave the company knowledge field blank for the Northwind management pack:

Figure 5. Rule Group Properties - Knowledge Base dialog box

Since we're in authoring mode, the third step in the Rule Group wizard allows us to specify how rules within the rule group are exported, as shown in Figure 6. We'll just accept the default setting for the Northwind management pack. With the default setting, all rules in our Northwind rule group that are enabled will be exported; however, disabled rules will not. This is a good setting to use when authoring custom management packs that will be deployed with your applications. By using this setting, we can simply disable any rules that we don't want to include when we export the management pack.

Figure 6. Rule Group Properties - Advanced dialog box

Finally, the last step allows us to enter product knowledge, also known as vendor knowledge, for the rule group. A rule group's product knowledge is captured in three self-descriptive fields: Purpose, Features, and Configuration. As you can see in Figure 7, we'll just enter some basic information in these fields for our Northwind management pack example.

You might have noticed the Generate Knowledge button on this dialog window. MOM will generate an HTML-formatted version of the knowledge information, which is then displayed in the details area of the Administrator Console. Whenever knowledge information is added or changed, the HTML view of the information must be regenerated. However, knowledge cannot be generated when creating a new Rule Group. Instead, the HTML-formatted version of knowledge information can be generated by right-clicking the Rule Group folder from the Administrator Console and selecting Regenerate Knowledge from the context menu.

Figure 7. Rule Group Properties - Knowledge Authoring dialog box

After you click Finish in the Rule Group wizard, you will be prompted to deploy the rules in the new rule group to a group of computers. This is accomplished by assigning the new rule group to one or more computer groups. If you select yes when prompted to deploy the rules, the Rule Group properties shown in Figure 8 will automatically be displayed, where you can add or remove references to computer groups. For our Northwind rule group, we'll add a reference to the Microsoft Windows Servers computer group that is defined by default after installing MOM 2005. Although we're using an existing computer group for this example, it's also possible to define new computer groups and include them with your management pack. For example, we could have defined a computer group named "Northwind Servers" to isolate our event rules to a specific set of servers running the Northwind application.

Figure 8. Rule Group Properties - Computer Group assignment

Creating the Exception Log Event Rule

Now that we have a top-level rule group, we can begin adding the individual rules. To keep things simple, we will create a single event rule to monitor the Application log for any error events logged by the Northwind application. Our event rule will be configured to generate a MOM alert when a new event record is created that matches our criteria. Although we're only going to create one generic event rule in this article, management packs will typically contain dozens or even hundreds of event rules that represent very specific events in a system.

Event rules include several configuration elements, such as a reference to a data provider, filter criteria, an operating schedule, responses, and related system or company-specific knowledge. The required configuration elements and event rule behavior varies with each type of event rule. There are five different types of event rules in MOM 2005:

  • Event—This is a standard event rule that listens for a specific event matching defined criteria and then executes response(s) and/or generates an alert when the event occurs.
  • Filter—Filter event rules are used to filter events and determine if and how they are processed by other rules. A filter event rule can act as a pre-filter and prevent other rules from processing events. Alternatively, filter event rules can be configured to allow other event rules to process, but controls whether or not other matching rules will result in new event records in the MOM operational database.
  • Detect Missing—Unlike standard event rules which are designed to listen for an event, rules to detect missing events are designed to monitor the absence of an event. Rules to detect missing events can generate an alert and/or execute responses if an event is not received by the data provider during the schedule when the event is expected to occur.
  • Consolidation—Consolidation event rules can consolidate multiple events together as a single event record. Consolidation requires that the events must have identical data in key fields and occur within a specified interval. The interval and key fields are configured when defining the consolidation event rule.
  • Collection—Collection event rules simply receive events from data providers and store the events in the MOM operational database. They are very similar to standard event rules; however, they cannot be used to generate alerts or other responses.

We can begin creating a new event rule by right-clicking the new Northwind rules group in the Administrator Console and select Create Event Rule... from the context menu. Select the event rule type from the dialog window shown in Figure 9. Since we want to generate an alert when receiving the error event from the Application event log, we'll create a standard event rule by selecting the Alert on or Respond to Event (Event) option.

Figure 9. Select Event Rule Type dialog box

After selecting an event rule type, the MOM Administrator Console will start the New Event Rule Wizard to collect the necessary information for creating a new event rule. The steps in the wizard will vary based on the type of event rule being created. The first step (Figure 10) for a standard event rule allows us to select the data provider to use for receiving events. As mentioned earlier, the data provider is a configuration artifact in MOM that references to a specific source of monitoring events. We can select an existing data provider that is defined in the MOM configuration database or add a new data provider. In this case, we'll just use an existing provider named "Application", which is configured to monitor the Application Windows NT Event Log. The Application data provider is created by default during the MOM 2005 installation. If our application raised events using a different event target, such as WMI, then we would need to create a new data provider.

Figure 10. Event Rule Properites - Data Provider dialog box

In most cases, we'll want to restrict the data that is received from the data provider so that we only receive the events we care about. In the next step (Figure 11), we can enter matching criteria for common fields such as the event source, event id, type, and description. We can also specify advanced settings to match additional columns. With the Northwind management pack, we're only creating a single event rule that will capture any exceptions logged by the Northwind application. However, in most situations you would want to create separate rules that are much more specific by matching additional fields such as the Event ID. For this event rule, we will simply receive events that have a source of "Northwind" and a type of "Error".

Figure 11. Event Rule Properties - Criteria

The next step (Figure 12) allows us to optionally schedule when the event rule is active. The ability to schedule active times for a rule can be helpful to filter out events in situations where an application might have scheduled operating hours or scheduled outages for system maintenance. We'll use the default setting, Always process data, indicating that we always want this rule to be active.

Figure 12. Event Rule Properties - Schedule dialog box

Since we are creating a standard event rule, the next step allows us to generate a MOM alert when an event occurs that matches our criteria. As shown in Figure 13, when alert generation is enabled we can specify data for the new alert's common properties such as severity level, owner, initial resolution state, alert source, and description. An alert record has five custom fields that can be used to store additional data. By clicking the Custom Fields button in this window, we can populate these custom fields with either static data or data from the original event record.

The Enable state alert properties check box controls whether or not this alert should be reflected in the MOM state monitoring data. Selecting this box allows us to set the alert's severity based on a set of rules and conditions, such as the error number of the event. We could also set the server role, server instance, and component properties for the alert. These properties are used to specify how the MOM state monitoring data should be updated. The topic of state monitoring is an article in itself. To keep our example simple, we're not going to use state monitoring, so we'll leave the Enable state alert properties check box clear.

Figure 13. Event Rule Properties - Alert dialog box

A big challenge with most monitoring tools is filtering through redundant data. For example, imagine the situation where the Northwind application couldn't access its SQL Server database for a couple of hours, and in that time it received 200 requests for customer data. Based on our current scenario, each of those 200 requests would generate an exception that would result in a MOM alert. Rather than having 200 separate alerts with redundant exception and alert information, we could use alert suppression to combine or roll up similar alerts. When using alert suppression, MOM will only generate one alert and then increment the repeat counter for each additional alert that has matching data in key fields. Alert suppression requires that the alerts are generated by the same event rule.

The next step in the rule wizard (Figure 14) allows you to enable or disable alert suppression and, if enabled, select the key fields that must match for alerts to be suppressed. By default, Alert Suppression is enabled and only the Computer and Domain fields are selected as key fields. We'll accept the defaults for our event rule and proceed to the next step.

Figure 14. Event Rule Properties - Alert Suppression dialog box

In addition to generating an alert, an event that matches the filter criteria can also trigger one or more responses. The next step in the event rule wizard for standard event rules (Figure 15) allows us to manage the list of responses. We can add any of the following response types:

  • Launch a script.
  • Execute a command or batch file.
  • Update state variable.
  • Transfer a file.
  • Call a method on a managed code assembly.

Notice that we can invoke managed .NET code for an event response. This is extremely powerful, because our managed code could perform almost any advanced action, such as calling a Web service, clearing an application's data cache, or updating a configuration file in response to an event. For our Northwind management pack, we'll keep the event rule simple and not include any responses.

Figure 15. Event Rule Properties - Responses dialog box

The next step in the wizard allows us to enter any company knowledge for the event rule. As you can see in Figure 16, this is similar to the company knowledge field we saw earlier when creating our Northwind rule group. However, in this case we capture company knowledge for this specific event rule instead of at the group level. Again, this information is typically captured by a systems administrator to supplement the knowledge the rule included with company-specific information. We'll just leave the contents blank for our event rule.

Figure 16. Event Rule Properties - Knowledge Base

The product knowledge associated with the event rule can be captured in the next step (Figure 17). Product knowledge for an event rule is captured in eight separate fields:

  • Summary
  • Causes
  • Resolutions
  • External Knowledge Sources
  • Sample Event
  • Related Events
  • Other Information
  • Internal Comment

The ability to attach knowledge to rules can eliminate the need to provide separate documentation for the rules, which would easily become out of sync with the management pack. Instead, systems administrators can view this detailed, contextual information within the Operator Console while they view events and alerts generated by the rule.

At a minimum all rules should at least include a summary that describes the purpose and behavior of the rule. As you start building more complex management packs and the number of rules increase, it is extremely beneficial to have at least summary-level documentation for event rules. By taking a little extra to include information about the causes, resolutions, and external knowledge sources for a rule, we can save valuable time later when trying to identify and resolve problems with an application. This information can also enable systems administrator to be more self-sufficient.

For our exceptions event rule in the Northwind management pack, we'll enter brief information in the knowledge fields. Like event group knowledge, an HTML view for rule knowledge must be generated before the knowledge information will be visible in the consoles. After we complete the event rule wizard, we need to regenerate the HTML views of the knowledge information for the Northwind rule group.

Figure 17. Event Rule Properties - Knowledge Authoring

Since Authoring Mode is enabled, the next step (Figure 18) allows us to set advanced authoring properties for our management pack. More specifically, we can specify if and how the new rule will be exported when the management pack is exported. We can also mark the rule as deleted. Rules that are marked for deletion are essentially disabled and hidden. They are not processed and not displayed in the Administrator Console, except in authoring mode. In authoring mode, the deleted status for rules can be viewed and changed and rules can be permanently removed from the MOM configuration database.

Figure 18. Event Rule Properties - Advanced

The last step, shown in Figure 19, involves entering a rule name and selecting the enabled status for the rule. The value specified for the Rule Name field will also be used to name any alerts generated by the rule. In this case we'll enter a descriptive name, "Northwind - Receive All Error Events and Generate Alerts", and enable our rule.

Figure 19. Event Rule Properties - General

Our event rule has now been created and our simple Northwind management pack is complete. However, before we run the Northwind Application and test our management pack, we need to make sure that the configuration changes we've made have been applied and deployed to the management agents. By default, the MOM management servers will check the MOM database for configuration changes every five minutes. We can notify the management server of the configuration changes more quickly by right-clicking the Management Packs folder in the Administrator Console and selecting Commit Configuration Change from the context menu. However, it may still take another minute for the management agents to receive with the changes.

Testing the Northwind Management Pack

After our configuration changes are applied, MOM will begin monitoring our server group and processing our event rule. Before we package our configuration changes into a Management Pack file for deployment, we need to test our event rule and make sure it configured correctly.

We can test our event rule by simply creating a new error event in the Windows Application Log with an event source of "Northwind". The MOM 2005 Resource Kit includes a utility called Event Creator that can be used to generate events in the Windows Event Log. Alternatively, we could create a custom script or unit test(s) that could be driven by a tool such as NUnit to log a new event and exercise our event rule. However, in this case we'll test our MOM configuration through the Northwind Application interface. We can trigger an exception and cause an error event to be logged from our Northwind application by attempting to update a customer record and omitting the CustomerID or entering one longer than five characters. As you can see in Figure 20, we'll edit a customer record and enter an eight character CustomerID of "jamescon", which will cause an exception to be raised (Figure 21).

Figure 20. Northwind application - Edit Customer Account

Click the image to see a larger version.

Figure 21. Northwind-application-generated exception

As we discussed earlier, the MOM Operator or MOM Web Consoles can be used to view and act on MOM operational data. Let's launch the MOM Operator Console to view the alert generated by MOM as a result of our event rule. After opening the Operator Console, navigate to the Alerts view by clicking the Alerts section on the lower left-hand side of the screen. This view of the Operator Console is shown in Figure 22. The Alert Details section displays detailed information for the selected alert including the alert's properties that were mapped form the event log entry, product and company knowledge, and a history log for the alert.

Click the image to see a larger version.

Figure 22. MOM Operator Console: MOM alert generated by the Northwind event rule

On the Events tab in the Alert Details section, you can see a list of the events that caused this alert to occur. Double-click on an individual event record and view more detailed information about event, including its properties and parameters. Figure 23 shows the event view in the MOM Operator Console.

Click the image to see a larger version.

Figure 23. MOM Operator Console: Event received by Northwind event rule

When testing a management pack it might be beneficial to clear the list of alerts or remove individual alerts from the list in the Operator Console. By default, the initial resolution state for an alert is New. Alerts that have been resolved will be not be displayed in the default Alerts view. To resolve an alert using the Operator Console, right-click on the alert(s), navigate to the Set Alert Resolution State context menu and select Resolved. Provide any optional comments to be captured with the alert's history.

Exporting the Northwind Management Pack

The rule group, rules, and provider instances we have created, and additional MOM artifacts such as computer groups, scripts, tasks, and Operator Console views, can be exported to a single management pack file using the Administrator Console. The management pack file can be packaged with our Northwind application and imported in another environment to automatically re-create these artifacts. The default file format for MOM management packs is a binary format with the extension AKM. Management packs can also be converted to an XML format using a conversion tool included with the MOM 2005 Resource Kit. By converting management packs to XML, the contents of the management pack can be viewed using any text editor. Unlike AKM-formatted management packs, XML formatted management packs can also be compared using a utility named MPDiff included with the MOM 2005 Resource Kit. However, the Administrator Console can only export and import management packs in the AKM file format.

To export the Northwind management pack, we can simply right-click the Management Packs folder in the Administrator Console and select Import/Export Management Pack from the context menu to start the Management Pack Import/Export Wizard, as shown in Figure 24.

Figure 24. Management Pack Import/Export Wizard

In the second step (Figure 25), we will export a management pack.

Figure 25. Exporting management packs

In the third step (Figure 26) we need to select the top-level rule group, Northwind, that we wish to export. In addition to the selected Rule Group and its contained rules, the exported Management Pack will also include any associated computer groups, notification groups, data providers, and scripts.

Figure 26. Selecting a rule group

Next in the Management Pack Import/Export wizard (Figure 27 & 28), we will select any Management Tasks and/or Operator Console views that should be included in the management pack. Since we have not created any custom management tasks or views for the Northwind application, we'll skip these steps.

Figure 27. Selecting views

Figure 28. Selecting tasks

We must provide a path and file name for the management pack. Since we're in Authoring mode, we can choose whether we export a full management pack or a retail management pack. With a full management pack, rules marked for deletion are included and the knowledge entries the MOM artifacts such as rules and rule groups can be edited. A retail management pack will not include rules that are currently marked for deletion and the knowledge entries will be read-only. As shown in Figure 29, we accept the default setting and export a full management pack.

Figure 29. Management Pack naming

Finally, we can confirm the options we have selected in the wizard and export the rule groups, rules, provider instances, and computer groups for the Northwind application to a management pack file.

Figure 30. Completing the Import/Export wizard

Now that our management pack has been exported, we can package the resulting Northwind Management Pack.akm file with our application. A systems administrator can import the management pack file using the Administrator Console and easily configure MOM 2005 to monitor the Northwind application.

Summary

We've just begun to scratch the surface of MOM 2005. The goal here is to introduce you to some of the key concepts required for building management packs. There are several steps involved with building a management pack and numerous configuration settings. However, once you understand the concepts, you can quickly navigate through the Administrator Console to configure rules and build a management pack. Now that we've reviewed the basics, there are several ways to extend our simple Northwind management pack. For example we could:

  • Create additional rules—The Northwind application could be enhanced to raise events when transactions complete or audit events when users login to the application. Additional event rules could be configured in MOM to collect and process these events.
  • Build SQL Reports—Our Northwind management pack could include reports that list the most frequent exceptions occurring in our application and the details about each exception.
  • Create custom tasks—We could define custom management tasks that a system administrator could invoke from the MOM Operator Console in reaction to an event or alert. For example, the Northwind management pack could include a custom task for restarting an IIS Application Pool for the Northwind Web services or Web application.

Finally, it's important to understand that MOM 2005 is part of the Microsoft roadmap in the Dynamic Systems Initiative (DSI). DSI is a broad initiative to simplify the development, operations, and entire lifecycle of applications on the Windows platform. A common theme with DSI is that information about an application, the data center hosting the application, and other components that compose a system are represented as models. Models are defined using an XML format called the System Definition Model (SDM). Future versions of many Microsoft products, such as Visual Studio 2005 Team System, plan to support SDM and begin facilitating the system lifecycle using models. MOM management packs are essentially health models for a system and MOM 2005 is an initial step in the DSI initiative. For more information about DSI, please visit the DSI site.

For more information on MOM 2005

About the Author

James Conard is an Evangelist on the Microsoft Windows Server Evangelism team. His focus is to help developers understand how to build manageable applications on the Windows Server platform using technologies such as MOM, SDM, and WMI. Prior to his current role, James was a Technology Specialist in the Microsoft communications sector, where he worked with US telecommunications companies. He has recently relocated to sunny Redmond, Washington with his wife, Amanda, and two kids, London, and Braydon.