Which Events Should I Monitor?
Every application is different, but design documents such as threat models  and performance models  can help you determine what to monitor. If you don't have the time to build these types of models, then at least take the time to identify key scenarios and determine which events should be logged on a normal basis. Do your best to ensure your application is configured by default to log these events.
Don't just consider the built-in Web events. You should also determine what data
must be available for monitoring
, even if ASP.NET doesn't provide built-in support for monitoring that data. Build custom Web events to cover these cases. When something goes wrong, the first thing a good administrator is going to do is crank up the level of monitoring in order to diagnose the problem. Verbose data need not be logged on a regular basis, but if it helps
One last thing to consider is that administrators often use monitoring tools to help determine when an application needs to be scaled up in some way. Consider instrumentation that assists in this planning process, including custom performance counters.
Now that you've seen the types of built-in events that you can monitor, we'll show how you can record them to various logs using the built-in providers that come with ASP.NET 2.0. Figure 7-2 shows the class hierarchy of the built-in providers, which all ultimately derive from WebEventProvider.
Figure 7-2. Built-in Web event providers
In order to use any of these providers, you need to refer to them in configuration. By default, three providers are already configured for you in the machine-wide web.config file, as shown in Listing 7-1 (I've removed the assembly strong
Listing 7-1. Default Web event providers in the root web.config file
Notice that the "enabled" attribute on <healthMonitoring> isn't set here, which means the entire Web event system is disabled by default. As you'll see in the following listings, you'll need to enable this yourself in your web.config file if you want to record any Web events.
The event log provider is a simple example to start with. It doesn't need any configuration: its job is to synchronously write each event it receives to the Windows application event log. System administrators like a high signal-to-noise ratio in their event logs, so it's wise to limit the amount of data you log using this provider to higher priority events. Listing 7-2 is an example of what a Web event recorded by this provider looks like, as
Listing 7-2. A Web event sent to the event log
Windows Management Instrumentation (WMI) is a well-known interface for management tools such as IBM Tivoli, Microsoft Operations Manager, and so on. Using the WmiWebEventProvider, you can
The TraceWebEventProvider is a special adapter that funnels each Web event it receives into the System.Diagnostics tracing engine. You'll see how to use this provider later in this chapter.
The E-Mail Providers
Two providers send SMTP (e-mail) messages for each Web event. Both of these providers can be configured with a common set of attributes that determine e-mail headers (from, to, cc, bcc), how many events should be buffered before sending an e-mail (maxEventsPerMessage), the maximum number of events you want in any given e-mail (maxMessagesPerNotification), as well as a subject prefix for the e-mail. These providers both use the services of System.Net.Mail, which relies on the system.net/mailSettings/smtp section in web.config (see Listing 7-3). You won't see any exceptions if the e-mail provider fails to send e-mail, but you will see errors in the application event log that can help you diagnose problems about these e-
The SimpleMailWebEventProvider creates text e-mail messages and lets you control formatting at a very basic level through a set of additional string-valued attributes on the provider: bodyHeader, bodyFooter, and separator. The maxEventLength attribute allows you to
If you need something fancier, TemplatedMailWebEventProvider lets you create an ASPX page that will be used to format these e-mail messages as HTML. Along with the common attributes listed above, you'll need to add one more attribute named "template" that specifies which ASPX page is to be used for formatting. The provider communicates the current set of events that need logging to your page via a static property on TemplatedMailWebEventProvider called CurrentNotification, which is of type MailEventNotificationInfo. This gives you all the information you need to build an HTML page, which the provider will then use as the body of the e-mail message.
Listing 7-3 is a sample configuration you can use to get started with templated Web event e-mails. We've used the
Listing 7-3. Configuring the TemplatedMailWebEventProvider
Listing 7-4 contains the code for formatter.aspx. This page uses data binding to output a few details from the collection of Web events into a GridView. Figure 7-3 shows what one of these formatted e-mails looks like in Outlook Express.
Listing 7-4. Formatter.aspx
Figure 7-3. E-mail notification
The SQL Provider
When you run aspnet_regsql, the resulting database includes a table called aspnet_WebEvent_Events, which includes columns for each property of WebBaseEvent. The SqlWebEventProvider
Note that SqlWebEventProvider always obtains its database connection using the worker process' security identity (even if you've turned on impersonation), so be sure to add this user account to the database role called aspnet_WebEvent_FullAccess, granting it permission to log Web events in the database.