It's a logging library. You don't reconfigure logging, you just make another logger and use it. And by the way, you take the configurations from your global configuration system, "dynamic configurable" is a feature of the configuration system, not of the logging.
> supports a wide range of output formats and destinations
Yeah, like network aware templates. (But the destinations are a feature, multiple destinations are one of the few things a logging library should support.)
Despite what people claim, the Java culture of loving complexity never did go away.
> It's a logging library. You don't reconfigure logging, you just make another logger and use it.
Prior company had a shared plugin that let you turn up the logging for a given logger remotely for 30 minutes (it self reset). Extremely helpful for incident debugging.
Now we can have an interesting discussion about whether that capability is worth the complexity, but that’s a very different discussion than unilaterally declaring that other people’s use cases just don’t exist.
> Despite what people claim, the Java culture of loving complexity never did go away.
Do you develop in Java? Because I do, and your takes don’t match my daily experience one bit. My experience going from Spring 3 to Spring Boot 2 is in fact one of reducing complexity (goodbye XML bean configuration!) and to more “it just works” situations than before.
Why is there any problem in restarting your logging system? There is nothing in a logging system that could be harmed by a restart. Restarting it is exactly how you should handle changes, because it deals with plenty of stuff that isn't reconfigurable on a lower level.
The only way to make a "reconfigurable" logging system is by having a stable facade that restarts everything behind it. But that extra layer does not belong on a logging system, there are plenty of other things you need to make "reconfigurable", and now you are adding an extra layer into each of them, instead of having only one on your main entry point.
Pushing that feature down into the logging system is the choice that maximizes complexity and minimizes functionality.
If you turn on debug logging to see why somewhere weird is happening, and the only way to do that is to completely restart the entire system - good luck figuring out why a large class of weird things happen!
You act as if “restarting” the logging system is easy and doesn’t require the same facade that you decry for a reconfigurable one. With dependency injection, there are loggers everywhere in the system, possibly in sections of the code you didn’t even rewrite. Restarting such a system while continuing to run everything else is just as complex as reconfiguring, possibly more complex.
Also, I noticed you didn’t answer my question about whether you’re a Java developer.
> I was once, but haven't used it professionally for a while.
This is why I ask. Java has changed a lot since ~1.8, and it is super common to see ex or non java developers making grandiose and sweeping statements about a community and language that they are no longer part of. Having developed in Java on and off since ~1.7 and Spring 3, I can certainly say that I have seen a strong movement towards less complexity and more convention. It's not perfect by any stretch, but I think saying that the space is "in love with complexity" is incorrect.
You of course don't have to go and re-use Java on my suggestion. We all have our preferences, and that's ok! But I would generally recommend against such sweeping and dismissive general statements about a culture that you are no longer part of. Things change, and your experience back then is probably not representative of things today.
> Oh, and now that you described it with so many details, the attachment to complexity does look more like addiction than love.
There's a fine line between disagreement and insult, and you are over it.
This turns gigabytes per hour of logs to hundreds of terabytes per hour during normal operation, in many cases it's an inferior solution for problems which pop up in a fraction of infrastructure several times a month.
Ok? One you need to disable debug logging and two I still don’t see a problem with that amount of data. You also don’t need to keep logs more than a month or so. How much log data do you think cloudwatch and the other majors filter per hour? much more than terabytes.
Log emission can often have a negative impact on performance, especially since peak logs and peak traffic tend to coincide. I’ve seen P95 latencies suffer just because of logs.
> How much log data do you think cloudwatch and the other majors filter per hour?
How much do you think the major providers pay for that infrastructure per hour, and are you willing to shoulder that cost too?
(Hint: log ingestion is $0.50 per gigabyte in cloudwatch. So a terabyte of logs an hour is $512/hr)
> Log emission can often have a negative impact on performance, especially since peak logs and peak traffic tend to coincide. I’ve seen P95 latencies suffer just because of logs.
Only if the emissions of said logs is doing more than stdout or fs writing and it’s not done in another thread.
> Log emission can often have a negative impact on performance, especially since peak logs and peak traffic tend to coincide. I’ve seen P95 latencies suffer just because of logs.
Yes and you need to fix that terabyte per hour garbage as that is well beyond typical for a single service. We’re also talking about java so 7000 page stack traces is where i’d start…
> It’s dynamically configurable
It's a logging library. You don't reconfigure logging, you just make another logger and use it. And by the way, you take the configurations from your global configuration system, "dynamic configurable" is a feature of the configuration system, not of the logging.
> supports a wide range of output formats and destinations
Yeah, like network aware templates. (But the destinations are a feature, multiple destinations are one of the few things a logging library should support.)
Despite what people claim, the Java culture of loving complexity never did go away.