With excellent documentation and support, neat logging features, blazing performance and an innovating eclipse plugin, I've finally found a good replacement for the good old log4j.
The first thing I really appreciate compared to log4j or the java logging api is the documentation. The guide is well written, they have a nice demo, and you are up to speed in a few minutes.
Neat logging features
There are some very simple features which makes the life so much easier, such as the intelligent logger name reduction when it's too long: instead of simply truncating the name, it put the first letter of each package:09:59:04.203 [main] INFO o.x.x.web.XoosentApplication - starting XooSent
The Mapped Diagnostic Context (MDC) is also a killing feature. It allows to associate metadata to the current thread, to correlate messages to their context. For instance in a web application with authentication, you can associate the user name to the the thread and add this user name to all log messages, without any change to your log calls. For instance, you add this at user authentication time:
MDC.put("user", username);
Then in your logback configuration you can use %Xuser in your pattern, and you will see the authenticated user name. It's that simple, and in multithreaded environment where multiple traces overlap, it really helps.
Updated: As Jorg pointed out, this isn't a feature introduced by logback, as log4j already supports NDC and MDC.
Performance
The parametrized logging is a key feature of logback, which improves performance by avoiding a toString() call when your message is not logged:
logger.debug("Hello, my name is {}, I am {} years old", username, age);
Note that obviously the performance gain applies only if you don't enclose your logging statements with if (logger.isDebugEnabled()) statements). But if you look at a benchmark run by Sebastien Pennec, one the developers of logback, it's really impressive:
Log4j direct debug call: 442 Log4j tested (isDebugEnabled) debug call: 19 Logback direct debug call: 435 Logback tested (isDebugEnabled) debug call: 10 Logback parametrized debug call: 15OK, we all know how we should consider benchmarks, especially when written by someone biased as Sebastien obviously is, but these numbers can't be completly wrong, and what's interesting is that a logback parametrized call takes approximately the same time as a log4j isDebugEnabled call. Really cool!
Still on the performance area, logback introduces TurboFilters, which allows to filter logging before the logging event is actually constructed, saving a lot of unnecessary time.
Beyond console and files
Beyond classical ways to track and configure your logs, you have very interesting features with logback, such as a JMX configuration, and a new Eclipse plugin which is really neat.One of the thing I like the most with this plugin is the option to go to the source which is at the origin of the log. Double click on the log, and it will open your source editor at the line where the log call is performed! Awesome! How many times did I use the search tool to find where a particular log call is performed in a big application, and waste time because the message was the result of a concatenation and thus my search failed...
Another interesting thing is the option to change the pattern and apply it to all the logs, including previous one.
And you have also a good filter option, where you can apply any logback filter expressions. This still need to be improved IMO to be able to apply the filter in real time to previous logs, but hey, it's only the first version of this plugin!
12 comments:
Nice and well-written summary!
Minor nitpick: NDC's and MDC's aren't exactly new features, as they existed in log4j already: http://logging.apache.org/log4j/docs/api/org/apache/log4j/MDC.html
Cheers
Jorg
Hello Xavier,
Thanks for your post, and your support!
I would just add something about the performance benchmarks: everybody should keep in mind that these are times in nanoseconds. This said, we should remember that seeing a difference of 5 nanos is not much and should not be considered as a significant difference.
As you wrote, logback's isDebugEnabled call and parametrized call are as fast as log4j's isDebugEnabled call. But one should not conclude from these number that logback's parametrized form is x% faster than log4j's isDebugEnabled form.
On the other hand, for the performance-critical code, logback's isDebugEnabled method is actually faster than log4j's isDebugEnabled, mainly because of the different way that effective levels are managed in both frameworks.
Thanks again for your post :)
Sébastien Pennec
Jorg: thanks for your comment, I've updated the post to reflect your nitpick.
Sebastien: thanks for the clarification about performance, and thanks again for your work :)
Xavier
Many thanks for your extremely favorable comments. It has made our day! Although not as active as Sebastien, Jean-Noel also works on logback. (As a matter of fact, he just committed new code a few minutes ago.)
I suspect that the modularity of logback will prove to be a major architectural advantage. Many of the things you can do with logback-classic are also possible with logback-access. I use it daily to capture SOAP messages sent to my web-server. Logback-accees makes it easier for me to get work done.
Anyway, we very much appreciate feedback, especially if it is this favorable.
Ceki, I've updated my kudos at the end of my post, Jean Noel is not forgotten anymore.
For logback modularity and the use of logback access, it indeed looks very promising.
My hope is that all major libraries move to slf4j so that we can really leverage logback as the backbone logging system, without any mapping...
Hi,
Have you checked out JXInsight Diagnostics which comes with a powerful management and analysis console that works across clusters of servers?
Diagnostics Related Blog Entries
http://blog.jinspired.com/?cat=19
Our JXInsight JVMInsight has many extensions for inspecting the state of systems, frameworks and components and we already support both Java logging and Log4j so it should also be possible to inspect remote state associated with components within the LogBack framework especially MDC instances.
JVMInsight Related Blog Entries
http://blog.jinspired.com/?cat=12
We recently made available a FREE development edition.
www.jinspired.com/products/jxinsight/downloads
kind regards,
William Louth
JXInsight Product Architect
JInspired
"Java EE tuning, testing, tracing and monitoring with JXInsight"
http://www.jinspired.com
Thanks for your links, william, and thanks for providing a free edition of your product.
I'll test it when I have some time, but may I suggest one thing: add screenshots to your product website (or make the link more obvious if you alerady have some), because it's difficult to figure out how it looks like.
My 2c.
Thanks for the feedback. I believe we will have a video demo up on the site in the next few days that make it easier to understand the products visualizations in the context of performance profiling and problem diagnostics. We only included some snippets of visualizations because there are many views within the product. But I do agree that it is sometimes important to see the forest (one big screen shot) from the trees (sections).
Thanks again.
William
"Note that obviously the performance gain applies only if you don't enclose your logging statements with if (logger.isDebugEnabled()) statements)"
what are you talking about? if i do this check, it helps in prevention of construction of the string in the first place;
Regards
Vyas, Anirudh
I mean that if you used to do this check for all your log statements in log4j, you won't see any performance improvement, because you already skipped the log message String building when the log level is disabled. If you don't use the check, then using logback has the advantage of defering the log message String building to the time logging is performed, thus avoiding it if log is disabled. Hence you can most of the time use the logging methods with logback without worrying of enclosing them within isXXXEnabled if statements, which makes the code much easier to read.
Nice post - made me try it out and I like what I see - esp the Eclipse plugin - killer feature! Not more need to location statements! (well, in dev anyway ;)
Post a Comment