Support for customized Job Log Preparer? #6845
Replies: 4 comments
-
Beta Was this translation helpful? Give feedback.
-
|
I did also investigate pushing our traced_id to the job["tags"]. While this could work having the formatting of the logs consistent across web and sidekiq is preferred, which the above PR would allow. |
Beta Was this translation helpful? Give feedback.
-
|
Turn off the default logging, add the middleware I included in the issue above and add the start/done logging in that middleware too. It will include your added context. |
Beta Was this translation helpful? Give feedback.
-
|
Resolved by #6846 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
We are implementing a trace_id that is being prepended to all of our logs. This allows for us to better see all side effects from n incoming request including jobs that were spawned directly or indirectly by this request. My initial thought was to leverage current attributes and inject these into the sidekiq logs. However, it seems that the current attributes aren't available for the
start,done, andfaillog messages. Switching the order of operations here so that the current attributes are set before the logger is called feels like it could have some unexpected effects. Would there be interest in supporting a customJobLogger.preparerthat could be configured in the initializer? The preparer would receive the already compiled hash that includes "jid", "class", "bid", and "tags" and should return aHashthat is then used to setThread.current[:sidekiq_context].Beta Was this translation helpful? Give feedback.
All reactions