How to pick a log level

While I, in no way, feel that I am the expert in this area this is how I select which log level I use for a message.  The number of applications that fail to have a coherent strategy for this is mind boggling.  Logging should not be a second thought or something that doesn't matter.  Especially when fixing a bug is extremely time sensitive, the more information you can concisely pack into a log message the better.  So here are the guidelines I use for selecting the log level I am going to use.

1. Debug - Messages necessary for debugging a piece of functionality.  A value of some sort should always be appended to the message as there is very little that can be gleaned from the state of the application if you don't know some values.  If there is only one concatenation, I am not concerned with enclosing it in isDebugEnabled, but if there are more than one, if you have an object that calls toString() or if you have multiple log statements, it should be enclosed in isDebugEnabled.
   
2.  Info - Informational messages, can be anywhere but these should be used very infrequently.  These should not be concatenated so there is no real reason to use isInfoEnabled.  An example of an info message would be to notify a user who is watching the log that a long running process has finished or something like that.
3. Warn - Use these whenever the application is in danger of getting into a state that could cause an issue.  For instance, if a call to the database returns 2 values when it should have only returned one but it is still valid to just take the top one, it would be prudent to log a warning to say what is happening so, if it ends up causing a problem we can see it in the log.  Also, warnings are typically the default level used in production applications by default.  That means that, from warn on, you can usually count on the message getting logged even in production.  When choosing if I'm going to append information from the state of the application, I try to be very careful to take the impact of that decision into consideration.
   
4. Error - This should be self explanatory.  I will stop short of saying this should be in every exception handling block, but it should be in most.  At the very least it provides a way for us to know when an exception occurs where it is normally swallowed.  I will say that we should NEVER, EVER swallow exceptions.  By swallowing, I mean: try { ... } catch (Exception e) {//no code to handle the exception}.  A log message is the very least we can do.  In addition, the method log.error(String message, Throwable t) is the only one to use here.  Do not append the output of e.getMessage() as the really useful information is in the stack trace and should be captured.
5. Fatal - I don't think there is much reason to do this in web applications, but if we do find a place, this is for problems that will probably take the server down.  Losing connectivity to the database would be an example of a fatal exception where we would need to restart the machine.

There are two caveats to this list.  Some loggers include a trace level.  I feel this is unnecessary and, if it is actually done, should probably be done by injection with AOP.  The idea of cluttering up the code with "entering this method... ", exiting this method..." makes me shudder.  If I wanted to read through 25 lines of log messages in order to get to the real code.... well... I don't want to do that.


The second caveat is some applications have a monitoring tool like Nagios that looks for errors and sends out an alert.  If this is the case in your system, you probably either want to be discrete with your use of error, monitor fatal instead of error or implement your own log level for bugs that are serious enough to set off a pager at 3 am.  I think, in most cases, I personally like the 2nd option because most applications have no need for Fatal and, when you do get one it is cause for serious concern.

So that's my method.  Perhaps some of you out there have others.  Remember, sharing is a good thing. :)

Related articles by Zemanta

• Random thoughts on Logging (sdk.org.nz)

James Gosling leaves Oracle

There's not really much good that can be inferred from Gosling leaving Oracle and his comments don't do anything but solidify that inference. 

"As to why I left, it's difficult to answer: Just about anything I could say that would be accurate and honest would do more harm than good," he said.

Really?  This doesn't give me great hope for the direction Oracle is steering Java.  If mod_plsql is any indication as to what an Oracle influence on a programming language would be I think those of us who make a living writing Java code may want to start expanding our horizons with more urgency.  


In my opinion, as long as they leave the JVM alone they can have the language.  As more and more alternatives come along, the language itself seems like a detail.  It's one of the reasons I think Microsoft's decision to chase after Java with C# is fruitless because they are chasing a dying language.  Dying... but far from dead as so many others are quick to call it.  Java is used in almost every sector of every business world-wide.  Languages like that don't just die.  Disagree?  Why then are people still writing new applications in Cobol?  I believe that there are some businesses that will still be using Java about 20 years from now.  However, for better or worse, the fact that Oracle has their hands in it means it's going to change... somehow.  More and more it seems like those changes don't jive well with the old guard from Sun.

http://www.reuters.com/article/idUSTRE63B4HV20100412

10 Useful Google Spreadsheet Formulas

Ran across this one in my reader today and I realized I could probably replace half the crappy software built for investors today with a Google spreadsheet and the Google Finance functions.


http://woorkup.com/2010/02/19/10-useful-google-spreadsheet-formulas-you-must-know/

Staying on topic - an off topic rant

Why is it so difficult for bloggers to stay on topic?  At CheckedException, I really try hard to keep the posts focused on technology because that's what I said I was going to talk about.  To me, it's like a contract... I tell you what I'm going to say, you decide if you want to read.  You may read a few times and think I'm full of crap, but at least I've fulfilled my contract with you and, of course, you're free to stop reading at any time.

To clarify, I'm not talking about the occasional off-topic post or rant(like this one) where you have no other outlet but your blog.  I get it.  What annoys me is when the incessant posts about your trips, your skiing, your kids and all the rest of the things in your life start to outnumber your posts relevant to the reason I subscribed to you in the first place.  Most people subscribe to your blog for the content, what they might learn, to get a pulse on what people are thinking in the industry, and so on.  To me, if you are a technical blogger and your only recent posts are about your day skiing, you have broken your contract.  I told a fairly popular blogger that one time because his recent posts were all related to politics or skiing, or his kids, and just about everything else BUT technology.  His response was, "I'd be happy to give you a refund."  Cute... but missing the point.  Unsubscribe.

Of course it's your blog and you can write about whatever you want.  But if you tell people you are going to write about one thing and then you write about something completely different you have failed those of us who subscribed to your blog in the first place because we thought you might actually have some insightful things to say.  When you use your blog as a sign that says, "Hey everyone, look how frickin awesome my life is!" I start to think that if I ever had to have a conversation with you it would end with me punching you in the face for being a pompous douchebag. 

Jealous?  Sure,  I'll admit that I'd love to play hookey because we got 15 inches of powder the night before.  I just think I'd tell everyone about it on Facebook rather than over my blog where I told people I would be writing about technology.

I'm not asking for you to not have a life.  I'm simply asking you to stay on topic and, if you want to write about something else, start another blog and for the love of semicolons, keep the RSS feeds separate!!!