(Windows) Exception Handling: to Event Log or to Database?

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

One note about writing to the event log: that requires certain permissions for your application users that in some environments may be restricted by default.

Where I'm at we do most of our logging to a database, with flat files as backup. It's pretty nice, we can do things like get an RSS feed for an app to watch for a few days when we make a change.

Answer 2

One thing that needs considering about event logging is that there are products out there which can monitor your servers' event logs (like Microsoft Operations Manager) and intelligently do notification, and gather statistics on their contents.

A "minus" of SQL-based logging is that it adds another layer of dependencies to your application, which may or may not always be acceptable. I've done both in my career. I once or twice even used a MSMQ based message queue to queue log events and empty the queue into a MSSQL database to eliminate the need for my client software to have a connection to the DB.

Answer 3

I wouldn't log straight to the database. As you say, database issues become tricky to log :)

I would log to the filesystem, and then have a job which bulk-inserts from files to the database. Personally I like having the logs in the database in the log run primarily for the scaling situation - I pretty much assume I'll have more than one machine running, and it's handy to be able to effectively have a combined log. (Each entry should state the machine it comes from, of course.)

Report and viewing apps can be done very easily from a database - there may be fewer log-specialized reporting tools out there at the moment, but pretty much all databases have generalised reporting functionality.

For ease of logging, I'd use a framework like log4net which takes a lot of the effort out of it, and is a tried and tested solution. Aside from anything else, that means you can change your output strategy with no code changes. You could even log to both the event log and the database if necessary, or send some logs to one place and some to the other. (I've assumed .NET here, but there are similar logging frameworks for many platforms.)

Answer 4

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.