Chapter 31. ASP.NET Management and Monitoring

IN THIS CHAPTER

• Introducing the New Health Monitoring System
• Using ASP.NET Performance Counters

Administering and monitoring an ASP.NET application can be a tedious and difficult task. Often, due to the complexity of attempting to monitor the internal behavior and health of an ASP.NET application, developers are the ones tasked with performing the ongoing maintenance and monitoring of these applications. This chapter illustrates various technologies and techniques that can make applications easier to administer, configure, and monitor by IT staff as well as developers.

Introducing the New Health Monitoring System

ASP.NET 2.0 comes equipped with a new system that allows for the raising of health monitoring events (also referred to as web events). The main benefit of this system is that because it is completely manageable through configuration files. Operations and other IT staff can monitor the health of deployed web applications without the direct intervention of developers. The health monitoring system is composed of two primary components:

• Web event—A web event is a derivative of the WebBaseEvent class and is used to contain information pertinent to the event raised and can often contain additional information. For example, several of the event classes that come with the system store information about the application such as its directory, the time of the event, the page in which the event occurred, and so on.
• Web Event provider—A Web Event provider is a special class that can subscribe to web events. When the provider receives an event, it can then store the event in a persistence medium like SQL Server or a file on disk, or it can forward the event by sending an e-mail or a text message to a cellular phone.

Events and providers are linked together in your application’s Web.config file. Event types are assigned to named groups in the Web.config’s <eventMappings> element. By default, ASP.NET already has several event providers defined as well as event groups.

Table 31.1 shows the web events that come with ASP.NET 2.0.

Table 31.1 ASP.NET 2.0 Web Events

ASP.NET 2.0 also contains several default web event providers. Those providers are described in Table 31.2.

Table 31.2 ASP.NET 2.0 Web Event Providers

By default, very little of this system is configured. If you don’t specify any other web event information in your application’s Web.config file, your application will send the All Errors and Failure Audits events to the EventLogWebEventProvider class.

Using the Health Monitoring System

Using the health monitoring system really boils down to manipulating the Web.config file to determine which events are handled by which event providers. As mentioned earlier, errors and failure audits are sent to the system event log by default. Using the Web.config file, you can use additional ASP.NET Web Event providers to handle additional event types.

This section shows you how to use a SQL Server 2005 database table as the destination for error events such as unhandled exceptions. Although the system event log might be handy in a few circumstances, storing all application errors in a central location that can be queried from remote locations is extremely useful. For example, if your application is running in a web farm scenario (multiple web servers hosting the same application), you will want all of the errors to be accessible in the same place and tagged with the name of the machine that originated the error. Logging errors using the SqlWebEventProvider does exactly that.

To start, create a new ASP.NET web application and add a Web.config file to the project. The SQL Web Event provider uses a table called aspnet_WebEvent_Events that is created when you create an application services database using the aspnet_regsql.exe tool.

Listing 31.1 contains the modified Web.config that will utilize the SQL Web Event provider.

Listing 31.1 A Web.config File Supporting Web Event Persistence in SQL Server

Next, add the following line of code to your default.aspx.cs file:

throw new ApplicationException("test error");

When you run the application, you will get the application exception and VS 2005 will break. Continue execution and then wait a minute or two. Because the SqlWebEventProvider class uses a buffered system, the error won’t appear within the database immediately. Figure 31.1 shows the contents of the aspnet_WebEvent_Events table after an error occurs.

Figure 31.1 Storing web errors in SQL Server.

Also shown in this figure are lifetime events. Lifetime events indicate significant changes that occur in an application’s lifetime such as application startup and shutdown. This information can be important when diagnosing problems with a production server. To support lifetime events in your application, change the preceding Web.config to the one shown in Listing 31.2.

Listing 31.2 A Web.config File Supporting Both Errors and Lifetime Events

This configuration file adds a new entry to the <eventMappings> section indicating that events in the group “Lifetime” are of the type WebApplicationLifetimeEvent. The <rules> section indicates that all events in the group “Lifetime” are to be handled by the SqlWebEventHandler class. This provides the necessary hooks to get information like application startup and shutdown stored in the SQL Server database.

Creating Custom Events

