Logger Level Confession
March 25th, 2008
I confess…I never know what log level to use. Some levels make sense to me:
- SEVERE – the program is about to exit
- WARNING – bad, but I’ll keep on running
Those two levels should always appear in the log, because they indicate bad things that must be fixed.
But the remaining levels are a mystery to me: INFO, CONFIG, FINE, FINER, FINEST. In my opinion, there are too many choices. I believe the overall power of an API diminishes as you add more choices, particularly if these choices are ambiguous and subjective. I believe that no two programmers will interpret the choices in exactly the same way.
I figure I’ll stick with INFO, WARNING, and SEVERE.
You can create your own log level; in your case I suggest making one called WHATEVER.
I use the fine level when I want to communicate something that is interesting but not necessarily important, like finding out that there was water on Mars a million years ago. Finer is useful when the code is entering a state of mild interest, like gossip you might read regarding the French president and his mistress or Britney’s latest court date; I guess it’s news but my day would be the same without knowing it. Finest logging level is reserved for things that are the least amount of useful knowledge but might be interesting to someone out there, like how much of the national anthem would fit if written on a grain of rice or the number of balls that the world-record holder of juggling can keep in the air at the same time. This strategy has helped me make the most out of all the logger API levels.
I agree. There should be a standard policy and everyone should stick to it.
But because that’s not the case, recently I thought long and hard about which log levels to use when and this was what I came up with:
http://www.databasesandlife.com/which-log-levels-to-use-when/
I agree with your three choices, but you might also use CONFIG. I’m guessing that’s for logging of application configuration settings that were in effect, if any.
Fine choice.
The others are only useful to programmers when they’re building or debugging it. We do this because we’re not supposed to use print statements.
So, on a production system, you’ll set the threshold to WARN? But then if there is a problem, the logs are pretty much empty. I prefer to set the threshold to INFO and log user actions at the INFO (e.g. ” deleted Contract” or ” listed Documents matching “A%”). That way when there is a problem there is some context. Then I log information useful for debugging problems at FINE (or DEBUG if using log4j).
My usual set is NFEWID: None (don’t even bother opening the log file), Fatal (log fatal errors only), Error (only log if there was something actually wrong with the data or ops), Warning (odd but usable), Info (normal operations), and Debug (excruciating detail, sometimes with specific flags for what chunks of code I want to spew like that, everything else being in Info mode).
I stick to Debug, Info, Warning and Severe. I add debug to help with program flow when troubleshooting bugs and slowdowns.
@Eric: Maybe it’s time for a comic of how Apple, Google, and your company does logging 8^).
I’m a bit embarrassed but here goes:
DEBUG: Kitchen sink logging level. Everything including variable values, return values, HTTP Response, stack traces, Hi, Mom’s, etc.
INFO: Program execution trace. Like we don’t know how to use a debugger, but meant more for our test servers running our web applications in a QA environment (where yeah, we don’t have debuggers).
WARNING: An error occurs, we’re not sure of the impact, it’s probably bad, we better log it.
ERROR: A bad error occurs, we’re not sure of the impact, we figure prod logs might need it.
FATAL: I’ve never seen one explicitly declared, but that’s what we have PROD set to (see the ERROR level where the developers think PROD is set to).
We don’t see to many production errors logged. Wonder why…. 8^P