-
Notifications
You must be signed in to change notification settings - Fork 896
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Moving active span interaction To Trace Context Utilities #923
Moving active span interaction To Trace Context Utilities #923
Conversation
Fixes open-telemetry#455. The previous spec stated that the active span get / set behavior MUST behave the same across Tracers retrieved from the same TracerProvider. As such, the active span manipulation methods are better provided by the TracerProvider directly. As it is still cumbersome to retrieve the current TracerProvider simply to get the current span, add in the concept of a "Trace Package", that can provide utilty methods to delegate to the configured default TracerProvider. This enables a fluid interface to retrieve the current span: from opentelemetry import trace current_span = trace.get_current_span() To help maintain backwards compatibility, the Tracer may still expose active span methods.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand the motivation for this. Span interactions, including active span, are best done via Tracer, it minimizes the number of objects that instrumentation has to deal with. How that's done by the tracer is an implementation detail, the only requirement is for active span accessors to act consistently.
And it does not fix #455, where the objective was to achieve the most normalized (albeit more verbose) API, which are maximally decoupled (i.e. Tracer does not need to know anything about Context - see opentracing.Tracer, for example).
@yurishkuro regarding #455: yes, it's a good point that the original point of the issue isn't solved. I've added my rationale and moved the references to a new issue #924 that describes the desire in more detail. Regarding who should perform span interactions: creating a Span currently requires a Tracer to ensure named tracers, so that certainly can't be moved. But there is a common use case of retrieving the active span, for the purposes of adding or modifying it in some fashion. The API as written implies that the active span should be the same regardless of which Tracer retrieves it. As such, retrieving the span from a tracer has a few cons, from my perspective:
APIs are subjective, but adding get_current_span to the module in Python had a quorum that this was a change that improved the user experience significantly. |
@toumorokoshi Thanks for the PR. As @Oberon00 mentioned, this is better separated from Your example would stay the same (i.e.
In OT we had these as shortcuts, but I heard some users got confused by it. Something to ponder. |
Ok! That sounds like another opinion supporting #923 (comment), so I'll get that PR up as well.
@carlosalberto would you mind elaborating? I think we still need to leave those methods for backwards compatibility, but would be interested in more data to inform the final design. |
…eraction-from-contextmanager
Removing the get / set current span methods from the TracerProvider. There is consensus that the functions should have the same behavior regardless of the TracerProvider. This change now means that the span retrieval methods can not be defined completely by the Trace Package. Moving the requirements up to the package level.
@Oberon00 @carlosalberto addressed your concerns, PTAL. |
So in OT we had the context functionality in a But to simplify things, lets consider removing such |
Selecting "Tracing Context Utilities" rather than "Trace Package" to provide clear guidance on languages that do not have static module-level functions. Adding a section on the ability to expose these as module-level functions to ensure that the simplified workflow of a top-level get / set span is possible.
87fa2df
to
bebaf44
Compare
Thanks, looks great! @open-telemetry/specs-approvers Please review. |
That might be a good design too, but in OpenTelemetry, the Tracer MUST use the Context system, that is even specified in the API spec.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for taking care of this.
Ping @yurishkuro - all feedback has addressed, I think, but would love to have our final review (take?) on this before we actually merge it ;) |
@toumorokoshi please rebase |
@bogdandrutu I updated the branch (just a conflict in the changelog) but we're still waiting for @yurishkuro to approve (or dismiss his change request). |
…etry#923) * Moving active span interaction To TracerProvider Fixes open-telemetry#455. The previous spec stated that the active span get / set behavior MUST behave the same across Tracers retrieved from the same TracerProvider. As such, the active span manipulation methods are better provided by the TracerProvider directly. As it is still cumbersome to retrieve the current TracerProvider simply to get the current span, add in the concept of a "Trace Package", that can provide utilty methods to delegate to the configured default TracerProvider. This enables a fluid interface to retrieve the current span: from opentelemetry import trace current_span = trace.get_current_span() To help maintain backwards compatibility, the Tracer may still expose active span methods. * Adding missing entries for TracerProvider functionality * Addressing feedback * fixing lint (multiple blank lines) * Addressing feedback Removing the get / set current span methods from the TracerProvider. There is consensus that the functions should have the same behavior regardless of the TracerProvider. This change now means that the span retrieval methods can not be defined completely by the Trace Package. Moving the requirements up to the package level. * Addressing comments Selecting "Tracing Context Utilities" rather than "Trace Package" to provide clear guidance on languages that do not have static module-level functions. Adding a section on the ability to expose these as module-level functions to ensure that the simplified workflow of a top-level get / set span is possible. * fixing invalid Trace Package reference * removing unrelated change * adding changelog entry Co-authored-by: Carlos Alberto Cortez <calberto.cortez@gmail.com> Co-authored-by: Armin Ruech <armin.ruech@dynatrace.com>
Fixes #924
Motivation
The Trace API currently
Changes
The previous spec stated that the active span get / set behavior MUST
behave the same across Tracers retrieved from the same TracerProvider.
As such, the active span manipulation methods are better provided by the
TracerProvider directly.
As it is still cumbersome to retrieve the current TracerProvider simply
to get the current span, add in the concept of a "Trace Package", that can
provide utilty methods to delegate to the configured default TracerProvider.
This enables a fluid interface to retrieve the current span:
To help maintain backwards compatibility, the Tracer may still expose
active span methods.