Some days ago, I read this cool article about the built in health monitoring features of ASP.NET. Funny that I never stumbled across that - I always implemented my own health monitoring.
The other day I played around with the health monitoring feature and it looks really great. As a quick reference here’s a short description of the elements of the health monitoring facility:
This element describes which events are to be captured. The type attribute references one of the event types derived from WebBaseEvent. All events of that type or a derived type are captured. For example, to capture all kinds of errors in the application, type would be set to System.Web.Management.WebBaseErrorEvent, for events regarding the application lifecycle (start, restart, stop etc.) one would use System.Web.Management..WebApplicationLifetimeEvent. You can further filter on a specific range of error codes (e.g. as defined in the WebEventCodes class).
The machine wide web.config has already defined numerous event mappings for you, so it’s unlikely that you need to define your own:
- All Events, captures all events (WebBaseEvent and below)
- Heartbeats, captures events that are automatically generated by ASP.NET in a given interval as defined by the heartbeatInterval attribute of the healthMonitoring section (WebHeartbeatEvent)
- Application Lifetime Events, captures compilation, application startup, restart, shutdown (WebApplicationLifetimeEvent)
- Request Processing Events, raised on each and every request (WebRequestEvent)
- All Errors, captures all errors (WebBaseErrorEvent and below)
Infrastructure Errors, captures all system related errors (WebErrorEvent)
- Request Processing Errors, captures all request related errors (WebRequestErrorEvent and below)
- All Audits, captures security related events (WebAuditEvent)
- Failure Audits, captures failed audits (WebFailureAuditEvent)
- Success Audits, likewise captures succeeded audits (WebSuccessAuditEvent)
The bold part is the name of the event mapping.
Providers describe how to process an event. ASP.NET comes bundled with a good selection of providers that cover most needs, for example:
- write to the event log: EventLogWebEventProvider
- write to the ASP.NET trace: TraceWebEventProvider
- send an email when the event is captured: SimpleMailWebEventProvider and TemplatedMailWebEventProvider
- write to a sql server table: SqlWebEventProvider
Again, ASP.NET has some standard providers defined:
- EventLogProvider, writes to the event log
- SqlWebEventProvider, writes to a database using the connection string named LocalSqlServer
- WmiWebEventProvider, generates WMI events
As you see, you’ll have to setup a mail sending provider yourself, but this is shown in the article mentioned above.
EventMappings and Providers won’t do you any good unless you define a rule. It’s the rules that actually activate the health monitoring system: they link providers and event mappings. Use the “eventName” attribute define the set of events to be captured and the “provider” attribute to decide what to do with those events.
You can configure additional settings, like
- how often has an event to be raised before the provider performs its action (minInstances)
- how often may events occur before processing is stopped (maxLimit), may have the value “Infinite” or an integer
- what is the interval within which consecutive occurrences of an event are ignored (minInterval)
Instead of defining the settings above with each and every rule you can – and should - use profiles instead (see below).
As with the other elements there are two prefab rules, both of which use the EventLogProvider to write events to the Windows event log:
- All Errors Default, logs “All Errors” at a minInteval of 1 minute
- Failure Audits Default, logs "Failure Audits" also at a minInterval of 1 minute
As mentioned above, profiles are used to centralize the configuration of the settings minInstances, maxLimit and minInterval. Simple define a profile, name it and use this name as the value of a rule’s “profile” element. Nothing fancy, but useful.
Two profiles are defined in the global web.config:
- Default: minInstances = 1, maxLimit = Infinite, minInterval = 1 minute (00:01:00)
- Critical: minInstances = 1, maxLimit = Infinite, minInterval = 0 seconds (00:00:00), that is each occurrence will be processed
Finally, we have the buffer modes. If you enable buffering on a provider (buffer=”true”) you also need to define how the buffering is done by referencing a specific buffer mode (bufferMode=”name of a buffer mode”). According to the documentation, buffer modes only apply to the SQLWebEventProvider, but I haven’t checked that.
The global web.config defines four buffer modes, ranging from least aggressive buffering for critical events to large buffers for non-crucial events:
- Critical Notification
For details of the configured values, look at your global web.config or at the documentation.