Before getting into the details of how to create a custom event, it is important to know when custom events should and should not be created. One important factor to keep in mind is that the developer does not have explicit control over when ASP.NET raises its own default custom events outside of defining event mappings and rules in the Web.config file. In other words, a programmer cannot explicitly raise an “Application Startup” event through code. The following guidelines should help you make the decision as to when to create a custom event:

• If your event requires the storage of data that is not already being stored by any of the existing event classes, you should create your own event.
• If you need programmatic control over when to signal the event, you can create your own and inherit from the event you want to manually signal. Keep in mind, however, that ASP.NET already does an excellent job of signaling events at the appropriate time, and you should use the existing events whenever possible.

The next sample will illustrate the use of a custom web event that will get signaled when a user of a research department’s website requests a search. As you’ll see in the next section on creating a custom provider, this request can then either be handled automatically via web services or dispatched to a research department employee.

Add a new Class Library project to the solution that contains the website from the previous samples. Add a reference to the System.Web Assembly and add a class to the project called AsyncSearchRequest. Listing 31.3 shows the class that inherits from WebBaseEvent.

Listing 31.3 The AsyncSearchRequest Class

The constructors were created so that you can see where you can inject your own code into the instantiation process. The FormatCustomEventDetails method is used to provide additional text data that will be logged with the event when sent to a provider.

One of the most powerful features of the new ASP.NET Web Management system is that you can plug any of your custom events into any of the existing event providers or any custom providers that you or a third party create.

Listing 31.4 contains a new Web.config for the web application that associates the newly created custom event with the SQL Server Web Event provider.

Listing 31.4 A Modified Web.config File Supporting Custom Web Events

To raise this event, you need to do it manually using the Raise() method on the custom event class. Because this class isn’t part of the default ASP.NET framework, it won’t raise events unless your code forces it to happen, as shown in the following example:

SampleEvents.AsyncSearchWebEvent searchEvent =
new SampleEvents.AsyncSearchWebEvent(
    "Search Requested", this, WebEventCodes.WebExtendedBase + 1);
searchEvent.SearchCriteria = "C#";
searchEvent.Raise();

Every event requires an event code in order to be raised. Event codes less than 100,000 are the sole property of ASP.NET and cannot be used by custom events. Therefore, your event codes should start at WebExtendedBase and increment from there. Event codes above 100,000 can be reused by any event. After running the preceding code and waiting a few minutes for the event buffer to flush, you will see a new event appear in the aspnet_WebEvent_Events table. The Details column contains the following text:

Creating Custom Event Providers

To illustrate how to create a custom Web Event provider, this section will show you how to create a Research Dispatch provider that handles AsyncSearchWebEvent events and dispatches them accordingly. To create a basic Web Event provider, create a class that inherits from the base class BufferedWebEventProvider (you can create an unbuffered one, but this sample uses a buffered provider to provide a comparison with the buffered SqlWebEventProvider class). To see this in action, add a new class called SearchWebEventProvider to the class library that contains the AsyncSearchWebEvent class. This class is shown in Listing 31.5.

Listing 31.5 A Simple Custom Web Event Provider

The code for the provider itself isn’t very complex. The complexity can come from choosing the storage medium or notification medium used when handling the event. The preceding sample shows how you can create a simple provider shell to be used with the search event.

Using ASP.NET Performance Counters

Another powerful tool at the disposal of developers and system administrators alike is the use of performance counters. The Performance Monitor tool (found under Administrative Tools, Performance) displays a value-over-time graph of any number of system counters that provide valuable analysis information. Consult your Windows administration guide for more information on system-level performance counters.

ASP.NET 2.0 provides the following performance counters that can be monitored from the Performance Monitor tool. These counters are described in Table 31.3.

Table 31.3 ASP.NET 2.0 Performance Counters

Summary

The task of monitoring the health of ASP.NET applications has often been difficult and time-consuming in the past. It was also a task that often fell on the shoulders of developers because of the specific constraints and requirements of custom-built monitoring systems. With the use of performance counters and the System.Web.Management namespace for web events, you can create web applications that can be monitored for system impact and performance by non-development staff and you can even monitor important events within your application without having to write complex monitoring systems. Every developer responsible for producing a commercial application should take a look at the ASP.NET performance counters and at web events to see how they can increase the stability and health awareness of their application.