How to determine what log level to use? [closed]

Question

The log levels WARN, ERROR and FATAL are pretty clear. But when is something DEBUG, and when INFO?

I've seen some projects that are annoyingly verbose on the INFO level, but I've also seen code that favors the DEBUG level too much. In both cases, useful information is hidden in the noise.

What are the criteria for determining log levels?

Answer 1

There's no need for a DEBUG2 level. That's what 'TRACE' is for. TRACE is intended to be the absolute lowest level of logging outputting every possible piece of information you might want to see.

To avoid a deluge of information, it is generally not recommended that you enable trace-level logging across an entire project. Instead use 'DEBUG' to find out general information about the bug and where it occurs (hence the name), and then enable TRACE only for that component if you still can't figure it out.

Answer 2

Think about who needs to use each level. In my code I keep DEBUG reserved for a developer output, e.g. output that would only help a developer. VERBOSE is used for a normal user when alot of info is needed. INFO I use to normally show major events (e.g. sending a webpage, checking something important).

And FAIL and WARN are pretty self explanatory.

Answer 3

Informally I use this sort of hierarchy,

• DEBUG - actual trace values
• INFO - Something just happened - nothing important, just a flag
• WARN - everything's working, but something isn't quite what was expected
• ERROR - something has happened that will need to be fixed, but we can carry on and do other (independent) activities
• FATAL - a serious enough problem that we shouldn't even carry on

I'll generally release with INFO being logged, but only if I know that log files are actually reviewed (and size isn't an issue), otherwise it's WARN.

Answer 4

The convention in my team is to use debug if something is calculated in the message, whereas info is used for plain text. So in effect info will show you what's happening and debug will show the values of the things that are happening.

Answer 5

I don't think there are any hard-and-fast rules; using the log4j-type levels, my 'rules of thumb' are something like:

• FATAL: the app (or at the very least a thread) is about to die horribly. This is where the info explaining why that's happening goes.
• ERROR: something that the app's doing that it shouldn't. This isn't a user error ('invalid search query'); it's an assertion failure, network problem, etc etc., probably one that is going to abort the current operation
• WARN: something that's concerning but not causing the operation to abort; # of connections in the DB pool getting low, an unusual-but-expected timeout in an operation, etc. I often think of 'WARN' as something that's useful in aggregate; e.g. grep, group, and count them to get a picture of what's affecting the system health
• INFO: Normal logging that's part of the normal operation of the app; diagnostic stuff so you can go back and say 'how often did this broad-level operation happen?', or 'how did the user's data get into this state?'
• DEBUG: Off by default, able to be turned on for debugging specific unexpected problems. This is where you might log detailed information about key method parameters or other information that is useful for finding likely problems in specific 'problematic' areas of the code.
• TRACE: "Seriously, WTF is going on here?!?! I need to log every single statement I execute to find this @#$@ing memory corruption bug before I go insane"

Not set in stone, but a rough idea of how I think of it.

Answer 6

I tend to target INFO towards the user to give them messages that aren't even warnings. DEBUG tends to be for developer use where I output messages to help trace the flow through the code (with values of variables as well).

I also like another level of DEBUG (DEBUG2?) which gives absolute bucketloads of debug information such as hex dumps of all buffers and so on.