After reading an article about the subject from O'Reilly, I wanted to ask Stack Overflow for their thoughts on the matter.
+3
A:
I'd say no, given that a fairly large percentage of server errors involve problems communicating with databases. If the database were on another machine, network connectivity would be another source of errors that couldn't be logged.
If I were to log server errors to a database, it would be critical to have a backup logger that wrote locally (to an event log or file or something) in case the database was unreachable.
MusiGenesis
2008-11-14 15:02:59
That is a good point. Sure, you can check to see if everything is good before logging, but what if something happens after the check? Or what do you do with the data to log after the check? Two things not addressed in the article, at least from what I saw.
Thomas Owens
2008-11-14 15:07:05
+13
A:
Write locally to disk, then batch insert to the database periodically (e.g. at log rollover time). Do that in a separate, low-priority process. More efficient and more robust...
(Make sure that your database log table contains a column for "which machine the log event came from" by the way - very handy!)
Jon Skeet
2008-11-14 15:05:17
I like that idea better. And, if you needed the data in the DB faster, you could do it nightly, if your log rotations aren't nightly to begin with.
Thomas Owens
2008-11-14 15:07:51
Wouldn't that mean the log info in the database is always kind of out of date, and thus would serve mainly as an archive instead of something you would use to diagnose recent problems?
MusiGenesis
2008-11-14 15:24:13
In terms of diagnosing today's issues, you'll face a challenge like that no matter how you handle current logs (tail/grep/etc or Windows alternatives so as not to interfere with logging). Even for a problem like that, you might want to look at historical data to see if it happened before.
Dave DuPlantis
2008-11-14 15:45:25
For a busy application, I'd probably try to rotate every 15 minutes or may every hour - but it also depends on the exact app. If you've got an app which doesn't log much and which is "quiet" overnight, that would be a good time to flush the logs.
Jon Skeet
2008-11-14 15:49:33
Of course, you could try to get smart - if you logged anything "serious" the collector/inserter could flush to the database earlier :)
Jon Skeet
2008-11-14 15:50:14
@Dave: I was thinking more that if your server logs immediately to the database and only logs locally if the db is unreachable, then the db is always up-to-date (for the most part).
MusiGenesis
2008-11-14 16:00:01
A:
It probably isn't a bad idea if you want the logs in a database but I would say not to follow the article's advice if you have a lot of log file entries. The main issue is that I've seen file systems have issues keeping up with logs coming from a busy site let alone a database. If you really want to do this I would look at loading the log files into the database after they are first written to disk.
carson
2008-11-14 15:05:49
+2
A:
See this question:
http://stackoverflow.com/questions/209497/using-a-sql-server-for-application-logging-proscons
Joel Coehoorn
2008-11-14 15:25:31