You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There was a discussion at the spec call about confusion over resources. The topic came up when discussing Library Resources.
The specification has the following to say about resources and spans:
When used with distributed tracing, a resource can be associated with the TracerProvider. When associated with a TracerProvider, all Spans produced by any Tracer from the provider will automatically be associated with this Resource.
Some SIGs have interpreted this to mean that a TracerProvider should create a resource that is associated with a given tracer and the spans it generates. The implication is that this would happen behind the scenes since resources are part of the SDK and not the API. The Resource that the Ruby SIG is creating is a Library Resource where the library.name and library.version attributes are the name and version of the instrumentation used for a named tracer.
There seems to be conflicting information about whether or not this is correct.
Some SIGs have interpreted this to mean that a TracerProvider should create a resource that is associated with a given tracer and the spans it generates.
In my opinion the spec is clear here that there should be one single resource per TracerProvider that should be shared by all tracers.
a resource can be associated with the TracerProvider. When associated with a TracerProvider, all Spans produced by any Tracer from the provider will automatically be associated with this Resource.
There was a discussion at the spec call about confusion over resources. The topic came up when discussing Library Resources.
The specification has the following to say about resources and spans:
Some SIGs have interpreted this to mean that a TracerProvider should create a resource that is associated with a given tracer and the spans it generates. The implication is that this would happen behind the scenes since resources are part of the SDK and not the API. The Resource that the Ruby SIG is creating is a Library Resource where the
library.name
andlibrary.version
attributes are the name and version of the instrumentation used for a named tracer.There seems to be conflicting information about whether or not this is correct.
There is a PR to add library information to the proto:
open-telemetry/opentelemetry-proto#94
However there is already a resource in the protos:
https://github.com/open-telemetry/opentelemetry-proto/blob/master/opentelemetry/proto/trace/v1/trace.proto#L27-L35
What should this resource be if not the library resource associated with the named tracer that is generating the spans?
EDIT: I think this resource is meant to be the process level resource.
The text was updated successfully, but these errors were encountered: