How to determine which log level to use?

Question

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

I saw some projects that are annoyingly verbose at the INFO level, but I also saw code that affects the DEBUG level too much. In both cases, useful information is hidden in noise.

What are the criteria for determining journal levels?

Answer 1

I do not think that there are any strict rules; using levels like log4j, my thumb rules look something like this:

• FATAL : The application (or at least the thread) is about to die awfully. Here the information explains why this is happening.
• ERROR : something the application should not do. This is not a user error ("invalid search query"); this is an approval error, network problem, etc. etc., probably the one that is going to interrupt the current operation.
• WARN : something that concerns, but does not lead to, the termination of the operation; the number of connections in the database pool, low, unusual, but expected timeout in operation, etc. I often think of WARN as being useful in the aggregate; for example grep, group and count them to get an idea of ​​what affects the state of the system.
• INFO : normal recording of that part of the normal operation of the application; so you can go back and say "how often does this operation happen on a large scale?" or "how did the user data get into this state?"
• DEBUG : disabled by default, can be enabled to debug certain unforeseen problems. Here you can register detailed information about the parameters of key methods or other information that is useful for finding probable problems in specific "problem" areas of the code.
• TRACE : "Seriously, is WTF happening here ?!

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

Answer 2

Informally, I use this hierarchy,

• DEBUG - actual trace values
• INFO - Something happened - nothing important, just a flag
• WARN - everything works, but something is not quite what was expected
• ERROR - something happened that needs to be fixed, but we can continue and perform other (independent) actions.
• Fatal is a serious problem that we should not even carry out

I will generally issue INFO with the registration, but only if I know that the log files are actually being viewed (and the size is not a problem), otherwise WARN.

Answer 3

Think about who should use each level. In my code, I keep DEBUG reserved for developer output, for example. an output that would only help the developer. VERBOSE is used for the average user when a lot of information is required. INFO I usually use ordinary events (for example, sending a web page, checking something important).

Both FAIL and WARN are pretty clear.

Answer 4

The convention on my team is to use debug if something is being computed in the message, while info used for plain text. In this way, the info effect will show you what is happening, and debug will show the values ​​of the events that happen.

Answer 5

I tend to target INFO on a user to give them messages that don't even alert. DEBUG tends to be used for developers when I output messages to help trace the flow through the code (also with variable values).

I also like another level of DEBUG (DEBUG2?), Which gives absolute bucketloads of debugging information such as hexadecimal dumps of all buffers, etc.

Answer 6

No need for DEBUG2 level. What is TRACE for? TRACE is designed for the absolute minimum level of registration, displaying all possible pieces of information that you might want to see.

To avoid a flood of information, it is usually not recommended to include trace protocols for the entire project. Instead, use "DEBUG" to find out general information about the error and its location (hence the name), and then enable TRACE only for this component if you still cannot understand it.