-
Notifications
You must be signed in to change notification settings - Fork 55
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
feat!: Infer default resource in logger #315
Conversation
Co-authored-by: release-please[bot] <55107282+release-please[bot]@users.noreply.github.com>
* added code to remove extra topics in snippet tests * fixed lint issue
Post-Processor: gcr.io/repo-automation-bots/owlbot-python:latest@sha256:58c7342b0bccf85028100adaa3d856cb4a871c22ca9c01960d996e66c40548ce
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks like a small improvement but this is actually huge!!!
Thanks Dan!
labels (Optional[dict]): Mapping of default labels for entries written | ||
via this logger. | ||
|
||
""" | ||
if not resource: | ||
# infer the correct monitored resource from the local environment | ||
resource = detect_resource(client.project) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
will this default to "global" in case the environment wasn't detected? (i.e. the code is running in dataflow job)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, global is the fallback for detect_resource
We recently added functionality to the library to detect the monitored resource type based on the environment the code is running in (#200, #207). Starting with v3.0.0, this detected data should be populated by default by default when sending new logs, rather than defaulting to
global
.This behaviour is already in place when using the logging handlers with the logging stdlib. Now calling the library methods directly will behave consistently
Fixes #239