-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
logging: prioritize GOOGLE_CLOUD_PROJECT env variable over project id from metadata server for GKE resource detection #10326
Comments
…ect id from metadata server for GKE resource detection related issue googleapis#10326
…ect id from metadata server for GKE resource detection (googleapis#10326)
…ect id from metadata server for GKE resource detection (googleapis#10326)
…ect id from metadata server for GKE resource detection (googleapis#10326)
…ect id from metadata server for GKE resource detection (googleapis#10326)
…ect id from metadata server for GKE resource detection (googleapis#10326)
@GoosvandenBekerom Is the Java library that you mention the Java Cloud Logging client library or some other proprietary library that interfaces with Cloud Logging? |
From what I understood from our jvm team, it uses this method from the java google cloud client https://googleapis.dev/java/google-cloud-clients/0.98.0-alpha/com/google/cloud/ServiceOptions.html#getDefaultProjectId-- They use For now our logging team is solving this for our Go apps by overwriting the detected project ID with the project ID in the logName. But that isn't ideal of course. |
Is this overwriting something that is happening to the |
Yes that is the problem, the monitored resource can either be detected (default) or fully overwritten using this option For us it seems to work fine on other compute (cloud run) but for that centralized GKE setup it doesn't work as required, I figured this can easily be solved by simply checking the I figured by first checking that variable our issue would be solved, and it would not harm users that do not have that variable set. |
@GoosvandenBekerom This seems like a very one-off ask, so I wouldn't add any option for this. I don't think this is a change we are willing to make in the client library itself. As a workaround, you can overwrite the |
Is your feature request related to a problem? Please describe.
In our company, we have a central project in which GKE is managed, but then every application has its own project which gets it's own namespace in that central GKE setup. Now we are trying to integrate with the central logging architecture provided by our central TPS team.
Everything works, but there is a slight problem for us in the autodetection of the MonitoredResource. It detects the central project instead of the project that owns the workload. Because this central team wants to forward logging bills to the projects that are actually doing the request, they enforce us to provide the project id in the resource.project_id field.
I've tried a couple things, without success:
logging.DetectProjectID
setupDescribe the solution you'd like
The Java library used by other teams in our company seems to first check for the "GOOGLE_CLOUD_PROJECT" environment variable before going to the metadata server. If we also do this here (at least for the GKE detection) this would solve our issue.
Describe alternatives you've considered
I want a way to override the detected
resource.project_id
field for log entries.We could implement a new LoggerOption like
logging.OverrideResourceProjectId(projectID string)
. which would then set the "project_id" label onl.commonResource
to the given projectID.The only other alternative I see for us is to write our own auto-detection setup, which I really dislike, as this feels like something that will change often.
Additional context
I would be happy to implement this feature if maintainers agree that it would fit.
The text was updated successfully, but these errors were encountered: