The Logging Olympics: A Race Between Today’s Top 5 Logging Frameworks

This should be tagged "Java". I have no desire to touch Java even with a ten foot pole.

We develop web applications and are happy users of sentry: https://getsentry.com/

Their table is really painful to read. Here is a quick chart of the data.

https://docs.google.com/spreadsheet/oimg?key=0AgScytvGrtowdG...

I don't think it makes sense to choose your logging framework based on performance. Logging does IO, so it's relatively slow compared to everything else you do -- but operationally it's invaluable. I'd take the performance overhead any day.

If you have to ask how much logging costs, you probably can't afford it.

I work with logmanagemant solutions for multiple application systems. The primary issue I see with logging is that no formal standard for events has ever been agreed upon. This effectively results in a million different event formats (whatever the developers think up) and make aggregated and correlated data evaluation quite hard.

The only options that I came across is a proprietary specification called CEF (common event format) and a dead project called CEE (common event expression) which IMO was over-engineered.

From a BI view the current logging formats could as well be /dev/random and this makes logging of somewhat limited use.

It's useful though when an admin reads individual log messages trying to debug an issue.

This doesnt discuss things like, which backend did they use for slf4j. Also, concurrency should have a huge affect, as log4j has some locks in it, and iirc log4j2's main claim over logback is in speed in concurrent environments.

Really, you should always use slf4j, because all your libraries will be a mix of log4j, JUL, commons logging, etc, and slf4j will give you control over them all. It also comes with features some(log4j) of these dont have natively, like passing objects in args to do printf style replacement only when the log will be printed, instead of concatenation that always happens. Then use whatever backend you prefer, probably logback.

This is missing the most important element IMO. How long to check whether a log level or logger is enabled?

I don't care about the log statements that fire, those are always going to be too slow. I care about the overhead of all the log statements that don't fire that run for every single packet and transaction.

According to Mission Control/Flight recorder checking trace level logging statements was single digit percentages for me.

I am not going to lie, when i started reading the headline I was hoping for some interesting story about the timber/logging industry...

Interesting, but I don't base my Java logger strictly on performance. I prefer Logback for two simple reasons 1) single line log statements and 2) they show the thread name the log statement was generated in. This is by default, perhaps the other frameworks can do the same if configured properly but I haven't felt the need to find out.

This olympic event should be cancelled. The whole methodology is flawed and assumes way too many things.

For us, logback+gelf was the right solution. Get the logs off the box and keep them intact. https://github.com/mp911de/logstash-gelf

Notice how no one is using the built in Java Logger.

(Separate: No one is using the javax JSON either).