How to design log level names. To reflect frequency of use?

Question

I'm going to build a great system. Thinking about log level naming make me wonder.

1. Can I choose names, so the admin and the developers know which to use. Without using documentation?

It would be good if the log level also reflect how frequent they will show up in logs.

For example:

• INIT/SHUTDOWN - (appear once)
• FUNC_CALL - (appear frequent, for example in loops)
• TRACE - (several times in functions)

Now, a sysadmin would never turn on TRACE logging in production. He can safely turn on INIT/SHUTDOWN. And FUNC_CALL if there are low trafic in the system.

What is wrong with this design?

What names would you use to reflect the frequency?

(I know about WARN, INFO and ERROR.)

Answer 1

The problem with log is to be sure they will actually not be displayed too much, for this is the surest way to bring a system to a full stop.
(log files full, process much slower because of some complicated log messages to build, log conditions repeated over and over, ...)

Then, it looks like FUNC_CALL and TRACE are good names for pre-production steps, when you want see, for test reasons, what exactly is executed.

But in production should remain only functional-related logs (generally WARNING and SEVERE logs about functional features), and even those can be dangerous (especially a WARNING in a loop for several thousand instances).

So actually, whatever name you choose, you must include in the document which helps to put your application into production which exact log levels you want to keep active, and for which packages. And it will take several tries before getting it right.

Answer 2

In existing logging frameworks such as log4j, the severity level and the location in the program are two orthogonal notions.

Log4j defines the following levels: TRACE, DEBUG, INFO, WARN, ERROR and FATAL, but one can also filter the output according to the class in which the log is done.

Answer 3

I'd go with more self-describing names, like:

• EVERYTHING_IS_BROKEN_IMMEDIATE_ATTENTION_REQUIRED
• RARE_IMPORTANT_EVENT (which includes init/shutdown)
• DETAILED_EXECUTION_TRACE
• TONS_OF_DEBUGGING_INFORMATION

Maybe not exactly these ones but you get the idea — make sure it is absolutely impossible to be confused about what each log level means. (I also used the “trace” term in a more conservative sense — a list of function calls is actually a trace, so FUNC_CALL and TRACE sound as synonyms to me)

Also be sure not to make log levels that noone should disable. I personally have always found the default ERROR/WARNING/INFO levels silly because they are very misleading (is a request for a non-existing item an error?)

Also would be good if noone can (accidentally) disable EVERYTHING_IS_BROKEN_IMMEDIATE_ATTENTION_REQUIRED and RARE_IMPORTANT_EVENT levels.

Don't be afraid to use long names, IDEs will auto-complete them anyway. Better to have longer names than messed up logs.

Answer 4

The single most important thing to remember about logs is that they should not be written as if the developer is the audience. In almost every case, the logs will be read by administration or operations staff. In many cases, they'll be read by another program.

Therefore, I always recommend distinguishing logs by the immediacy of response needed. Andrey's log level names might have been a bit tongue-in-cheek, but the concept is right on the money. Log levels should reflect the following:

• (Highest) System Broken - immediate intervention needed
• Possible breakage, or developing issue - investigation needed, with possible intervention
• Status/informational reporting - routine heartbeat or summary stats

This last one serves two purposes, one overt and one subtle. The overt purpose is to log some useful info about the health and performance of the app. Second, a regular output into the log lets an operator know that the app is still functioning normally. (I.e., if I see a log file with no new entries in the last 3 hours, I'm likely to assume it's already dead.)