Question

I’ve worked in shops where I’ve implemented Exception Handling into the event log, and into a table in the database.

Each have their merits, of which I can highlight a few based on my experience:

Event Log

• Industry standard location for exceptions (+)
• Ease of logging (+)
• Can log database connection problems here (+)
• Can build report and viewing apps on top of the event log (+)
• Needs to be flushed every so often, if alot is reported there (-)
• Not as extensible as SQL logging [add custom fields like method name in SQL] (-)

SQL/Database

• Can handle large volumes of data (+)
• Can handle rapid volume inserts of exceptions (+)
• Single storage location for exception in load balanced environment (+)
• Very customizable (+)
• A little easier to build reporting/notification off of SQL storage (+)
• Different from where typical exceptions are stored (-)

Am I missing any major considerations?

I’m sure that a few of these points are debatable, but I’m curious what has worked best for other teams, and why you feel strongly about the choice.

Answer 1

You need to differentiate between logging and tracing. While the lines are a bit fuzzy, I tend to think of logging as ‘non developer stuff’. Things like unhandled exceptions, corrupt files, etc. These are definitely not normal, and should be a very infrequent problem.

Tracing is what a developer is interested in. The stack traces, method parameters, that the web server returned an HTTP Status of 401.3, etc. These are really noisy, and can produce a lot of data in a short amount of time. Normally we have different levels of tracing, to cut back the noise.

For logging in a client app, I think that Event Logs are the way to go (I’d have to double check, but I think ASP.NET Health Monitoring can write to the Event Log as well). Normal users have permissions to write to the event log, as long as you have the Setup (which is installed by an admin anyway) create the event source.

Most of your advantages for Sql logging, while true, aren’t applicable to event logging:

• Can handle large volumes of data: Do you really have large volumes of unhandled exceptions or other high level failures?
• Can handle rapid volume inserts of exceptions: A single unhandled exception should bring your app down – it’s inherently rate limited. Other interesting events to non developers should be similarly aggregated.
• Very customizable: The message in an Event Log is pretty much free text. If you need more info, just point to a text or structured XML or binary file log
• A little easier to build reporting/notification off of SQL storage: Reporting is built in with the Event Log Viewer, and notification systems are, either inherent – due to an application crash – or mixed in with other really critical notifications – there’s little excuse for missing an Event Log message. For corporate or other networked apps, there’s a thousand and 1 different apps that already cull from Event Logs for errors…chances are your sysadmin is already using one.

For tracing, of which the specific details of an exception or errors is a part of, I like flat files – they’re easy to maintain, easy to grep, and can be imported into Sql for analysis if I like.

90% of the time, you don’t need them and they’re set to WARN or ERROR. But, when you do set them to INFO or DEBUG, you’ll generate a ton of data. An RDBMS has a lot of overhead – for performance (ACID, concurrency, etc.), storage (transaction logs, SCSI RAID-5 drives, etc.), and administration (backups, server maintenance, etc.) – all of which are unnecessary for trace logs.