api: adding trace.get_current_span by toumorokoshi · Pull Request #552 · open-telemetry/opentelemetry-python

toumorokoshi · 2020-04-04T04:54:22Z

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.

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.

toumorokoshi · 2020-04-04T04:55:53Z

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?

…urrent-span

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.

toumorokoshi · 2020-05-14T23:31:27Z

additional context: open-telemetry/opentelemetry-specification#455

…urrent-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.

opentelemetry-api/src/opentelemetry/trace/__init__.py

ext/opentelemetry-ext-opentracing-shim/src/opentelemetry/ext/opentracing_shim/__init__.py

opentelemetry-sdk/src/opentelemetry/sdk/trace/propagation/b3_format.py

lzchen · 2020-05-18T20:44:11Z

"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."

Can you explain this part a little more? What would set_current_span imply in behaviour that it actually isn't doing?

opentelemetry-sdk/src/opentelemetry/sdk/trace/__init__.py

lzchen · 2020-05-19T00:51:09Z

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>

…n-telemetry#751)

opentelemetry-api/src/opentelemetry/trace/propagation/__init__.py

lzchen

LGTM. Some non-blocking comments/questions.

linux-foundation-easycla · 2020-06-08T22:31:15Z

✅ Yusuke Tsutsumi (46bcf63, 71e70b6, 12569ea, 3480e41, 885228c, aa128fe, 612db6c, 167482c, ec1c120, 088931d, 95b3663, a901b8a, 791c31b, 6973d24, 9708ca9, e7472e7, f8da41d, 5c03a97, 236223d, c5b960a, dc6a77e, d8320d5, 3732f31, c8de5ed, aae0402, 1a692ab, cc08e7a, 3d30915, 412d20f, 8e7db78)
✅ alrex (fc9897f, c4f1364)
✅ Leighton Chen (2f9d229, 9e5ddbb)
✅ Diego Hurtado (1086c83)
✅ Andrew Xue (afe6150)

❌ Hector Hernandez The commit (aad61af) is not authorized under a signed CLA. Please click here to be authorized. For further assistance with EasyCLA, please submit a support request ticket.

codeboten

This looks good. Just a non-blocking question

codeboten · 2020-06-04T15:23:37Z

docs/api/trace.span.rst

@@ -0,0 +1,7 @@
+opentelemetry.trace.span
+==========================


Suggested change

==========================

========================

codeboten · 2020-06-08T23:22:33Z

opentelemetry-api/src/opentelemetry/trace/span.py

+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()


Any reason these were moved as well? Was this to get around a circular dependency issue?

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?

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.

lzchen

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.

lzchen

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>

tedsuo · 2020-06-26T05:44:28Z

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

toumorokoshi requested review from a team and codeboten April 4, 2020 04:54

toumorokoshi added 8 commits April 6, 2020 15:15

Merge branch 'master' into feature/trace-get-current-span

71e70b6

Merge remote-tracking branch 'source/master' into feature/trace-get-c…

12569ea

…urrent-span

fixing lint

3480e41

fixing test

885228c

Fixing mypy.

aa128fe

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.

Merge branch 'master' into feature/trace-get-current-span

612db6c

removing __init__.py

167482c

It was causing issues with the module import order.

removing recursive import.

ec1c120

toumorokoshi added api Affects the API package. needs reviewers PRs with this label are ready for review and needs people to review to move forward. labels May 8, 2020

toumorokoshi added 3 commits May 14, 2020 22:20

Merge remote-tracking branch 'source/master' into feature/trace-get-c…

088931d

…urrent-span

Removing get_current_span from Tracer and TracerProvider

95b3663

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.

removing missed reference to tracer.get_current_span

a901b8a