Sentry is great, but I currently need something that will log timeseries (i.e. more like an actual syslog, so I can see how debug messages progressed in time). I tried Logstash, but it was a bit hard to set up.
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.
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.
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).
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.
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.
We develop web applications and are happy users of sentry: https://getsentry.com/