Health Monitoring

CoreCoder

LANGUAGES: C#

ASP.NET VERSIONS: 2.0

Health Monitoring

Keep the Health of ASP.NET Applications Under Strict Control

By Dino Esposito

In classic ASP and ASP.NET 1.x, it is difficult for Web site administrators to diagnose problems and monitor Web applications. In case of run-time errors, the richest source of information is simply HTTP errors. In some cases, another helpful source of information can be trace messages scattered throughout the code in places that the developer considers potentially buggy or problematic. Classic ASP and ASP.NET 1.x feature a limited set of event log messages that can be used to monitor the health of installed applications. The bad thing about this form of event logging is that it works in a reactive manner. Administrators receive messages and pass them on to the development team. The development team must analyze the cause of the error and make a decision. All of this happens offline as, all the while, the connected user gets a more or less friendly error page.

In ASP.NET 2.0, a new subsystem known as the health monitoring system enables a proactive approach to application monitoring. It works by raising a number of application events that carry health-monitoring data through various mechanisms and storage media. In this way, collecting and processing run-time information is easier than ever and can be done programmatically through code incorporated in the body of the application.

Health Monitoring at a Glance

ASP.NET health-monitoring features can be used to perform a number of tasks. You can monitor the health of live applications to ensure that they are working properly. You can monitor applications individually, and even across a Web farm. The health subsystem helps significantly in the diagnosis of applications that appear to be failing and to log any sort of events. It is important to notice that you can log and process not just errors but also events that signal particular situations that can be useful for you to examine. More in detail, the ASP.NET health monitoring system instruments your application for predefined and custom events related to performance, security, failures, and anomalies.

The subsystem works by sending events to registered listeners, named Web event providers. A Web event provider typically processes the information associated with a health event by recording the event on a persistent medium. Each event contains information such as type, code, and a descriptive message. Not all events are of interest to all providers. The mapping between providers and fired events is set in the web.config file.

The health monitoring system takes advantage of the ASP.NET provider model, meaning that it exposes some core functionality through a replaceable component, called the provider. The provider model allows ASP.NET developers to become familiar with a single API to program a service, regardless of how that particular service interoperates with the rest of the system and data storage layers. The theory behind this behavior is codified in the popular behavioral design pattern the pattern strategy.

The strategy pattern indicates an expected behavior that can be implemented through a variety of interchangeable algorithms. Each application selects the algorithm that best fits, while keeping the public, observable behavior intact. Applied to an ASP.NET service such as health monitoring, the pattern isolates in the replaceable algorithm the code to save and process run-time information and serve them to the developers through a common and unchangeable API. Let s take a look at how to enable and configure the health monitoring system.

The <healthMonitoring> Section

The health monitoring system tracks significant events in the lifetime of deployed applications and fires related events to providers. The event contains actual information about what happened; the provider processes the information. The system is configured through the <healthMonitoring> section in the web.config file. The overall schema is shown below:

<healthMonitoring

enabled="true|false"

heartbeatInterval="HH:MM:SS">

</healthMonitoring>

The attribute enabled indicates whether health monitoring is enabled or not. By default, health monitoring is turned on and must be disabled explicitly if you don t want it on. The core element of the system is the heart-beat event. The heart-beat event serves as a timer for the whole subsystem and is raised at regular intervals to capture useful run-time state information. The heartbeatInterval attribute indicates how often the heart-beat event is raised. You can set it to a number and it will indicate the period in seconds. You can also use an HH:MM:SS schema to specify a period with the maximum flexibility. The default interval for the heart-beat event is set to 0, meaning that no heart-beat event is raised.

The heart-beat is only one of the events that the health monitoring system can detect. Other events track unhandled exceptions, request processing, application lifetime, and success and failure audits. Child sections listed in Figure 1 allow you to configure the whole health subystem.

Element	Description
bufferModes	Used with SQL Server and e-mail built-in Web event providers to determine how often to flush the various events to the provider and the size of the intermediate buffer.
eventMappings	Maps friendly event names to the event classes.
profiles	Defines parameter sets to use when configuring events.
providers	Defines the health monitoring providers that process events.
rules	Maps events to providers.

Figure 1: Elements to configure ASP.NET health monitoring.

The monitoring system pings the application to determine what s going bad and reports to listeners. You don t have to be a super-expert developer to suspect that this practice may have a devastating impact on performance. Depending on the selected Web event provider, the action performed by the provider can be quite costly, such as sending an e-mail to the administrator or writing a record to a relational database. In this case, you can turn on buffering through the <bufferModes> section. If you enable buffering, the provider buffers event information according to the specified mode and inserts the event information into the database in a batch. You can customize buffering behavior by selecting a predefined buffering mode: Analysis, Notification, or Critical Notification. Each mode has its own set of properties, such as the size of the buffer and frequency for flushing the buffer. Alternatively, you can create custom buffering modes and configure the provider to use one of the buffer modes you have defined.

Under the <eventMappings> section you define events that will be trapped and recorded. Each event is characterized by a class. In this section you give each event a friendly name and register new custom event classes:

<add name="Failure Audits"

type="System.Web.Management.WebFailureAuditEvent" />

</eventMappings>

Web events contain information about the current worker process, AppDomain, request and response data, and application and configuration errors. All event classes inherit from the WebBaseEvent base class. Event classes are listed in Figure 2.

Event Class	Description
WebApplicationLifetimeEvent	Represents a significant event in the lifetime of an application, including start-up and shut-down events.
WebAuthenticationFailureAuditEvent	Provides information about authentication failures.
WebAuthenticationSuccessAuditEvent	Provides information about successful authentication events.
WebErrorEvent	Provides information about errors caused by problems with configuration or application code.
WebFailureAuditEvent	Provides information about security failures.
WebHeartbeatEvent	Serves as a timer for the ASP.NET health monitoring system. These events are raised at an interval defined by the heartbeatInterval attribute of the healthMonitoring configuration section.
WebRequestErrorEvent	Defines the event that carries information about Web request errors.
WebSuccessAuditEvent	Provides information about successful security events.
WebViewStateFailureAuditEvent	Provides Web application viewstate failure information.

Figure 2: Health-monitoring events.

Other configuration sections are defined to fine-tune the behavior of the system. The <profiles> section allows you to create profiles; that is, sets of configuration attributes that can be collectively added to a Web event provider. The <providers> section instead lists all registered providers and allows you to define custom providers, as well. Finally, the <rules> section defines which events are processed by which provider.

ASP.NET 2.0 comes with a number of built-in event providers. Each provider writes event information to a distinct storage medium. Let s briefly analyze some of them (see Figure 3 for a quick list).

Provider	Description
EventLogWebEventProvider	Records errors to the Windows Application Event Log.
SimpleMailWebEventProvider	Sends an e-mail message with a fixed text.
TemplateMailWebEventProvider	Sends a customizable e-mail message.
SqlWebEventProvider	Records errors to a SQL Server database.
TraceWebEventProvider	Records errors as ASP.NET trace messages.
WmiWebEventProvider	Records errors through the WMI system.

Figure 3: Web event providers.

The Event Log Provider

EventLogWebEventProvider works by logging health-monitoring events into the Windows Application Event Log. By default, the provider tracks failure audits and all other application errors. The following excerpt from the global web.config file illustrates the configuration of the provider:

<rules>

<add name="All Errors Default" eventName="All Errors"

provider="EventLogProvider" ... />

<add name="Failure Audits Default" eventName="Failure Audits"

provider="EventLogProvider" ... />

</rules>

SimpleMailWebEventProvider sends e-mail notifications of an event to the specified recipient (see Figure 4).

<add name="CriticalMailEventProvider"

type="System.Web.Management.SimpleMailWebEventProvider, ..."

from="[email protected]"

to="[email protected]"

bodyHeader="..."

bodyFooter="..."

subjectPrefix="..." />

</providers>

<rules>

<add name="All Errors by Email"

eventName="All Errors"

provider="CriticalMailEventProvider" />

</rules>

Figure 4: SimpleMailWebEventProvider sends e-mail notifications of an event to the specified recipient.

To use the mail provider you must have the mail SMTP host properly configured. Here s what you need in the web.config file:

<system.net>

</smtp>

</mailSettings>

</system.net>

The format of the message sent through SimpleMailWebEventProvider can t be modified. If you want to build more sophisticated e-mail messages, opt for TemplatedMailWebEventProvider, which has an additional property that references an ASP.NET page to be used as a template. TemplateMailWebEventProvider counts a static property through which you can access any event-related information and populate the template page. Any output in the page is used to prepare the message sent to the recipient.

SqlWebEventProvider writes event information to the configured SQL Server database. The default target database is aspnetdb.mdf, the same local SQL Server 2005 that other ASP.NET providers use to persist data. The table where data is flushed is named aspnet_WebEvent_Events. To start using this provider you need to add a <rules> section.

TraceWebEventProvider sends intercepted health events out as ASP.NET trace messages that can be seen through the trace.axd utility. For this provider to work, ASP.NET tracing must be enabled.

Finally, WmiWebEventProvider forwards the intercepted events to the Windows Management Instrumentation (WMI) system. WMI is an operating system component that administrators and developers use to query and process system information. You typically add the following <rules> section to start the WMI event provider:

<rules>

<add name=" ErrorsToWMI" eventName="All Errors"

provider="WmiWebEventProvider" />

</rules>

The built-in set of event providers covers the most common storage media. Additional providers can be created, but the main reason for doing so is to record events in a SQL Server database with a different schema or in another DBMS system, such as Oracle or DB2. If you need to get output in a particular text format, it is preferable that you use the Event Log provider, then export the recorded information in a suitable text format. Writing a custom provider is certainly possible, but exporting data if functionally adequate is much simpler and faster.

Conclusion

Health monitoring is an ASP.NET system feature that allows the production staff to monitor the status of a deployed application and track significant events related to performance, behavior, and failures. The system works by firing events to ad hoc providers. The event delivers information about what happened, whereas the provider processes the information. Typically, the provider records the event and forwards information to a listener. ASP.NET comes with a built-in set of event providers, but others can be defined to suit particular storage needs you may have.

Dino Esposito is a Solid Quality Learning mentor and author of Programming Microsoft ASP.NET 2.0 Core Reference and Programming Microsoft ASP.NET 2.0 Applications-Advanced Topics, both from Microsoft Press. Based in Italy, Dino is a frequent speaker at industry events worldwide. Join the blog at http://weblogs.asp.net/despos.

Comments

Plain text