Is there a near-consensus guideline for log levels?

I've been influenced by the log levels that I and my teams have used at my last two companies. I'll share ours here but keep in mind this bit is subjective:

• Fatal - Your app is going down.
• Error - This operation or thread is crashing and burning. The app may be able to continue.
• Warn - The current operation may be able to continue but an engineer needs to investigate something.
• Info - Explain what your operation is doing.
• Debug - Explanation of operations that may get pretty spammy (inner loops, etc).

Now, my objective question is whether there is a highly-agreed upon style defined in this regard. The answer may be no. But if there is such a standard, can you point a URL to it?

Also note that I don't really care what threshold is actually configured to log somewhere useful in a deployed / production environment. Rather, my question is restricted to guidelin开发者_运维问答es that those of us who write code should use.

I'm putting a C# tag and Java tag on my question. It's possible we'd have different guidelines in these two camps but there are probably only cultural reasons that we'd differ, not conceptual reasons.

---

I'm not even sure that whether something is "highly-agreed" upon can be answered objectively.

The Log4j and Log4Net libraries certainly employ the level definitions that you've described. See this link.

Somebody might yet produce a counter-example of a library that uses a differently defined set of logging levels.

---

from SSCLI (.NET sources):

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

note the [warning] values) I rely on this variant of distribution. anyway it's Microsoft)

---

There's no "highly agreed upon" standard, style or advice that I'm aware of. But each of the mainstream logging subsystems for Java has a set of levels that correspond to the 5 that you have identified. Indeed, the levels are well enough aligned in practice that it is possible to "unify" logging using the SLF4J facade. (I guess that you could say that this makes the SLF4J levels a defacto preferred style for Java.)

I would add a couple of caveats:

• Advice about what an engineer can and should do in response to a log event is out of scope in describing what log events mean.

• The categories are necessarily subjective, but using language like "crash and burn" is going to lead to misunderstanding.

• In practice, usage may well not be consistent with the defacto style; e.g. some logging systems allow you to use other (non-manifest) levels, and developers may log events at the "wrong" level.

---

Note that slf4j 1.4 added support for a TRACE level.

---

Thought I'd add the levels from the Python logging facility:

DEBUG - Detailed information, typically of interest only when diagnosing problems.

INFO - Confirmation that things are working as expected.

WARNING - An indication that something unexpected happened, or indicative of some problem in the near future (e.g. ‘disk space low’). The software is still working as expected.

ERROR - Due to a more serious problem, the software has not been able to perform some function.

CRITICAL - A serious error, indicating that the program itself may be unable to continue running.

These can be found here: http://docs.python.org/howto/logging.html#logging-basic-tutorial