-
Notifications
You must be signed in to change notification settings - Fork 657
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
api: adding trace.get_current_span #552
api: adding trace.get_current_span #552
Conversation
The span context is no longer coupled with the tracer itself. As such, providing a get_current_span method bound to the trace api module rather than a specific tracer is semantically correct, and removes a hurdle where someone who wants to retrieve the current trace would have to create a tracer to do so. renaming and export get_span_in_context to get_current_span, as the intention of the API is similar, and reduces unneeded aliasing and duplication. set_span_in_context is not renamed, as set_current_span would have implied that the span would then be active in the default context, which is only true after attaching the resulting context returned by set_span_in_context. Keeping that name at least implies some asymmetric behavior from get_current_span.
As a thought here, this paves the way to remove the [TracerSource|Tracer].get_current_span methods as well. I didn't do so in this commit because that breaks compatibility quite significantly. But I feel like it's worth removing as a single pattern for active span manipulation would minimize confusion. Thoughts? |
mypy needs re-exports called out explicitly in one of two ways: * in the __all__ param * using the "import y as x" syntax. Modifying the imports to work in this fashion solves the issue.
It was causing issues with the module import order.
additional context: open-telemetry/opentelemetry-specification#455 |
After discussion in the SIG, we decided to remove the legacy get_current_span APIs from Tracer and TracerProvider to reduce long-term confusion of how to idiomatically retrieve the span.
ext/opentelemetry-ext-opentracing-shim/src/opentelemetry/ext/opentracing_shim/__init__.py
Outdated
Show resolved
Hide resolved
"set_span_in_context is not renamed, as set_current_span would have Can you explain this part a little more? What would |
Include an entry in CHANGELOG? |
Missing references in the documentation were causing issues with dependent class definitions.
This commit ports the OpenTracing testbed[1] to check that the ot-shim is working as expected using different frameworks. Gevent doesn't support context vars yet[2], so those tests are not compatible with opentelemetry and were not ported. [1] https://github.com/opentracing/opentracing-python/tree/master/testbed [2] gevent/gevent#1407 Co-authored-by: Mauricio Vásquez <mauricio@kinvolk.io> Co-authored-by: alrex <aboten@lightstep.com>
Co-authored-by: Yusuke Tsutsumi <yusuke@tsutsumi.io>
Co-authored-by: Cheng-Lung Sung <clsung@gmail.com>
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.
LGTM. Some non-blocking comments/questions.
|
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.
This looks good. Just a non-blocking question
docs/api/trace.span.rst
Outdated
@@ -0,0 +1,7 @@ | |||
opentelemetry.trace.span | |||
========================== |
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.
========================== | |
======================== |
class TraceFlags(int): | ||
"""A bitmask that represents options specific to the trace. | ||
|
||
The only supported option is the "sampled" flag (``0x01``). If set, this | ||
flag indicates that the trace may have been sampled upstream. | ||
|
||
See the `W3C Trace Context - Traceparent`_ spec for details. | ||
|
||
.. _W3C Trace Context - Traceparent: | ||
https://www.w3.org/TR/trace-context/#trace-flags | ||
""" | ||
|
||
DEFAULT = 0x00 | ||
SAMPLED = 0x01 | ||
|
||
@classmethod | ||
def get_default(cls) -> "TraceFlags": | ||
return cls(cls.DEFAULT) | ||
|
||
@property | ||
def sampled(self) -> bool: | ||
return bool(self & TraceFlags.SAMPLED) | ||
|
||
|
||
DEFAULT_TRACE_OPTIONS = TraceFlags.get_default() | ||
|
||
|
||
class TraceState(typing.Dict[str, str]): | ||
"""A list of key-value pairs representing vendor-specific trace info. | ||
|
||
Keys and values are strings of up to 256 printable US-ASCII characters. | ||
Implementations should conform to the `W3C Trace Context - Tracestate`_ | ||
spec, which describes additional restrictions on valid field values. | ||
|
||
.. _W3C Trace Context - Tracestate: | ||
https://www.w3.org/TR/trace-context/#tracestate-field | ||
""" | ||
|
||
@classmethod | ||
def get_default(cls) -> "TraceState": | ||
return cls() | ||
|
||
|
||
DEFAULT_TRACE_STATE = TraceState.get_default() |
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.
Any reason these were moved as well? Was this to get around a circular dependency issue?
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 moved the minimum, which were primarily classes. I also moved default objects to be near their class counterparts.
DEFAULT_TRACE_STATE might have been ok. Do yo think we should try to keep the module small and move related objects up to trace if we can?
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 was thinking that the TraceState and TraceFlags classes might be better living in trace/__init__py
since it doesn't seem to fit strictly within a Span
but i'm mostly curious.
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.
Just a change waiting on exposing set_span_in_context
in the tracing api module/
Adding docstrings for propgation span methods. Exporting set_span_in_context in trace.
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.
Nice
The span context is no longer coupled with the tracer itself. As such, providing a get_current_span method bound to the trace api module rather than a specific tracer is semantically correct, and removes a hurdle where someone who wants to retrieve the current trace would have to create a tracer to do so. renaming and exporting get_span_in_context to get_current_span, as the intention of the API is similar, and reduces unneeded aliasing and duplication. set_span_in_context is not renamed, as set_current_span would have implied that the span would then be active in the default context, which is only true after attaching the resulting context returned by set_span_in_context. Keeping that name at least implies some asymmetric behavior from get_current_span. After discussion in the SIG, we decided to remove the legacy get_current_span APIs from Tracer and TracerProvider to reduce long-term confusion of how to idiomatically retrieve the span. Co-authored-by: alrex <aboten@lightstep.com> Co-authored-by: Hector Hernandez <39923391+hectorhdzg@users.noreply.github.com> Co-authored-by: Leighton Chen <lechen@microsoft.com> Co-authored-by: Diego Hurtado <ocelotl@users.noreply.github.com> Co-authored-by: Mauricio Vásquez <mauricio@kinvolk.io> Co-authored-by: Andrew Xue <aaxue@google.com> Co-authored-by: Cheng-Lung Sung <clsung@gmail.com>
Nice to see common operations getting more convenient. :) |
* chore: linting * feat(collector-exporter): new exporter for opentelemetry collector * chore: updating readme * chore: undo auto lint fix - which is wrong * chore: updates after comments * chore: renaming util to transform * chore: renaming types, last comments from review * chore: adding missing links * chore: fixes after comments * chore: fixes after comments * chore: fixes after comments * chore: updating jsdoc * chore: enabling attributes * chore: adding script to generate package version file * chore: naming * chore: adding todo * chore: updating types for link * chore: fixing typo * chore: removing unnecessary typing * chore: const for enum * chore: adding missing interface for message event * chore: adding timestamp example * chore: changes after review * chore: adding case when the exporter is shutdown but export is called * chore: adding missing header for request to prevent instrumentation
The span context is no longer coupled with the tracer itself.
As such, providing a get_current_span method bound to the
trace api module rather than a specific tracer is semantically
correct, and removes a hurdle where someone who wants to retrieve
the current trace would have to create a tracer to do so.
renaming and export get_span_in_context to get_current_span,
as the intention of the API is similar, and reduces unneeded
aliasing and duplication.
set_span_in_context is not renamed, as set_current_span would have
implied that the span would then be active in the default context,
which is only true after attaching the resulting context returned
by set_span_in_context. Keeping that name at least implies some
asymmetric behavior from get_current_span.