Define how integrations should obtain a tracer

[mauriciovasquezbernal]

An instrumented library needs to access a tracer to create spans. Right now we have different ways of providing such tracer to the integration:

1. Pass the Tracer when enabling the instrumentation (pymongo, mysql, dbapi and other DB integrations probably)

opentelemetry-python/ext/opentelemetry-ext-pymongo/src/opentelemetry/ext/pymongo/__init__.py

Line 52 in b62c233

def trace_integration(tracer=None):

2. Pass a TracerProvider (requests)
   

   opentelemetry-python/ext/opentelemetry-ext-http-requests/src/opentelemetry/ext/http_requests/__init__.py

   Line 60 in b62c233

   def enable(tracer_provider):

3. Don't pass anything, the integration will get a tracer using opentelemetry.trace.get_tracer() (Flask and WSGI)

opentelemetry-python/ext/opentelemetry-ext-flask/src/opentelemetry/ext/flask/__init__.py

Line 114 in b62c233

tracer = trace.get_tracer(__name__, __version__)

I think the right approach would be to let it pass an optional TracerProvider, if that's not passed the integration should use trace.get_tracer_provider(). This approach provides flexibility, it allows customization and also has a default working version.

A possible downside of this approach is that the user will have to configure the SDK first, anyway this limitation is already present in all the integrations but Flask / WSGI that are creating a new Tracer for each operation, that in my opinion is not efficient and should be improved.

[codeboten]

The idea of an optional TracerProvider makes sense to me, this lets the instrumentation instantiate a tracer with the name/version information.

[toumorokoshi]

That seems like a good middle ground. Although personally I hope no one has a need to route different trace providers to different integrations, it might be good to allow that flexibility.

A possible downside of this approach is that the user will have to configure the SDK first

I think that's fine. As long as all of our examples illustrate that SDK configuration must happen first, and we have clear errors, I don't imagine this being a problem.

Then again there's a weird middle case where some integrations will work fine since they're instantiating tracers not during the initial instrumentation, but later e.g. after the event loop starts. But either way the standard of expecting SDKs to be configured first sounds very reasonble.

[Oberon00]

I also think this suggestion is sensible. In any case, providing the Tracer from the outside is bad because the tracer is supposed to have the name and version of the instrumentation, and the instrumentation should best provide this information to the TracerProvider itself.