ASP.NET Logging - log4net or health monitoring?

Question

I'm looking at a fresh asp.net site in 3.5 that has absolutely no error handling or logging. What are some good options for logging and handling errors? I've used Log4Net on the 1.1 framework but hear there are potentially better options in 3.5.

Answer 1

One option is ELMAH. I asked a question about it here: http://stackoverflow.com/questions/583307/asp-net-error-handling.

Since then, I have implemented a slightly modified version of it and the logging plus e-mail is great and easy to integrate via the web.config file.

Answer 2

Enterprise Library maybe has a learning curve but is a good project.

In Asp.Net follow david hayden's article Enterprise Library 2.0 Logging Application Block

Answer 3

If you are used to log4net, stick with what you know. It's easy, fast, and works well. I've used it for years in 1.1, 2.0, and now 3.5.

Answer 4

ASP.NET Health Monitoring actually does a pretty decent job right out of the box!

MSDN, How to: Send E-mail for Health Monitoring Notifications

Answer 5

Personally, I havent tried log4net but seen the specs and examples for winforms, but my organization coded our own logging mechanism that reports and logs errors that are caught in the global.asax that reports everything we need to know about the stack trace, session (if exists), form's NVC, version of the app, URL that originated the error with querystring, and HTTP headers. Though I noticed that not all errors get logged there; such as forms authentication expiration or application pool restart/shutdown or anything reported by IIS that was not thrown by the application executing.

Answer 6

We use two options for our logging:-

ELMAH for unexpected exception handling

NLog for expected, manual (debug, info and error) information.

ELMAH is a great out-of-the-box plugin that automatically captures exceptions (from 404's (page not found) to 500 exception thrown) and has a built in web-ui to visualize these errors. So it's a really quick and effective way of grabbing unexpected errors that occur.

Now NLog compliments this by having our developers manually insert debugging information into the code at specific spots, so when we need to get information out of a non-locahost system, it's very easy. For example, we litter log.Debug(..) code in most of our methods to see what the local variables are or returned values, etc. For more important information, we then use log.Info(..) .. but use this a lot less. Finally, for serious errors which we have trapped and handle, we use log.Error(..) or log.Warn(..) .. generally inside some try/catch scopes. So on our test or live servers, we then turn on all logging states (eg. Debug and greater) if we need to grab LOTS of data, live... or just the general important information, such as Info states and greater. We always have Warn, Error and Fatal states always on. Debug state generates a LOT of data, so we use that only sparingly.

So to summarize, I suggest you use TWO approaches to your WebApp. Elmah for excellent unexpected error trapping and NLog for expected information and errors.

Finally, NLog is WAAAY easier to use/get working than Log4Net. It basically superceeds it, IMO.