Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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

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?

like image 510
Sietse Avatar asked Oct 09 '08 11:10

Sietse


People also ask

What should I log at information level?

You use the INFO logging level to record messages about routine application operation. Those are entries you usually don't care that much about, to be honest. If things go bad during development, you'll be looking at DEBUG entries. When things go bad in production, ERROR entries are what you're looking for.

What should be the log level in production?

Log at the Proper LevelTRACE level: this is a code smell if used in production. This should be used during development to track bugs, but never committed to your VCS. DEBUG level: log at this level about anything that happens in the program.

What are the five levels of logging?

The possible values are: QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, DEBUG1, DEBUG2, and DEBUG3. The default is INFO.


1 Answers

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.

like image 85
Cowan Avatar answered Sep 17 '22 13:09

Cowan