Shane Duffy

Archive for September 3rd, 2007

The Microsoft Enterprise Library has a really good Logging Application Block that allows you to make your logging infrastructure configurable.

This framework makes logging as easy as typing:

Logger.Write(“System rolled over!”);

the framework is configurable from your config file.

The Microsoft Enterprise Library out of the box provides the following destinations for logging messages:

  • Email
  • Custom Locations
  • Message Queues
  • WMI Events
  • Database
  • Text Files
  • File

I took our web site and our main global error handler and did a dump routine of all exceptions to the log and it worked great. But the question arose – where should we log? Here are some of our ideas that spring to mind on this issue.

  • The least error prone seems to be the flat file. The custom location seems the worst option simply we would hope that our proprietary code is less tested in less real world scenarios than Microsoft’s Enterprise Library components.
  • The idea of logging to the database is attractive from a reporting perspective, but everyone on the team felt like it was risky given that the most typical scenario for an error in the application itself was a database related error. I suppose if we had the logging database seperate from our application database then this would reduce the risk, but we don’t have the resources for such a move, so if our application were to kill the database it would take down any logging sources there as well.
  • Even with the flat file, it is possible that it will fail. A simple scenario for it failing would that the file is read-only or the ASPNET process doesn’t have permission to access the file. So we need at least two logging mechanisms to provide redundancy. The Enterprise Library allows for this – you can configure more than one listener for every log message being written.
  • Our second challenge with using flat files is that they no provide a notification mechanism like email. So if there is an exception, the file has to be constantly monitored or periodically checked. Therefore, combining an email message and a flat file backing store seemed like a decent combination. If the email fails, then we may not know for a day or two but at least the error will be logged. If the file fails, then at least we’ll get the email.
  • The event log is not a bad option either and its generally easier to monitor as most monitoring tools already handle event log monitoring. The one issue with using the event log that I have found is that if you use an event log source that doesn’t exist the logging will fail without any notification to you. Your error will simply disappear and won’t be logged. You can use any existing EventLog source or create a new one in the registry for your custom logging needs. In addition, you have to make sure that the ASPNET account has permission to write to the event log.

That’s where we are at so far – its not quite bullet-proof yet but its getting there. If you have any further suggestions or thoughts, leave them as a comment!


Follow

Get every new post delivered to your Inbox.