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

Conflicting information on Resource / Instrumentation Library #614

Closed
mwear opened this issue May 19, 2020 · 5 comments · Fixed by #616
Closed

Conflicting information on Resource / Instrumentation Library #614

mwear opened this issue May 19, 2020 · 5 comments · Fixed by #616
Milestone

Comments

@mwear
Copy link
Member

mwear commented May 19, 2020

Conflicting information on Resource / Instrumentation Library

The SDK Resource Spec states:

When used with distributed tracing, a resource can be associated with the TracerProvider when it is created. That association cannot be changed later. When associated with a TracerProvider, all Spans produced by any Tracer from the provider MUST be associated with this Resource.

My interpretation is that the Resource assigned to the TracerProvider, will remain static for the lifetime of the application. Tracers returned by the provider will also reference this Resource as will Spans created by the Tracers.

My confusion comes from the SDK Trace spec which states:

New Tracer instances are always created through a TracerProvider (see API). The name and version arguments supplied to the TracerProvider must be used to create a Resource instance which is stored on the created Tracer.

OTEP-83 added the Instrumentation Library concept, and I thought that the name and version described above belong to the Instrumentation Library, not as another Resource.

Should the SDK trace spec be updated to say:

New Tracer instances are always created through a TracerProvider (see API). The name and version arguments supplied to the TracerProvider must be used to create an InstrumentationLibrary instance which is stored on the created Tracer.

or do we need to represent this information both as a Resource and an Instrumentation Resource?

@jkwatson
Copy link
Contributor

I think the SDK trace spec is just out of date and should be rewritten as you suggest.

@bogdandrutu
Copy link
Member

I think your suggestion is correct @mwear

@arminru
Copy link
Member

arminru commented May 20, 2020

For the current state, updating the outdated SDK trace spec with your suggestion would be correct.

If I got the discussion on open-telemetry/opentelemetry-proto#150 right, however, there is a motion to revert OTEP-83 by removing InstrumentationLibrary. It would be replaced by representing the tracer and meter name+version using span attributes and metric names or labels. In that case, this passage would have to be revised again.

@bogdandrutu
Copy link
Member

@arminru I would focus to fix the current state for the moment.

@arminru
Copy link
Member

arminru commented May 20, 2020

@arminru I would focus to fix the current state for the moment.

@bogdandrutu Of course. Just wanted to mention it so it's less likely to be overlooked.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
5 participants