Update instrumentations to use tracer_provider for creating tracer if given, otherwise use global tracer provider #402
Conversation
… given, otherwise use global tracer provider
...tion/opentelemetry-instrumentation-flask/src/opentelemetry/instrumentation/flask/__init__.py
Outdated
Show resolved
Hide resolved
...tion/opentelemetry-instrumentation-flask/src/opentelemetry/instrumentation/flask/__init__.py
Outdated
Show resolved
Hide resolved
…hon-contrib into issue-401
srikanthccv
requested review from
owais and
aabmass
and removed request for
a team
.../opentelemetry-instrumentation-asyncpg/src/opentelemetry/instrumentation/asyncpg/__init__.py
Show resolved
Hide resolved
This reverts commit bf33f17.
|
I believe the tracer_provider is used for resource attributes. Adding to your point here is the small discussion we had about using the resource from span instead #345 (comment). If there is no other reason to pass tracer provider I think we can get rid of it. |
|
@lonewolf3739 @lzchen regarding logging instrumentation, it would be ideal if we could update it to extract service name from the span instead of provider but I don't know if that is possible without adding a dependency on the SDK. One possible solution could be to implement log injection as a feature of the SDK instead of an instrumentation. Technically it's not really an instrumentation as it doesn't instrument the logging module (doesn't trace it) but provides utility to augment generated logs with additional data. The behavior is actually part of upcoming Otel log spec as well. |
I agree. We can add a dependency on the SDK to begin with and later move the package out of instrumentations into either it's own package or into the SDK. |
…hon-contrib into issue-401
|
@owais |
Description
An optional tracer provider can be passed to instrumentations to use for creating tracer instances. There is no consistency in instrumentations.
Contributes to #401