

The Logging Olympics: A Race Between Today’s Top 5 Logging Frameworks - rubygnome
http://www.takipiblog.com/2013/12/18/the-logging-olympics-a-race-between-todays-top-5-logging-frameworks/

======
scardine
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/](https://getsentry.com/)

~~~
masklinn
> This should be tagged "Java".

And "useless micro-benchmark", which I'd hope is not the only factor going
into picking a logging tool or API.

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

[https://docs.google.com/spreadsheet/oimg?key=0AgScytvGrtowdG...](https://docs.google.com/spreadsheet/oimg?key=0AgScytvGrtowdGliajdHQjhPeHctVW5YN3RINEpubmc&oid=1&zx=d8oxcbnr6qyx)

------
rafekett
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.

~~~
techdragon
You say that but if it means you double your per server costs to handle the
overhead. Hard to justify. Logging should be efficient. It must be to scale
from Large to small.

~~~
rafekett
If logging doubles your per server costs then you're doing it wrong. The
amount of noise you'd have to be producing there would make logs useless
anyway.

I agree logging has to scale, but it doesn't look like there's any substantial
difference between anything benchmarked (it'd have to be at least an order of
magnitude for me to care).

------
skriticos2
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.

------
idunno246
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.

------
arielweisberg
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.

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

------
jwn
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.

------
dmourati
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](https://github.com/mp911de/logstash-gelf)

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

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

