Format args and kwargs and the extra parameter
See original GitHub issueHi, first of all thanks a lot for this nice piece of logging 😃
I have a question: is there a way to use the keys in extra to format the message ? Or to add the kwargs of the debug/info/etc. to the extra parameter ?
Let me explain more with code, today one has to do this:
logger.bind(duration=10).info("my long process duration was: {duration} seconds", duration=10)
to have both a nice message and a “real” value to work with for monitoring purpose.
What I’m trying to achieve is having a single logging library for all our internal applications that allow to: log normally, send exceptions to sentry, send “TRACE” levels to influxdb -> grafana and all “TRACK” levels to loki -> grafana. For instance:
logger.exception("Houston we have a problem") # this goes to sentry
logger.debug("we do something") # this stays on the server
logger.track("user {username} started a long process", username="Me") # this is sent to Grafana through loki so username should be sendible in json log (serialize=True)
# later
logger.trace("long process duration was {duration} seconds", duration=10) # this is sent to Grafana through influxdb, duration should be sendible in json log (serialize=True)
Is it clear enough ? Am I missing something ? It’s late here and maybe I missed something obvious. If this is the case, sorry !
Anyway thanks a lot for your awesome lib ! Cheers
Issue Analytics
- State:
- Created 3 years ago
- Comments:9 (5 by maintainers)
Top GitHub Comments
Indeed, it would be trivially possible to populate
extra["kwargs"]
with all arguments used to format the log message. However, I don’t want this to be the default behavior. I prefer it to be explicitly configured by the user, if he chooses to do so.The
logger
has been designed so thatlogger.info(msg, *args, **kwargs)
is a shorthand formsg.format(*args, **kwargs)
that just creates the logged message. Besides that, there isbind()
which can be used to dynamically update a dict (record["extra"]
) and provide additional context. They’re two different things I’d rather not mix.Also, if a solution had to be implemented to make the
logger
more convenient for your use case, I would love it to solve #2 at the same time. These are very related issues. This means we not only need a way to somehow addkwargs
to therecord
, but we also need a way to allow a custom function to modify the message usingkwargs
.I haven’t come up with a solution that I liked yet, but you’ve gave me another use case to think about. I’ve got some ideas.
The best I can offer you for now is to monkeypatch the logging methods (but in addition to being hacky, it breaks
opt()
):Whaaat !! You are a rockstar ! Thank you so much !