Application errors occur in production regardless of how much planning and testing is done, thus the need for application support. Production systems should be monitored from the ground up with the application being the last level.

ASP.NET health monitoring has been available since ASP.NET 2.0. Health monitoring provides one way to keep an eye on a production Web application by tracking such things as unhandled exceptions.

The benefits

You may be thinking that this type of monitoring is unnecessary since you have robust error handling in your application code and extensive production monitoring in place. While you still need to do these things, ASP.NET health monitoring provides another level of monitoring with the following advantages:

  • Keeps an eye on application performance to measure its health.
  • Monitors the performance of an application to make sure that it is healthy.
  • Evaluates events during an application’s life cycle.
  • Monitors production applications in a Web farm or individually.
  • Tracks events/exceptions that don’t necessarily relate to ASP.NET errors.
  • Captures data that can be used to quickly diagnose problems on the fly.

A great aspect of health monitoring is the lack of changes to production code. That is, it can be put in place by simply making configuration changes (the application’s web.config file).

Setting up health monitoring

Health monitoring is as simple as specifying what events to monitor, deciding where to store this log data (SQL Server, event log, etc.), and then mapping the selected events to the data storage location. Utilizing health monitoring in an ASP.NET application is easy, since it is controlled via various options located in an application’s web.config file by way of the <healthMonitoring> element. This element has three child elements that are used to configure health monitoring:

  • <eventMappings>: Named groups of the event that you want to monitor. There are two high-level groupings that cover most everything: All Events and All Audits. There are other options available, and you can create your own for custom events.
  • <providers>: Define the logging sources available for logged events.
  • <rules>: Specify which events to log via which providers — this is where events and providers are paired together.
  • <bufferModes>: Configure buffering to minimize the performance impact and overhead of recording events. You can use the <bufferModes> configuration to define how long events are buffered before they are written to the provider, and you can distinguish between urgent or critical events and regular events.
  • <profiles>: Specify sets of parameters to use when configuring events. These parameters indicate the minimum number of instances after which the event should be logged, the maximum number of instances, and the minimum interval between logging two similar events. This element can be critical in controlling how much information is generated by defining when monitoring begins and when it ends by setting thresholds.

The configuration elements necessary for an application will depend on your requirements. As an example, the following web.config snippet demonstrates basic health monitoring that records all application lifetime events in the Windows Event Log. These events include application startup and shutdown, so you can get an idea of when an application is starting and stopping, and this is provided without touching any source code.

<healthMonitoring enabled="true">

<rules>


<add name="Application Lifetime Events On"


eventName="Application Lifetime Events"


provider="EventLogProvider" profile="Default"/>


</rules>

</healthMonitoring>

The next example takes it further by recording application events to a backend database. This takes the previous example further by adding the connectionString element to define the database connection and using the providers element to tie health monitoring to the defined database connection. The rules element marries the events to the backend database.

<system.web>

<connectionStrings>


<add name="healthMonitoringDatabase" connectionString="depends on your database" />


</connectionStrings>


<system.web>


<healthMonitoring enabled="true">


<providers>


<add name="dbProvider" type="System.Web.Management.SqlWebEventProvider"


connectionStringName="healthMonitoringDatabase" buffer="false"  bufferMode="Notification" />


</providers>


<rules>


<add name="applicationEvents" provider="dbProvider" eventName="Application Lifetime Events" />


</rules>

</healthMonitoring>

A caveat with using a SQL Server database with health monitoring is the backend database used must require setup. The good news is the command line aspnet_regsql.exe tool handles the setup — it creates the necessary features (tables and stored procedures) in the specified database. There are various command line switches used to configure this option, but you can use the W command line switch (aspnet_regsql.exe -W) to use the GUI to guide you through the steps.

Plenty of options

This post only scratches the surface of what health monitoring offers. For example, you are not limited to using the Event Log or a database backend, as you can utilize email, trace messages, and even WMI. And, the range of exceptions or events to monitor is unlimited. The Microsoft patterns & practices site is a good starting point to dive deeper into this feature.

Keep an eye on it

I had a manager recently ask me to guarantee an application would not have any down time. I respectively declined despite their insistence. While you may have a Linux box in the corner that has been running for years, there are too many factors that can affect the availability of a Web application. The ASP.NET health monitoring feature provides one way to keep an eye on an application in various ways and then respond accordingly.

What methods do you use to keep an eye on production applications? Let us know in the comments.

Keep your engineering skills up to date by signing up for TechRepublic’s free Software Engineer newsletter, delivered each Tuesday.