ext: Expect tracer provider instead of tracer in integrations#602
ext: Expect tracer provider instead of tracer in integrations#602toumorokoshi merged 14 commits intoopen-telemetry:masterfrom mauriciovasquezbernal:mauricio/integrations/use_tracer_provider
Conversation
A helper to create a return a configured TracerProvider with a the span processor and the memory exporter
Oberon00
left a comment
Oberon00
left a comment
There was a problem hiding this comment.
LGTM, I think this is more in line with the intention of "named tracers" than the original interfaces. 👍
| if tracer_provider is None: | ||
| tracer_provider = trace.get_tracer_provider() | ||
|
|
||
| tracer = tracer_provider.get_tracer(__name__, __version__) |
There was a problem hiding this comment.
Since this pattern will occur more often, would it make sense to add an utility function setup_tracer(tracer_provider: Optional[TracerProvider], name, version) to the API to encapsulate these three lines?
There was a problem hiding this comment.
I was thinking if it could make sense to add an optional TracerProvider parameter to get_tracer(). It'll be the same setup_tracer you're proposing.
codeboten
left a comment
codeboten
left a comment
There was a problem hiding this comment.
This is a good cleanup and gives us a pattern moving forward! Just a couple of non blocking questions.
| https://dev.mysql.com/doc/connector-python/en/ | ||
| """ | ||
|
|
||
| if tracer_provider is None: |
There was a problem hiding this comment.
any reason not to call the original db_integration with the tracer_provider as a parameter since it's doing the same check?
There was a problem hiding this comment.
The problem is that it'll create the tracer with the version and name from the db-api module. I had to split the logic from opentelemetry.ext.dbapi.trace_integration into two different functions, one receiving a tracer provider (to be used by the user), and other one receiving a tracer (to be used by other integrations).
|
@mauriciovasquezbernal do you want to update the API to support that get_tracer pattern? Otherwise we can merge this in and take that as an improvement later. |
…m:mauriciovasquezbernal/opentelemetry-python into mauricio/integrations/use_tracer_provider
|
@toumorokoshi I implemented the change, would you mind taking a look? |
|
|
||
| # pylint: disable=unused-argument | ||
| def wrap_connect( | ||
| def wrap_connect_( |
There was a problem hiding this comment.
maybe a slight style thing, but it's a little harder for me to spot a trailing underscore rather than a leading underscore.
…elemetry#602) Standardize the interface that trace providers are specified in integrations, as specified in open-telemetry#585. Adding a helper to create and return a configured TracerProvider with a the span processor and the memory exporter api: Add tracer provider parameter to trace.get_tracer(). This eliminates the need for a helper function and boilerplate code to retrieve the appropriate tracer from a passed tracer_provider.
4 participants
Fixes #585
@lzchen @hectorhdzg I would love to get your opinions on this as it mainly affects the DB integrations that you worked on.
The
requestsintegration is updated in #597, there are some fixes coming for Flask as well in #601, so I don't update them to avoid conflicts.