Exposing tracer property on spans

[SergeyKanzhelev]

From open-telemetry/opentelemetry-js#5

Span has a private tracer property, NoRecordSpan doesn't. I'd prefer to make tracer always available on Span like in OpenTracing. Coming from OpenTracing, I found it challenging not having tracer available on spans, especially that first I assumed it is and started to use it, then my code broke one NoRecordSpan(s).

@hekike, @rochdev

[tylerbenson]

I also think it would be nice since configs are usually exposed via the tracer. Besides, I assume Span will need to have a reference to it anyway to report when finished.

[SergeyKanzhelev]

@tylerbenson in the original issue - the scenario was given to start a child span, not to distinguish configurations. How will you use tracer obtained from Span besides starting child spans?

[rochdev]

We use this with OpenTracing to access the scope manager and to start related spans. The ability to access the tracer configuration would also be a nice addition since right now with OpenTracing the only compliant way to do that would be to assign the configuration to every span context to expose it.

In general, I find that exposing the tracer would result in a cleaner API that replicating some of the available tracer methods on the span class.

[carlosalberto]

I remember that we wanted to do this in OT Java (although we did this for OT Python, for example), and I'm definitely in agreement with this change.

Wondering if there's a way to poke people for a counter example (if there's any at all ;) )

[SergeyKanzhelev]

This becoming even more important and valuable with the named tracers

[tedsuo]

@SergeyKanzhelev I agree. Given the design of span.end, it's extremely unlikely that a span implementation would not to have a tracer reference, so I doubt there is a downside to this.

[Oberon00]

In my opinion, with named tracers, there now actually is the slight downside to providing another way to access the tracer. E.g. some instrumentation libraries might use parent.getTracer().startSpan(parent) instead of the "proper" tracerFactory.getTracer("myname", "myversion").startSpan(parent). The the span will be misattributed to the instrumentation library that created the parent span.

[SergeyKanzhelev]

@Oberon00 it is a good point that some libraries may want to "hide" their Tracer. For instance, user may disable certain component telemetry and span will carry no-op Tracer. Which will not be clear to the caller.

Giving it's easy to obtain a tracer and tracer doesn't carry any instance-specific information I tend to close this issue.

We should reconsider when Tracer will have more methods than it has today.

[yurishkuro]

+1 for closing this issue without action. In OpenTracing we had Span.getTracer() method and there was a lot of confusion about it. Tracer (or factory) should only be an injected dependency, accessing it at runtime from a span is a sign of code smell.