Health Monitoring in ASP.NET 2.0

ASP.NET 2.0 includes a nifty new feature known as Health Monitoring. The name might be a bit misleading, as the feature is really an extensible and general-purpose framework for producing and capturing events during the life of an ASP.NET application. Health monitoring can be useful in a number of scenarios, for instance, health monitoring is useful to administrators who need to monitor an application and be notified when a critical error occurs, or to developers who need to add instrumentation to a mis-behaving application.

The runtime includes a number of classes to represent events. There is a class to represent authentication failures, a class to represent request errors, and more. You can find out the reason for an application restart, and find out when a compilation occurs. You can even derive a class from System.Web.Management.WebBaseEvent to encapsulate your own custom events. If you just want to raise a simple event, instantiate an existing event class and invoke the Raise method.

You capture events using one of the built in event providers. There is a provider to capture events and send email notifications, a provider to log events to SQL Server, a provider to expose events via WMI, and a provider to drop events into an event log. As the name implies, Microsoft built event providers using the pervasive provider model. You can also build a custom event provider and plug into the health monitoring system.

Three providers come pre-configured: the event log provider, the WMI provider, and the SQL Server provider. The default SQL Server provider will log events into a SQL Express aspnetdb database in the special App_Data folder. To log events to a different instance of SQL Server, even a remote instance, you simply need to provide a bit o’ configuration love in web.config:

ScottGu has all the details on switching the default database configuration in his post: “Configuring ASP.NET 2.0 Application Services to use SQL Server 2000 or SQL Server 2005”.

In the above web.config is the rules section. The rules section controls which events the ASP.NET runtime will deliver to a provider. In the config snippet above, we are asking for “All Events” to come to our database via the MySqlWebEventProvider. ASP.NET 2.0 groups events into categories such as “All Events”, “Heartbeats”, “All Audits”, “Failure Audits”, “All Errors” and more using an eventMapping section in the machine’s web.config file (in the CONFIG directory of the .NET framework installation, typically \Windows\Microsoft.Net\Framework\v2.x\Config). Take a look at the file to see the default categories. You can also define your own event categories using an eventMapping section in your application’s web.config file.

One question that comes up with health monitoring is when to use health monitoring and when to use a tool like the Logging and Instrumentation block in Enterprise Library. If you have to provide logging and instrumentation outside of an ASP.NET web application or web service, obviously the block is the solution. Inside of ASP.NET, health monitoring is certainly easy to use and extend, so I wouldn’t see a need to pull in enterprise library for the sole purpose of adding logging functionality.