Question

In a large application logging is essential, but when many developers work on the code, the logs can become chaotic. One might write:

log.info("Loaded " + rowCount + " recodrs from the database.");

Another might do something like:

log.debug("Records read={}", rowCount);

A third developer might think this is the proper way:

log.trace("Record(s) read: " + NumberFormat.getInstance().format(rowCount)
          + ", values: " + values);

This will result in logs that are hard to read, and much harder to parse.

What guidance can you give developers to produce logs that have a chance to be consistent, and actually be usable by other people? Will a policy about logging do any good? And if so, what should it include? Should there be an API (above the logging framework’s own) to enforce this policy?

I’m also curious about how to make the code look alike, but the more important question is about the actual output.

Answer 1

IMHO logging guidelines on what constitutes a good log statement level are rare even among large frameworks and products, primarily due more important guidelines involving

• Log verbosity – more verbose statements should appear as debug statements, and calls to log.debug() should be wrapped by with a call to check whether debug is enabled. Developers often need to get the distinction between FATAL, ERROR, INFO, DEBUG and TRACE correct – not all exceptions are fatal, and not all messages are informative.
• Use of TRACE or equivalent – this should be reserved for execution flow. Ideally, no other log statements are required to indicate control flow.
• DEBUG vs INFO – DEBUG statements are often meant for developers and support personnel; INFO is often for users and administrators.
• override toString() – it is helpful for logging the state of complex objects

That said, I follow a few general thumb rules at the lowest level:

• Log data as is, without formatting. That way, in case of an error, I know what was the data that caused the problem, instead of doubting the logger, the formatter and the application at the same time.
• Avoid creating too many String objects unless you are running with DEBUG or TRACE switched on. In short, avoid concatenating too many strings. Even if log4j eventually checks if DEBUG is enabled or not, the String objects have been created, and that’s why log call wrapping is important. slf4j helps avoids this via the use of parameterized messages.