-
-
Notifications
You must be signed in to change notification settings - Fork 218
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Traceback when using stdlib.filter_by_level
with Python Standard Logging Library
#542
Comments
Hmm Generally speaking the execution environment within ProcessorFormatter is very different than within structlog proper. |
Hi @hynek , thank you very much for the comment. Could we have an explanation which Example: COMMON_PRE_CHAIN: list[structlog.typing.Processor] = [
structlog.contextvars.merge_contextvars,
structlog.stdlib.filter_by_level, # <-- this "common" processor is causing issues in stdlib configuration
structlog.processors.TimeStamper(fmt='iso'),
structlog.stdlib.add_logger_name,
structlog.stdlib.add_log_level,
structlog.stdlib.PositionalArgumentsFormatter(),
structlog.processors.StackInfoRenderer(),
structlog.processors.UnicodeDecoder(),
]
LOGGING: dict[str, t.Any] = {
'version': 1,
'disable_existing_loggers': False,
'filters': {'event_blacklist': {'()': 'app.settings.components.DevelopmentFilter'}},
'formatters': {
'plain_console': {
'()': structlog.stdlib.ProcessorFormatter,
'processors': [structlog.stdlib.ProcessorFormatter.remove_processors_meta, structlog.dev.ConsoleRenderer()], # <-- what is the difference between processors here and `foreign_pre_chain` later on? One is used for `structlog` logs and another for `stdlib` logs? We are trying it to keep "the same"
'foreign_pre_chain': COMMON_PRE_CHAIN, # <-- the issue is caused here with the same example
},
},
}
structlog.configure(
processors=[*COMMON_PRE_CHAIN, structlog.stdlib.ProcessorFormatter.wrap_for_formatter],
logger_factory=structlog.stdlib.LoggerFactory(),
wrapper_class=structlog.stdlib.BoundLogger,
cache_logger_on_first_use=True,
) With the following configuration we have exactly the same traceback. In the documentation it is stated that you should keep your Could you please explain which processors we can't/shouldn't use in |
structlog.stdlib.ProcessorFormatter's structlog.stdlib.ProcessorFormatter's I cannot answer your question in general because it's complicated. OP's problem was that they used a processor that needed a stdlib logger to get the log level. I'm not even sure what your problem is. |
Just started using structlog recently; I've have found it's a great library to work with. Appreciate your all your hard work!
I'm using it both for internal logging library and for formatting the root python logging library's messages. Both are printing JSON to stdout. I get a traceback when I try to use
structlog.stdlib.filter_by_level
. Actually, I run into several similar tracebacks for several processors from thestructlog.stdlib
library. With these processors commented out, I am able to successfully encode JSON logs to the console from 3rd party libraries using the built in Python logger.However, I was hoping to utilize the additional processors listed in the documentation. I checked for similar issues in GH and the documentation on integrating with the stdlib python logger, but didn't find any solutions. I'm hoping to understand if there was any insight here on something I'm doing wrong - configuring the python standard library to use structlog or if I'm using the processors incorrectly? Otherwise, I think this might be a bug with structlog.
After some review of the stack trace, I think the issue may comes from
isEnabeldFor
not being available on whatever objectstructlog.stdlib.ProcessorFormatter
provides as it seems to only exist onstructlog.stdlib.BoundLogger
.I'm attempting to configure it like this for each logger instance respectively.
The text was updated successfully, but these errors were encountered: