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

Remove resource from individual spans #1180

Closed
aabmass opened this issue Sep 30, 2020 · 8 comments
Closed

Remove resource from individual spans #1180

aabmass opened this issue Sep 30, 2020 · 8 comments
Labels
backlog bug Something isn't working sdk Affects the SDK package. tracing

Comments

@aabmass
Copy link
Member

aabmass commented Sep 30, 2020

Steps to reproduce
You can currently set a resource directly on a span:

resource: Resource = Resource.create({}),

My understanding was it should only be in the Tracer/Meter providers since resource is generally a constant throughout the program based on the environment.

What is the expected behavior?
I believe resource should only be attached to the providers.

What is the actual behavior?
Can set it on spans

Additional context
OTLP only has Resource once for all the spans sent in a request: https://github.com/open-telemetry/opentelemetry-proto/blob/30d237e1ff3ab7aa50e0922b5bebdd93505090af/opentelemetry/proto/trace/v1/trace.proto#L28-L31

I couldn't find resource attribute for spans in the tracing spec either.

@lzchen
Copy link
Contributor

lzchen commented Sep 30, 2020

Continued from this comment

@lzchen
Copy link
Contributor

lzchen commented Sep 30, 2020

@aabmass
Copy link
Member Author

aabmass commented Sep 30, 2020

Is there a use case for dynamically setting the Resource though? How would we even do this? Modify TracerPovider 's resources, create span, and then remove resource from TracerProvider? Seems kind of unecessary.

What are the boto/botocore instrumentations doing it for (could they just use labels)?

Doing this IMO violates the idea of a "a Resource is an immutable representation of the entity producing telemetry". The other issue is OTLP has no span-level resource, besides maybe merging into span attributes.

The OTLP exporter right now groups the spans by span Resource into separate ResourceSpans protos, but I don't think this is right, that would represent multiple instrumentation libraries. It also is not sending the Resource attached to the TracerProvider

@aabmass
Copy link
Member Author

aabmass commented Oct 1, 2020

@aabmass
Copy link
Member Author

aabmass commented Oct 1, 2020

On second look I don't believe the JS SDK has this. It is just passing a reference to the provider's resource in the constructor here and it is not settable by the user.

Same goes for Go after a quick look; there is no way to set resource (https://github.com/open-telemetry/opentelemetry-go/blob/master/sdk/trace/span.go). Also not seeing it in Java.

srikanthccv pushed a commit to srikanthccv/opentelemetry-python that referenced this issue Nov 1, 2020
@srikanthccv
Copy link
Member

srikanthccv commented Jan 5, 2021

Jaeger has some inconsistent model definitions about this. Thrift span def doesn't have process field and Batch makes it mandatory. Proto span def has process as mandatory span field and in case of Batch it is nullable.

So, for Jaeger to work with protobuf span should have resource attribute for every span or at least pb2_span should be populated with some resource data.

My understanding was it should only be in the Tracer/Meter providers since resource is generally a constant throughout the program based on the environment.

This makes lot of sense and trace specification doesn't have anything related to resource.

@github-actions
Copy link

github-actions bot commented Apr 9, 2021

This issue was marked stale due to lack of activity. It will be closed in 30 days.

@lzchen
Copy link
Contributor

lzchen commented Apr 19, 2021

Following this issue, we need the resource to be on the individual spans to populate service_name instead of getting them from the global tracer_provider. Closing this.

@lzchen lzchen closed this as completed Apr 19, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backlog bug Something isn't working sdk Affects the SDK package. tracing
Projects
None yet
Development

No branches or pull requests

3 participants