Health Monitoring in ASP.NET 3.5
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
- Event Log
- SQL Server
- 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
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
- 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
- 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
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:
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:
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.
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:
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.