How to know when there's too much logging messages?

Question

I came across one very good library for parsing CUE files. But when I started to read its source code, I realized that it is almost unreadable:

public void setParent(final CueSheet parent) {
    FileData.logger.entering(FileData.class.getCanonicalName(), "setParent(CueSheet)", parent);
    this.parent = parent;
    FileData.logger.exiting(FileData.class.getCanonicalName(), "setParent(CueSheet)");
}

every method has logger.entering() and logger.exiting() messages. Isn't that too much?

There's another java library for parsing audio tags. It also had like 15 log messages for each file it read. It was annoying so I commented out every call to logger. And the library became twice as fast, because they used a lot of string concatenation for log messages.

So the question is: should I really log everything, even if it is not large enterprise application? Because these libraries obviously don't need any logging, except for error messages. And my experience shows that loggers are terrible tool for debugging. Why should I use it?

Answer 1

How to know when is too much logging? When you know that the logged information isn't important in the long term, such as for straightforward debug actions or bug correction, or for when the application doesn't deal with too much important information.

Sometimes you need to log almost everything. Is performance or full possibility of analysis the most important part of an application? It really depends.

I've worked in the past with some integration with a lot of different webservices, like 10 in a same app. We logged all xml requests and responses. Is this an overhead? In the long term, I don't think so because we worked with a lot of credit card operations and should have every process made with the server logged. How to know what happened when there was a bug?

You wouldn't believe what I've seen in some of the xml responses. I've even received a xml without closing tags, from a BIG airplane company. Were the "excessive logs" a bad practice? Say that to your clients when you have to prove that the error came from the other vendor.

Answer 2

This level of logging is canonically bad - in fact, I saw code exactly like this in the Daily WTF a few days ago.

But logging is in general a Very Good Thing.

Answer 3

Ideally, you use a logger that allows logging levels; log4j has fatal/error/warn/debug/info, for example. That way, if you set the level to "only show errors", you don't lose speed to the software building log messages you didn't need.

That said, it's only too much logging until you wind up needing something that would have been logged. It sounds like most of the logging that's slowing you down should be "trace" level, though; it's showing you what a profiler would have.

Answer 4

Most logging libraries incorporate a means to confirm that logging is enabled before processing an instruction:

For example:

public void foo(ComplicatedObject bar) {
    Logger.getInstance(Foo.class).trace("Entering foo(" + bar + ")");
}

Could be quite costly depending on the efficiency of the bar.toString() method. However, if you instead wrap that in a check for the logging level before doing the string concatenation:

static {
    Logger log = Logger.getInstance(Foo.class);

public void foo(ComplicatedObject bar) {
    if (log.isTraceEnabled()) {
        log.trace("Entering foo(" + bar + ")");
    }
}

Then the string concatenation only occurs if at least one appender for the class is set to Trace. Any complicated log message should do this to avoid unnecessary String creation.