Anfang der weitergeleiteten Nachricht: Von: Rainer Hoerbe <rainer at hoerbe.at> Betreff: Granular Logging control Datum: 14. Juli 2019 um 22:04:55 MESZ An: satosa-dev at lists.sunet.se Kopie: Ivan Kanakarakis <ivan.kanak at gmail.com> If would like to discuss a logging feature that I would like to see in Satosa. I proposed with PR 237 to add a log filter that would enhance satosa's logging capabilities. Ivan rejected it for the (in general good) reason that the proxy should log everything and log processing should be external. I agree in general, but there are bits where I still think that they would be useful in satosa. These are: 1. In production environments it is unlikely to push the full set of debug information to a logging service. However, it might be useful to get debug level data on certain selections. Usually that would be based in IP addresses, which should not be too complicated to implement. 2. In a dev environment one is easily inundated with debug data. Shibboleth has a nice feature providing logging levels for certain aspects, such as XML tooling, SAMl message de-/encoding. I find this capability quite useful, because in my dev environment I do not have an elaborate log processor. Attribute configuration in satosa could be helped by selected messages. If done properly, this change has following impact on all modules that instantiate a logger: 1. refactor the satosa_logger wrapper back to the native logger with similar signature 2. add a log filter after each get_logger() The logfilter (logging.Filter) is orthogonal to structured logging, or may even help to improve it. see: https://github.com/IdentityPython/SATOSA/pull/237 <https://github.com/IdentityPython/SATOSA/pull/237> Cheers, Rainer