Health Monitoring in ASP.NET 2.0(转载）

原文：http://aspnet.4guysfromrolla.com/articles/031407-1.aspx
An Overview of Health Monitoring
The ASP.NET 2.0 Health Monitoring system is designed to monitor the health of a running ASP.NET application in a production environment. The Health Monitoring system works by recording event information to a specified log source. For example, it can log events like application starts and stops, successful and failed logins, and unhandled exceptions to log sources like the Windows event log or a SQL Server database. Setting up the Health Monitoring system is as easy as adding some configuration information to Web.config specifying the events to monitor and the log source to send them to.

While the .NET 2.0 Framework provides a number of built-in Health Monitoring events and log sources, there will invariably be times when you need to add custom events or use an alternate log source. New events can be created as classes that extend the WebBaseEvent class, and custom log sources can be created as classes that extend the WebEventProvider class. The Health Monitoring system was designed with the provider design pattern, allowing custom events and log sources to be plugged into an application with just a few changes to the configuration information.

Future articles in this series will examine creating custom events and log sources. In this article, we will constrain the examples to using built-in events and log sources.

Configuring Health Monitoring
Health Monitoring is configured through a <healthMonitoring> element in Web.config that specifies the event mappings, the event subscription rules, and log sources. Each of these items is defined as a child element of the <healthMonitoring> element. Let's look at each of these children elements individually:

• Event Mappings (<eventMappings>) - associates a human-friendly name with a set of events. The name used here is referenced in other sections.
• Log Sources (<providers>) - associates a human-friendly name with those types that can function as log sources.
• Event Subscription Rules (<rules>) - ties an event set defined in the <eventMappings> section with a log source defined in the <providers> section.

The following example illustrates how these three sections are tied together. Here we have defined a single event mapping named "All Errors" that is denoted by any event class that derives from the WebBaseErrorEvent class. A single log source named "EventLogProvider" is defined, which maps to the EventLogWebEventProvider class, which, as its name implies, logs event information to the Windows event log. Finally, the event subscription rule named "All Errors Default" associates the "All Errors" event set with the "EventLogProvider" log source. With the following configuration defined in Web.config, all unhandled exceptions or error events explicitly raised will result in a record being written to the Windows event log:

<configuration>     <system.web>       <healthMonitoring enabled="true">        <eventMappings>           <clear />           <add name="All Errors" type="System.Web.Management.WebBaseErrorEvent"                    startEventCode="0" endEventCode="2147483647" />        </eventMappings>        <providers>           <clear />           <add name="EventLogProvider" type="System.Web.Management.EventLogWebEventProvider" />        </providers>        <rules>           <clear />           <add name="All Errors Default" eventName="All Errors" provider="EventLogProvider"                    profile="Default" minInstances="1" maxLimit="Infinite" minInterval="00:01:00"                    custom="" />        </rules>       </healthMonitoring>     </system.web> </configuration>

With the following configuration in place, when an unhandled exception is encountered, the Health Monitoring system automatically records the error's details to the Windows event log. The download at the end of this article includes a web application that includes a page with a Button control that, when clicked, raises an ApplicationException. When visiting this page and clicking that Button, the "Yellow Screen of Death" appears, indicating that an unhandled exception has occurred. Behind the scenes, this information was recorded to the Windows event log's Application section.

The "Yellow Screen of Death" is Displayed in the Face of an Unhandled Exception

The Unhandled Exception's Details are Logged to the Windows Event Log

The Default Health Monitoring System Configuration
By default, ASP.NET 2.0 applications have Health Monitoring enabled and log all error events and failed audits to the Windows Event log. You can view or modify this default functionality for the entire web server through the machine-level Web.config file in the %WINDOWS%\Microsoft.NET\Framework\version\CONFIG folder. In the sample configuration above, I used the <clear /> statement in each section to remove the default settings before specifying my own.

In addition to including the "EventLogProvider" log source, the default configuration includes two other providers with the following names:

• "SqlWebEventProvider" - uses the SqlWebEventProvider class to log event information to a SQL Server database. The default configuration uses the connection string name "LocalSqlServer", which maps to the ASPNETDB.MDF database in the App_Data folder. This is the same database used by the Membership system by default. (See Examining ASP.NET 2.0's Membership, Roles, and Profile for more information on Membership.)
• "WmiWebEventProvider" - uses the WmiWebEventProvider class to log event information using Windows Management Instrumentation (WMI).

There are additional log source providers in the .NET Framework, but they are not included in the <providers> section by default. To add these or to customize those providers specified by default, you will need to add a <providers> element in Web.config like we did in the above example.

There are also a number of pre-defined event sets specified in the <eventMappings> section. See the machine-level Web.config file for a full list. For a full list of the events built into the .NET Framework, check out the System.Web.Management namespace. All of these events are derived from the WebBaseEvent. They are further grouped into categories by their type hierarchy. For example, all request events are derived from the WebRequestEvent class (which is derived from WebBaseEvent).

The remainder of this article explores how to use the "SqlWebEventProvider" log source to log particular errors to a SQL Server database.

Logging Events to SQL Server
In order to have the Health Monitoring system log errors to a SQL Server database, we need to do two things:

• Configure the web application's Health Monitoring settings to log the events to a SQL Server database, and
• Add the necessary schema information to the database that will be used as the log source

If you use the default data store for the "SqlWebEventProvider" log source (the ASPNETDB.MDF database in the App_Data folder), the database will automatically be created the first time the Health Monitoring system records an event. If you want to use an alternate database, you need to use the ASP.NET SQL Server Registration Tool (aspnet_regsql.exe). You can run this from the command line using the following arguments:

-- For a trusted connection... aspnet_regsql.exe -E -S serverName -d database -A w -- When using SQL authentication... aspnet_regsql.exe -U userID -P password -S serverName -d database -A w

The aspnet_regsql.exe program is found in the %WINDOWS%\Microsoft.NET\Framework\version directory. You'll also find a file named InstallWebEventSqlProvider.sql in that same folder that contains the T-SQL script used to install the Health Monitoring schema.

The Health Monitoring schema is very straightforward - it includes a table, aspnet_WebEvent_Events, and a stored procedure, aspnet_WebEvent_LogEvent. That's it! When an event occurs that the Health Monitoring system is monitoring and configured to log to the "SqlWebEventProvider" log source, the aspnet_WebEvent_LogEvent stored procedure will be executed, adding a new record to the aspnet_WebEvent_Events table.

Once the SQL Server schema has been applied (again, you won't need to do a thing if you opt to use the ASPNETDB.MDF database in App_Data), add the following <healthMonitoring> section to Web.config. This configuration information instructs the Health Monitoring system to log all error events and all application events using the "SqlWebEventProvider" log source. The configuration settings re-register the "SqlWebEventProvider" provider in the <providers> section. I am using the default connection string name here ("LocalSqlServer"), but you can change this to be the name of a connection string registered in Web.config's <connectionStrings> section if you want to use a logging database other than ASPNETDB.MDF.

<configuration>     <system.web>       <healthMonitoring enabled="true">        <eventMappings>           <clear />                     <!-- Log ALL error events -->           <add name="All Errors" type="System.Web.Management.WebBaseErrorEvent"                startEventCode="0" endEventCode="2147483647" />                     <!-- Log application startup/shutdown events -->           <add name="Application Events" type="System.Web.Management.WebApplicationLifetimeEvent"                startEventCode="0" endEventCode="2147483647"/>        </eventMappings>        <providers>           <clear />                     <!-- Provide any customized SqlWebEventProvider information here (such as a different connection string name value -->           <add connectionStringName="LocalSqlServer" maxEventDetailsLength="1073741823"                    buffer="false" bufferMode="Notification" name="SqlWebEventProvider"                    type="System.Web.Management.SqlWebEventProvider" />        </providers>        <rules>           <clear />           <add name="All Errors Default" eventName="All Errors" provider="SqlWebEventProvider"                    profile="Default" minInstances="1" maxLimit="Infinite" minInterval="00:01:00"                    custom="" />                     <add name="Application Events Default" eventName="Application Events"              provider="SqlWebEventProvider" profile="Default" minInstances="1"              maxLimit="Infinite" minInterval="00:01:00" custom="" />        </rules>       </healthMonitoring>     </system.web> </configuration>

With this configuration information in place, whenever the application starts or stops or whenever there is an error event, the event information will be logged to the ASPNETDB.MDF database in the App_Data folder. (If this database does not exist, it will be automatically created.)

The download available at the end of this article includes a simple website application demoing this functionality. It consists of two pages, Default.aspx and Log.aspx. Default.aspx contains a Button control that, when clicked, raises an ApplicationException. Log.aspx uses a GridView, DetailsView, two SqlDataSource controls to display the current events information in the aspnet_WebEvent_Events table.

Note that each event has an associated EventCode value. See Erik Reitan's FAQ - Health Monitoring in ASP.NET 2.0 blog entry, which includes (among other useful information) a table mapping event codes to event types.

Conclusion
ASP.NET 2.0's built-in Health Monitoring support makes it easy to automatically log specified events to specified log sources. In this article we examined two of the built-in log sources, "EventLogProvider" and "SqlWebEventProvider", which log event information to the Windows Event log and a SQL Server database table, respectively. The Health Monitoring system can also capture custom events and use other log sources. In future articles we will explore more log sources and even see how to create our own log sources. We will also look at creating our own events, as well as how to programmatically raise an event.

Until then... Happy Programming!

By Scott Mitchell

转载于:https://www.cnblogs.com/jisiki/archive/2007/03/20/681018.html