Is there an almost consistent guide for log levels?

Question

I was influenced by the levels of magazines that I and my teams used in my last two companies. I will share with you here, but remember that this bit is subjective:

• Fatal - your application goes down.
• Error. This operation or flow is malfunctioning and burning. Allows the app to continue.
• Warning. The current operation may continue, but the engineer must investigate something.
• Information. Explain what your operation does.
• Debugging - An explanation of operations that can receive quite spam (internal loops, etc.).

Now my objective question is whether there is a consistent style defined in this regard. The answer may be negative. But if there is such a standard, can you provide a URL to it?

Also note that I don't care what threshold is really set up to write somewhere useful in a deployed / production environment. Rather, my question is limited to the recommendations that those of us who write the code should use.

I put a C # tag and a Java tag in my question. We might have different guidelines in these two camps, but there are probably only cultural reasons why we will be different, not conceptual reasons.

Answer 1

I’m not even sure that something “highly coordinated” can be answered objectively.

Log4j and Log4Net libraries of course, use the level definitions that you described. See this link .

Someone else might create a counter example library that uses a differently defined set of logging levels.

Answer 2

from SSCLI (.NET sources):

namespace System { ... [Serializable] internal enum LogLevel { Trace = 0, Status = 20, Warning= 40, Error = 50, Panic = 100, } ... } 

note the values ​​of [warnings]). I rely on this distribution option. anyway it's Microsoft)

Answer 3

There is no “very consistent” standard, style, or advice that I know of. But each of the basic logging subsystems for Java has a set of levels that correspond to the 5 that you have identified. Indeed, the levels are quite well aligned in practice, that you can "unify" the logging using the SLF4J façade. (I think you could say that this makes SLF4J layers the preferred style for Java.)

I would add a couple of caveats:

• The advice on what an engineer can and should do in response to a log event goes beyond the scope of the log event description.

• Categories are necessarily subjective, but using a language such as “malfunction and burning” will lead to misunderstanding.

• In practice, use may not conform to the defacto style; for example, some logging systems allow other (implicit) levels to be used, and developers can log events at the “wrong” level.

---

Note that slf4j 1.4 has added TRACE level support.

Answer 4

I think I would add levels from the Python logger:

DEBUG - detailed information, usually of interest only when diagnosing problems.

INFO - Confirmation that everything is working properly.

WARNING - an indication that something unexpected has happened, or indicating some problems in the near future (for example, "disk space is low"). The software is still working as expected.

ERROR. Due to a more serious problem, the software could not perform any function.

CRITICAL - A serious error indicating that the program itself may not work.

You can find them here: http://docs.python.org/howto/logging.html#logging-basic-tutorial