Which log levels to use when?

By Adrian Smith5 Feb 2008600 words3 mins to read

I'm sure there are a lot of opinions in the world about which logger levels to use for which errors. Log levels in the sense of if a text destined for a logfile should be prefixed with "Info", "Warning", "Error" etc.

There is even great debate about which log levels there should be. E.g. should there be a "Debug" level or a "Trace" level? Or both? In which case what's the difference?

I tended to ignore those debates—for me a log statement was simply a log statement—but recently I was deploying an application, and various people had worked on it and used log levels inconsistently. Hardly a surprise as I'd never set any guidelines on how they should be used, due to aforestated ignoring. So I started to think about how I would have wanted the log levels to have been in the application I was at that moment deploying.

Firstly, what does a log level actually influence?

And how would those differences influence ones decision about which level to make a particular log? I came up with the following scheme for me:

Level When to use it
TRACE For things that should happen, but one doesn’t want to see live. (For example SQL statement logs, etc.)
INFO For things that should happen, but one does want to log live. (For example, “writing file to /x/y.pdf…”) It’s important to state IDs and paths in log files, for if something goes wrong, one needs to be able to work out exactly what the robot did with what rows and objects. And if the robot crashes, a log, written before an action is done, such as “Writing PDF file…” can help to identify what part of the process caused the error.
WARNING For things that shouldn’t happen, but where the user sees the correct result. For example files that should always exist, but if they don’t, they can be automatically recreated. If those happen live, one might want to look at them. But as long as the user sees the right thing, one can look at them in ones own time.
ERROR For things that shouldn’t happen, and where the user sees an incorrect result. Including “fatal” errors.

And in that case, one would monitor ERRORs (or maybe WARNINGs if one was otherwise bored), and would set the log level to TRACE on all test servers and INFO on all live servers.

This article was written by Adrian Smith on 5 Feb 2008

Follow me: Facebook | Twitter | Email

More on: Software Architecture | Coding | Operations & Servers