Add tracer construction spec

[pavolloffay]

Resolves #39

Signed-off-by: Pavol Loffay ploffay@redhat.com

[yurishkuro]

I have a couple concerns here.

• Not sure how language-neutral the proposed pattern is. In Go people often have very strong feelings against registration pattern.
• I think there have been many asks in OpenTracing where people use multiple tracers per process, so using words like "MUST use opentelemetry.GetTracer()" sounds too rigid

[songy23]

I think tracer should be part of tracing-api.md?

[carlosalberto]

Hey @pavolloffay thanks for cooking this PR.

As Yuri said, I think stating "MUST" for using OpenTelemetry.getTracer() is indeed strong - probably it's better to leave it as a recommendation only.

Also, automatic registration (i.e. what TracerProvider does) may not even be possible in all the languages (in Python, for example). Perhaps we can mention this as a possible route for languages to register OpenTelemetry.get*() members, or else fallback to manual registration.

[pavolloffay]

I think there have been many asks in OpenTracing where people use multiple tracers per process, so using words like "MUST use opentelemetry.GetTracer()" sounds too rigid

I think we should look at it from the other side. We should assure that the registry always returns a valid tracer so the instrumentations can bind to it.

[songy23]

LGTM

[iredelmeier]

+1 for @yurishkuro's concerns.

In particular, an assumption that OpenTelemetry.getTracer() returns a valid (i.e., non-null) tracer is quite different from assuming that it is the desired tracer. There are many reasons why users may want to avoid relying on a global tracer.

[SergeyKanzhelev]

@iredelmeier for libraries instrumentation there must be a way to obtain the Tracer without the need to accept it as an argument thru dependency injection. Thus OpenTelemetry.getTracer() must exists. Even if customer is not relying on it. Do you envision a future when every library takes OpenTelemetry object as an argument on construction?

As for non-null - an implementation of this registry may be very language specific. But I'd say the requirement for it to be non null is quite important to avoid undesired NullReferenceExceptions. It's not too hard to return an noop tracer.

[iredelmeier]

@iredelmeier for libraries instrumentation there must be a way to obtain the Tracer without the need to accept it as an argument thru dependency injection. Thus OpenTelemetry.getTracer() must exists. Even if customer is not relying on it. Do you envision a future when every library takes OpenTelemetry object as an argument on construction?

One in which every library requires providing a tracer? No. One in which libraries are at least advised to enable overriding the global? Yes.

As for non-null - an implementation of this registry may be very language specific. But I'd say the requirement for it to be non null is quite important to avoid undesired NullReferenceExceptions. It's not too hard to return an noop tracer.

My thoughts exactly! e.g., in OpenTracing there's the concept of a NoopTracer, which conforms to the same interface but (as the name implies) doesn't actually do anything. (I'd actually argue that OpenTelemetry should take this a step further with, e.g., a NoopSpan, but that's a separate conversation.)

[SergeyKanzhelev]

@iredelmeier I suggest we file a feedback item to expand this description for the languages that uses DI extensively and have a practice of constructing SDKs and providing OT object explicitly. In any case there must be some global object to get as minimum the default (noop) tracer.

So I suggest we merge this one and formulate it better later.

I'd need this update personally for C#, but not ready to generalize it properly as a spec

[SergeyKanzhelev]

Created: #143

[tedsuo]

LGTM