-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Add Logging Handler #1881
Add Logging Handler #1881
Conversation
de6d47e
to
0bbf805
Compare
|
||
Python Logging Integration: | ||
|
||
It's possible to tie the Python `logging` module directly into Google Cloud Logging. To use it, create a :class:`CloudLoggingAPIHandler <gcloud.logging.CloudLoggingAPIHandler` instance from your Logging client. |
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
@@ -0,0 +1,7 @@ | |||
Logger | |||
====== |
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
One concern I thought of is thread-safety. Logging is ostensibly thread-safe, but I know for sure our client is not. |
""" | ||
|
||
def __init__(self, client): | ||
logging.StreamHandler.__init__(self) |
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
For thread safety, I think it's fine because the Python handler base class acquires/releases locks around the emit call. @tseaver do you think this needs a system test added? |
@waprin a system test would be a good idea. Figuring how how to tear down the handler, as plugged into the stdlib |
Yeah I think that's unfortunately not quite right on the unit tests either. I try to undo it but I see log statements in the tox output I usually don't see. I'll look into fixing it and adding a system test. |
ebba62b
to
578cd38
Compare
@tseaver Ok I added system tests and I think logging handlers cleanup is now right in both unit and system tests. I also added a note to CONTRIBUTING that you need to change service account to Owner for logging. This is required to edit Sinks, not thrilled about it but I'm told it works as intended. The system tests for logging are all waiting for 2 seconds, they were usually failing for me so I bumped it to 5. Unfortunately logging API is especially eventually-consistent so any of these system tests are always going to be at least a little flaky. Given there's a bunch more I want to add to improve this handler, as well as more work in this library for Error Reporting, do you think we can start merging all this work into some sort of development branch? I wrote up an internal doc on the game plan, I can share it with you if you like (tseaver at company?). I think the work I have in mind belongs in this repo, but we can discuss, maybe not or maybe you want it as optional dependency or organized into contrib packages. /cc @filipjs /cc @steren (no work on error reporting yet, if you'd prefer I can only cc you on PRs relevant to that) |
@waprin I just set up a |
Superseded by #1920. |
First stab at addressing #1497.
Starting this with a baby step while we flesh out what we want. So it doesn't worry about fluentd integration, doesn't worry about async transports, doesn't worry about error reporting integration. Just a minimal handler that connects Python logging to Cloud Logging.