-
Notifications
You must be signed in to change notification settings - Fork 77
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
[Feature Request] Log Forwarding Support for python-SDK #311
Comments
This can be disabled by setting
The only real reason is you're the first to need it :-) This is something we can add I think. I will leave this issue open on the backlog and we will look into implementing it. |
Didn't seem to work, I think the rust core uses And from this thread appears the config requires the filter to have |
I see! I opened temporalio/sdk-core#529 to let that be disabled at runtime. |
Somewhat related to this topic, it would be nice to have more control on the structure of the Rust logging. One scenario is using structured (JSON) logging on the Python side, which currently gets mixed with the Rust log lines (as @samuelmakarovskiy shared on the description). Structured logging is desired in certain scenarios, like Kubernetes deployments where the infrastructure takes containers stdout/stderr and forwards that to some logging infrastructure. Edit: @cretz clarified on Slack that "log forwarding" in this context means forwarding to the Python side, which would effectively solve the problem |
After further discussion, we are going to wait on temporalio/sdk-core#618 and have buffered, pushed logs be sent to Python logging. |
Is your feature request related to a problem? Please describe.
Have noticed an interesting behavior that arose when all instances of a temporal server are brought down after a python worker has connected. The worker infinite retries polling to reconnect which is fine, but the real issue is that the console logs for the underlying rust core are not formatted like the python worker logic ones. See below:
Fixing this would allow me to also guarantee any core issues can be detected by monitoring unified logs and not just stdout
Describe the solution you'd like
Couple of things would work
Additional context
The text was updated successfully, but these errors were encountered: