To Log or Not to Log
Honestly, really? Let’s hope we’re not still asking ourselves that question in 2012 kids. Say in ain’t so!
So let’s say its safe to assume we’re all logging things somewhere.
The question is not “to log or not to log” but rather where should yon logs go? (yon logs are not to be confused with yule logs, though if Santa were a developer I suppose .. nevermind)
Where to log our well, logs? I think the answer is simple. Now I have few hard and fast development rules but like you, when I do make them, they are always right (some of you will get that in a few minutes).
Here though, is the Rob Horton Logging Rule.
“Logs are always text-file-based and never done anywhere else because anywhere else is dumb.”
Let the holy war begin. I stand before you, development community, and I say if you’re logging to anywhere other than a text file you are wrong, I am right, and you need to change how you do things. Mwhahahaha!
(ladies and germs you simply must get yourself a blog because if you don’t already have one, they are a perfect place to make riotous statments like that without getting pansed at the office coffee bar .. just sayin’)
Ahem. Back to logging.
The biggest question most of us have is where should we drop our logs. While that last statement cries out for a follow-up comment using bathroom humor, this blog is above such things and chooses to merely circle the rim of such frivolity while watching other technical blogs flush their credibility by making number ONE .. bathoom jokes and number TWO .. more bathroom jokes.
Where were we? Ah yes, dropping logs. Face front class!
As developers, what do we get from logging?
- Application state during a point of failure or success.
The end.
We use logs as markers of what happened and what was going on when it happened. So where should we best keep this information? Yep, good ol’ text files.
But …
- Some of you are screaming .. databases! Wrong.
- Some of you are screaming .. even log! Wrong.
- Some of you are screaming .. email! Dear lord I hope you’re not THAT wrong.
Let’s think it through for a moment, ya’ll. What do we actually DO with our logs?
- We look at them physically on screen as developers …
- We sometimes email them to ourselves for safe-keeping …
- We sometimes parse them for reporting to Mr or Mrs BigCheck in the corner office …
Most of this though never happens unless there are problems. Something breaks, check the logs. Something doesn’t show up in a file transfer to an external client, check the logs. Etc, etc.
The one over-arching thing I think we can all agree on is that the act of logging should NEVER cause an application to break.
If logging fails it should just fail quietly into the night, perhaps with an email shot across the bow, saying “Ouchie, I couldn’t even log this message. Yes things are THAT bad. Calling a technical recruiter may be a good idea.”
You guys don’t log messages like that? Shame on you. Have some fun. This is IT after all!
Ok, let’s be serious for a moment.
So we need a log to be ….
- “Always available” or at least “as available as possible” which means as few points of failure as possible.
- We need a backup notification strategy in case the primary log does fail quietly. Redundancy is good and also redundancy is good.
Text files work best for this is in most cases because they easily meet all our conditions.
Logging to a databases is not good because the database is another point of failure (db connections, access/permissions, db could be offline for maintenance, etc)
While you can argue that text files could have similar problems and you’re right, the chances of it happening are far fewer. When was the last time you had a database access problem? When was the last time you couldn’t access a local path on your server? I rest my big ATX case.
Closing thought
There is a certain amount of risk in everything we do. Anything CAN fail. What we do is analyze the risk and reduce it where ever possible. Anything CAN be asked to be part of the next big migration or reporting strategy. So another part of what we do is try to write applications that will make those possible things less painful in the future.
So the question becomes how much risk are you willing to accept? Build your logging solution around that.
Remember this has all been about my rule and remember (for me) it’s right. I’m sure you have your rule and it’s right too. Comments are welcome!