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

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 2

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.