Skip to content
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

SDK should populate telemetry.sdk.* resource attributes #1076

Closed
codeboten opened this issue Aug 21, 2020 · 3 comments · Fixed by #1235
Closed

SDK should populate telemetry.sdk.* resource attributes #1076

codeboten opened this issue Aug 21, 2020 · 3 comments · Fixed by #1235
Labels
enhancement New feature or request
Milestone

Comments

@codeboten
Copy link
Contributor

As per the spec, the SDK must set the opentelemetry.sdk.name to opentelemetry. It would be nice if the other telemetry.sdk.* values were also set.

@MrAlias
Copy link
Contributor

MrAlias commented Sep 10, 2020

My first thought is this can be setup as a resource detector that sets up all the relevant attributes. Is this in line with what you are envisioning @codeboten

@MrAlias MrAlias added this to the RC1 milestone Sep 10, 2020
@codeboten
Copy link
Contributor Author

@MrAlias I don't have a clear picture of how resource detectors are used in the Go implementation. In the Python implementation we decided to add those attributes to the Resource itself instead of a resource detector, you can see the discussion that lead us there here: open-telemetry/opentelemetry-python#932 (comment)

The implementation was done in this PR: open-telemetry/opentelemetry-python#1053

@MrAlias
Copy link
Contributor

MrAlias commented Sep 10, 2020

The implementation was done in this PR: open-telemetry/opentelemetry-python#1053

Gotcha. This was the implementation that I was not sure is desired from a user perspective. It makes sense to make it easy to annotate telemetry by including this information in the Resource, but I expect having this showup without users configuring it might be bothersome to certain users. Especially users that prioritize optimization by reducing included information to an absolute minimum.

Having this provided by a detector would give the user the choice to include this or not. I'll add this to the SIG meeting agenda for later today to see if I can get more input on this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
3 participants