Health Monitoring in ASP.NET 3.5

Introduction

Keeping an eagle's eye on the errors and important events occurring in your web site is an important administrative job. ASP.NET health monitoring features provide a great deal of functionality out of the box that relieves you from developing custom monitoring systems. In this article I am going to show you how ASP.NET health monitoring can be used to track system events and errors.

Health monitoring providers

If you developed any web site in ASP.NET 2.0 or later you are probable aware of the Provider Model concept. The same provider model concepts are applicable to health monitoring system also. ASP.NET allows you to log information about system errors and events in several locations. The possible locations are as follows:

• Event Log
• SQL Server
• Email
• ASP.NET Trace
• IIS Trace

By default ASP.NET logs the information in Windows event log using EventLogWebEventProvider. This is the default. You can divert this information to a SQL server database using SqlWebEventProvider. If you wish to send this information in the form of email based alert you can use SimpleMailWebEventProvider and TemplatedMailWebEventProvider instead. Finally, if you decide to put this information in ASP.NET or IIS tracing systems then you can use TraceWebEventProvider and IisTraceWebEventProvider respectively. These providers and most of the other classes of health monitoring system are located in System.Web.Management namespace.

The following diagram shows how ASP.NET logs error information in Windows event log.

Web Events

There are several events that you can trap using the health monitoring system. These events are called Web Events. Each web event is defined by a class. Some of the important events are given below:

• WebBaseEvent : Acts as a base class for all the other web events.
• WebBaseErrorEvent : Acts as a base class for all web events related to errors in the system.
• WebHeartbeatevent : Records web events after a predefined interval instead of each and every occurrence.
• WebRequestEvent : Represents web events occurring during a request.
• WebErrorEvent : Represents configuration or compilation errors.
• WebApplicationLifetimeEvent : Deals with application level events including application starts and stops.
• WebRequestErrorEvent : Deal with unhandled exceptions and any request related errors.
• WebAuditEvent: Represents a base class for web events related to login attempts.
• WebFailureAuditEvent : Deals with login failures.

Configuring health monitoring features

In order to use the health monitoring system you need to do some configuration job as outlined below:

• Enable health monitoring
• Map events with developer defined friendly names (optional)
• Specify buffering behavior for the providers (optional)
• Configure one or more providers
• Specify which system events are to be monitored and by which providers

Let's perform all of the above steps one by one and see how system event information can be stored in a SQL server database.

Enabling Health Monitoring

The first step in using ASP.NET health monitoring system is to enable it in the web.config file. This is done using <healthMonitoring> section as shown below:

<healthMonitoring enabled="true">
...
</healthMonitoring>

The enabled attribute of <healthMonitoring> tag must be set to true.

Map events to friendly names

Earlier I discussed important web events classes. While configuring the health monitoring system it is easy if you give some friendly names to these web events. That is precisely done using <eventMappings> section. This section comes under <healthMonitoring> section and looks as shown below:

<eventMappings>
<add 
name="MyEvent" 
type="System.Web.Management.WebBaseEvent" 
startEventCode="0" 
endEventCode="10000"/>
</eventMappings>

The <add> tag specifies several attributes. The name attributes gives a unique friendly name to this web event. The type attribute specifies name of the class that represents the web event. Each time a web event occurs ASP.NET assigns it a code. The startEventCode and endEventCode attributes decide the start and end codes. These attributes must contain Int32 values.

Specify buffering behavior

If you keeping logging each and every web event individually it may add overheads in terms of too many IO operations or too many emails (in case of SimpleMailWebEventProvider and TemplatedMailWebEventProvider). You can tackle such situations by defining a buffer mode for a provider. Thus events are first queued and then logged using the target provider. The following markup shows how the buffer is configured:

<bufferModes>
<add 
name="MyBuffer" 
maxBufferSize="100" 
maxFlushSize="50"
maxBufferThreads="1" 
regularFlushInterval="00:10:00" 
urgentFlushInterval="00:01:00" 
urgentFlushThreshold="10" />
</bufferModes>

The <bufferModes> section specify one or more buffer modes to be used with web event providers. In the above example I named the buffer mode as MyBuffer. The maxBufferSize attribute specifies the maximum number of event messages that can be held in the buffer (100 in above example). While logging using the underlying provider the system will not send more than 50 messages at a time as indicated by maxFlushSize attribute. The flushing of the buffer will happen after every 10 minutes as indicated by regularFlushInterval attribute. The urgentFlushInterval and urgentFlushThreshold attributes govern the minimum flush interval and minimum messages per flush respectively. Finally the maxBufferThreads attribute decides the maximum number of flushing threads.

Configuring Web Event Provider

Now comes the important step - defining one or more web event providers. This is done using <providers> section. In the following example I store the web event messages in a SQL server database.

<providers>
<add 
name="MyProvider" 
type="System.Web.Management.SqlWebEventProvider" 
connectionStringName="LocalSqlServer" 
buffer="true"
bufferMode="MyBuffer"/>
</providers>

The <add> section specifies many attributes. The name of this entry is specified by name attribute. The type attribute indicates the web event class that you wish to use. The SqlWebEventProvider class stores the web event information in a table named aspnet_WebEvent_Events. This table is created by the aspnet_regsql.exe command line tool that configures ASP.NET application services. If you don't specify a specific configured database then ASP.NET creates ASPNETDB database in the App_Data folder and automatically configures it. The connectionStringName attribute points to a database connection string from <connectionStrings> section. The buffer attribute decides whether buffering should be turned on and the bufferMode attribute decides the buffer mode to be used for the buffering.

At this point if you run your web site you will find that it doesn't log any message even if errors occur. This is because you have not yet mapped the providers and the events to be trapped.

Map providers and web events

The final step involves mapping providers with the web events. This is accomplished using <rules> section as shown below:

<rules>
<add 
name="MyRule" 
eventName="MyEvent" 
provider="MyProvider"/>
</rules>

The name attribute gives a unique name to this rule. The eventName attribute specifies name of the web event as defined by the <eventMappings> section earlier that you wish to log in a provider. The provider attribute specifies the name of the provider to be used.

That's it! You just configured ASP.NET health monitoring system for your web site. In order to test how it works deliberately throw some exception in your web site and check the SQL server database. The following screen shot shows aspnet_WebEvent_Events table after a sample run of a web site.