-
Notifications
You must be signed in to change notification settings - Fork 15
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
Support adding custom resource.Detectors / resource.Options #12
Comments
Hey @dstrelau - sorry for the delay in responding. I don't see a reason why we can't upgrade to semconv v1.17 to match the other deps. Please do submit a PR to fix 👍 Regarding the supporting additional Resource Detectors, I think your idea of extending the API to include something like |
Created this ticket to update semconv separatley: |
## Which problem is this PR solving? Bumps the semconv version to 1.18 to match other upstream packages. - Partially addresses #12 ## Short description of the changes - Bumps semconv version to 1.18 - Add gitignore to ignore smoke test artifacts ## How to verify that this has the expected result - Run smoke tests and tests - Replace launcher dependency in the go distro with this local change to make sure the distro works as expected
## Which problem is this PR solving? We are unable to add resource detectors when configuring the launcher. - Closes #12 ## Short description of the changes Rather than adding a specific `WithDetectors` func to mirror the functionality in the [resource package](https://pkg.go.dev/go.opentelemetry.io/otel/sdk/resource#WithDetectors) this adds a more generic version so that any resource option configuration can be provided. This has been done in a backwards compatible manner but I could see a future where the `WithResourceAttributes` function is removed as it is duplicate functionality now. ## How to verify that this has the expected result Unit tests have been added
## Which problem is this PR solving? We are unable to add resource detectors when configuring the launcher. - Closes #12 ## Short description of the changes Rather than adding a specific `WithDetectors` func to mirror the functionality in the [resource package](https://pkg.go.dev/go.opentelemetry.io/otel/sdk/resource#WithDetectors) this adds a more generic version so that any resource option configuration can be provided. This has been done in a backwards compatible manner but I could see a future where the `WithResourceAttributes` function is removed as it is duplicate functionality now. ## How to verify that this has the expected result Unit tests have been added
## Which problem is this PR solving? We are unable to add resource detectors when configuring the launcher. - Closes #12 ## Short description of the changes Implementation starts with what was written for #47 with smoke tests added to verify the order of precedence for resources attributes from environment over code. [vera] upon further inspection, the original behavior of CODE attributes winning over ENV attributes was valid: > The SDK MUST extract information from the OTEL_RESOURCE_ATTRIBUTES environment variable and [merge](https://opentelemetry.io/docs/specs/otel/resource/sdk/#merge) this, as the secondary resource, with any resource information provided by the user, i.e. the user provided resource information has higher priority. — [OTel Resource SDK spec](https://opentelemetry.io/docs/specs/otel/resource/sdk/#specifying-resource-information-via-an-environment-variable) “user provided resource information” -- the user could mean the application code writer OR the operator setting environment variables. It’s ambiguous! And *not* settled in the spec: open-telemetry/opentelemetry-specification#1620 See note in that issue: >others in the Go SIG have interpreted this passage to require that resource attributes from the environment must be subordinated to any resource attributes provided by the developer-user This is how the underlying Go SDK works, as designed. The CODE>ENV decision was also made in the Ruby SDK: https://github.com/robertlaurin/opentelemetry-ruby/blob/0c03e4aee09093ce0d80142e13a35326aad9f877/sdk/test/opentelemetry/sdk/configurator_test.rb#L35 Description from original PR: Rather than adding a specific `WithDetectors` func to mirror the functionality in the [resource package](https://pkg.go.dev/go.opentelemetry.io/otel/sdk/resource#WithDetectors) this adds a more generic version so that any resource option configuration can be provided. This has been done in a backwards compatible manner but I could see a future where the `WithResourceAttributes` function is removed as it is duplicate functionality now. ## How to verify that this has the expected result - [x] Unit tests - logic's probably sound - [x] Smoke tests - interaction with config from environment behaves according to spec --------- Co-authored-by: Martin Holman <me@martinholman.co.nz> Co-authored-by: Vera Reynolds <verareynolds@honeycomb.io>
I'd like to be able to add custom Detectors, like the ones in sdk/resource or the ones in contrib for cloud providers.
There are two problems here:
I think the fix is something like adding
func WithResourceOptions(...resource.Option) Option
and then passing those to theresource.New
call here (andsdk/resource.WithDetectors
returns aresource.Option
so that covers the contrib Detectors too). However, the error returned fromresource.New
is ignored right now and I know at least some of the AWS Detectors will return errors when not on an appropriate platform (eg, the EKS detector returns and error when not running on EKS). I'm not sure if it's worth threading that error all the way back up to the caller ofConfigureOpenTelemetry
or if there are other options I'm not seeing. I'd like some advice before attempting a fix.The
semconv
versions imported in this project (v1.10.0) and in those other libraries (v1.17.0) are different, meaning that thesemconv.SchemaURL
values are different, meaning that any attempt to merge them together will fail. Happy to submit a PR to upgrade this package's version if that sounds like a reasonable fix.The text was updated successfully, but these errors were encountered: