Well, you are correct that if a bug creeps in then it effects everyone. That said, currently our apps do not dynamically reconfigure logging. They only pick up changes on restart. That said, something is restarting many times a day, so any bug like that gets caught pretty quickly. And since our configuration is almost the same in our dev, release candidate, and production environments buggy changes made to the configuration are almost always found in the dev lab.
The alternative of having each application have its own logging configuration is a disaster. Since all your logs are routed to Kibana via ELK having uniform settings is essential. Applications can still have their own overrides as we use a composite configuration, but most apps don’t. To be honest, this was a major aid with Log4Shell. We were able to add the nolookups property to our logging pattern and restart our apps as a temporary bandaid. So although having a bug in a central configuration can be an issue, not having a central configuration becomes death by a thousand tiny cuts. Ralph > On Apr 10, 2022, at 8:14 PM, Dominik Psenner <dpsen...@gmail.com> wrote: > > Ralph, I do not believe that there exists a "one size fits it all" > solution. Yes, running in debug log has drawbacks and should not be > necessary. And yet I learned that only debug logs may provide enough > insights. The cause for this is simple: developers test code at "debug" > level and when time is short, may not add enough log statements on info. > > My intention was to push the horizon and I wanted to share this idea only > because I read "hundreds of applications are configured from a single > configuration file that should be modified only by qualified personnel". To > me this single configuration file sounds like a single point of failure > where even only a small typo can have devastative effect. Looking for a > solution that goes beyond the logging configuration may be a good idea in > such a case. > --
