What information to include at each log level? [duplicate]

This quest开发者_开发问答ion already has answers here: Closed 12 years ago.

Possible Duplicates:

Where/what level should logging code go?

Debug Levels

Is there a convention, a standard, or a widely used guide which will help with logging in Java? Specifically, what to include at each level (verbose, debug, ... etc.) rather than the actual mechanism of logging.

There are many guides out there of what to include at each log level, but none of them are specific; they're all vague, and this makes it hard to "follow orders".

Any tips would be appreciated.

---

It's subject to personal interpretation, but mine is (in order from finest to coursest):

• Trace - The finest logging level. Can be used to log very specific information that is only relevant in a true debugging scenario, e.g., log every database access or every HTTP call etc.
• Debug - Information to primary help you to debug your program. E.g., log every time a batching routine empties its batch or a new file is created on disk etc.
• Info - General application flow, such as "Starting app", "connecting to db", "registering ...". In short, information which should help any observer understand what the application is doing in general.
• Warn - Warns of errors that can be recovered. Such as failing to parse a date or using an unsafe routine. Note though that we should still try to obey the fail fast principle and not hide e.g., configuration errors using warning message, even though we a default value might be provided by the application.
• Error - Denotes an often unrecoverable error. Such as failing to open a database connection.
• Fatal/Critical Used to log an error the application cannot recover from, which might lead to an immediate program termination.

In the end it's up to you to define what suits you best. Personally, I run most production system with logging level of Info, where I'm mostly interested in following the applications main logic, and of course catch all warnings/errors.

Except for code cluttering, there is no such thing as too much logging. All logging which helps you reproduce or understand problems better are good logging. On a performance note, most logging systems (e.g., log4j) allows configuring which level to actually append to the physical log which is a great thing.

---

For what it's worth, we're using the following log levels:

• DEBUG level messages give highly-detailed and/or specific information, only useful for tracking down problems.
• INFORMATION messages give general information about what the system is doing. (e.g. processing file X)
• WARNING messages warn the user about things which are not ideal, but should not affect the system. (e.g. configuration X missed out, using default value)
• ERROR messages inform the user that something has gone wrong, but the system should be able to cope. (e.g. connection lost, but will try again)
• CRITICAL messages inform the user when an un-recoverable error occurs. (i.e. I am about to abort the current task or crash)

I think the most important thing with log levels is to figure out a scheme, document it, and stick with it. Although making log level consistent between programs would be nice, as long as you've used common sense in defining your log levels, users will tolerate a certain amount of variance between programs.

---

Simple log what yuo think is important if you were to come back later and need to read the logs. This of course means that your Object.toStrings now need to be nice and readable and not a dump of crap thats impossible to read. This also means you need to do sensible things like quoting strings etc..