What's best practices to maintain logger names in backend configuration files like logback.xml?
Hi all, I'm using Logback mostly, but things are the same for other logging backends in the end. My current approach is to maintain `logback.xml` per deployment of some software project, which might be some daemon, web app or whatever. If it has an individual deployment and is known to use logging at all, it gets an individual config file. But should that file contain all logger names known and used by some application? I did so in the past to clearly document which loggers are available at all. Many of those are related to concrete classes and don't need to be configured individually in theory, but the most likely available root logger is enough already. OTOH, there are use cases for very specific loggers which additionally exist per class. Sometimes e.g. I have very special status loggers with very custom logging format which need to write some data to some special fail or send some mail or else. Because those are so special and need to be configured specially, they need to be part of the config file always. The downside of adding all loggers to those files clearly is maintenance overhead: The same logger might be available in multiple files, so renames need to be applied everywhere. Newly added loggers need to be added to all files, but one can't easily know if some class of some package is used in some app only only because some package/project is used in that app. The benefit of this approach clearly is that at best every admin always simply knows which loggers are available by looking into the config and can configure log levels for individual loggers of interest only. Otherwise one would need to start logging and blacklist things clearly not of interest. Does anyone else do this or is it not worth the effort? Thanks! Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: Thorsten.Schoening@AM-SoFT.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...........05151- 9468- 55 Fax...............05151- 9468- 88 Mobil..............0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
I tend to keep it simple and have a fairly generic config file and I include it in the jar file of the app. In the file I’ll have only overrides where needed. If I want to change logging at runtime then i will set a system property on the command line to override a log level. I’ve never needed much more than that. Have a look about how to read system properties inside logback.xml Dave On Fri, Apr 3, 2020, at 09:22, Thorsten Schöning wrote:
Hi all,
I'm using Logback mostly, but things are the same for other logging backends in the end. My current approach is to maintain `logback.xml` per deployment of some software project, which might be some daemon, web app or whatever. If it has an individual deployment and is known to use logging at all, it gets an individual config file.
But should that file contain all logger names known and used by some application?
I did so in the past to clearly document which loggers are available at all. Many of those are related to concrete classes and don't need to be configured individually in theory, but the most likely available root logger is enough already. OTOH, there are use cases for very specific loggers which additionally exist per class. Sometimes e.g. I have very special status loggers with very custom logging format which need to write some data to some special fail or send some mail or else. Because those are so special and need to be configured specially, they need to be part of the config file always.
The downside of adding all loggers to those files clearly is maintenance overhead: The same logger might be available in multiple files, so renames need to be applied everywhere. Newly added loggers need to be added to all files, but one can't easily know if some class of some package is used in some app only only because some package/project is used in that app.
The benefit of this approach clearly is that at best every admin always simply knows which loggers are available by looking into the config and can configure log levels for individual loggers of interest only. Otherwise one would need to start logging and blacklist things clearly not of interest.
Does anyone else do this or is it not worth the effort?
Thanks!
Mit freundlichen Grüßen,
Thorsten Schöning
-- Thorsten Schöning E-Mail: Thorsten.Schoening@AM-SoFT.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/
Telefon...........05151- 9468- 55 Fax...............05151- 9468- 88 Mobil..............0178-8 9468- 04
AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
_______________________________________________ logback-user mailing list logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
participants (2)
-
David Roussel -
Thorsten Schöning