Health Monitoring, just like tracing, lets you review of a running applications state, stability, performance. It can be used for a number of reasons, such as:
- Getting notified of errors
- Catching errors
- Performance analyze
- Inspecting the payload of an application.
The Basic Structure of Health Monitoring
To enable health monitoring, head for the web.config, and search for the system.web section. The markup is the following:
<healthMonitoring Enabled=”true||false” heartBeatInterval=”seconds”>
To set up providers, use the providers section. To register and process events, add them to the eventMappings element. The rules section is used to connect to two.
The following events are available (and are already registered in your machine.config file):
- Heartbeats: these are raised regularly (timespan specified in the heartBeatInterval attribute), and provides information about the running process (CPU, memory, etc.).
- Application lifetime events: these events are related to the lifetime of the application, such as Application_Start, shutdown, session-related events, etc.
- Security audit events: these are events related to secrity, such as successful or failed logons.
- Request– and response-based events: events related to HTTP requests.
- Errors: as the name implies, these events are related to errors of an application.
As mentioned above, these events are already registered in your machine.config file, but it can be further extended by the following events (of which some are already registered. Before you add some, check your machine.config):
|Health Monitoring Events|
|All Event||WebBaseEvent: mapping for all events available.|
|HeartBeats||WebHeartBeatEvent: information about the process in regular intervals.|
|Application Lifetime Events||WebApplicationLifetimeEvent: information about the lifetime events of an application.|
|Request Processing Events||WebRequestEvent: events that are occouring during request processing.|
|All Errors||WebBaseErrorEvent: events for all errors.|
|Infrastructure Errors||WebErrorEvent: errors of the runtime included.|
|Request Processing Errors||WebRequestErrorEvent: errors of a request process.|
|All Audits||WebAuditEvent: general class of security events.|
|Failure Audits||WebFailureAuditEvent: catches all failed audit events, such as failed logins or access denied errors.|
|Success Audits||WebSuccessAuditEvent: succeeded audit events.|
To catch these events, you should declare providers for them. There are no restrictions of which provider can process which event, so use any one of them. There are five base providers which you can use (or extend):
- EventLogProvider: a provider that add events to the event log.
- MailWebEventProvider: send event notification to an email address when the event occurs.
- SqlWebEventProvider: uses a SQL server database to add event data. You can use InstallWebEventSqlProvider.sql located in the .NET framework library to prepare a database.
- TraceWebEventProvider: add event to the ASP.NET trace.
- WmiWebEventProvider: publish events through WMI.
To set up a provider for an event, you should use a similar syntax:
<add name=”MyProvider” type=”System.Web.Management.SimpleMailWebEventProvider” from=”firstname.lastname@example.org” to=”email@example.com” subjectPrefix=”My Subject”/>
<add provider=”MyProvider” name=”A name you like” eventName=”friendly name of the event, such as Application Lifetime Events”/>
You should not add your event (Application Lifetime Events) to the eventMappings section, as it is already defined in web.config. You should specify the provider in the providers section, including its name, the type, and the data related to the mail address. Then at the rules section, you should sign up your provider to the event. In the provider attribute, you should add the provider name, and the eventName attribute should be set to the friendly name of the event in which you are interested in.