What logging listener should be used in production? (ASP.NET / Logging Application Block)

537 Views Asked by At

I'm using MS Enterprise Logging Application Block in an ASP.NET website.

For production launch, I will set up a log listener in one of these locations:

  • Sql Server database
  • Windows event log
  • Text files

Which has the least impact on performance?

NB - I can't switch to Log4Net or ELMAH at this point, so please don't suggest that in your response.

3

There are 3 best solutions below

1
On BEST ANSWER

I ended up using this configuration in prod:

  1. FormattedDatabaseTraceListener for messages with severity "error" and "critical".
  2. Flat file trace listener for specialSources in case logging database is down.

Anything with lower severity, we are not logging.

4
On

We use event log, and that doesn't seem to impact performance. I can't properly tell you the difference between each one... when it comes with a database, it depends. Is the database on the same machine, or a different machine? Is it half-way across the country?

Typically, the database is fast, but network latency can slow down the process. Disk IO is usually pretty fast too. Disk IO for logging can grow rapidly, and might not be the best option if you store all the logs in the same file.

Plus, consider accessibility, which one is easier to access without having to access the machine. The database would be a choice candidate in that category...

HTH.

0
On

SQL would give you the most flexibility for reporting. If you have a beefy DB setup and fast network, it might not put much additional perfroamcne burden on you over text files.

OTOH, if you're not planning on doing much log analysis, just looking at logs on rare occassions to figure out what lead to a problem, then text files are simpler to set up and manage.

Event log is ok, but if you're going to use it, consider using it only for significant errors, don't clutter it up with a bunch of unimportant messages. Use it in conjunction with SQL or text files with those significant errors logged to both locations.

Whatever you decide, test it for performance before going into production.