Skip to content
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

Merged

Conversation

toumorokoshi
Copy link
Member

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 toumorokoshi requested review from codeboten and a team April 4, 2020 04:54
@toumorokoshi
Copy link
Member Author

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.
@toumorokoshi 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
Copy link
Member Author

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.
@lzchen
Copy link
Contributor

lzchen commented May 18, 2020

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

@lzchen
Copy link
Contributor

lzchen commented May 19, 2020

Include an entry in CHANGELOG?

toumorokoshi and others added 8 commits June 4, 2020 23:04
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>
Copy link
Contributor

@lzchen lzchen left a 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.

@linux-foundation-easycla
Copy link

linux-foundation-easycla bot commented Jun 8, 2020

CLA Check

Copy link
Contributor

@codeboten codeboten left a 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

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
==========================
========================

Comment on lines +109 to +152
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()
Copy link
Contributor

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?

Copy link
Member Author

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?

Copy link
Contributor

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.

Copy link
Contributor

@lzchen lzchen left a 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/

Copy link
Contributor

@lzchen lzchen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice

@toumorokoshi toumorokoshi merged commit 3fa15aa into open-telemetry:master Jun 9, 2020
codeboten pushed a commit to codeboten/opentelemetry-python that referenced this pull request Jun 11, 2020
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
Copy link

tedsuo commented Jun 26, 2020

Nice to see common operations getting more convenient. :)

srikanthccv pushed a commit to srikanthccv/opentelemetry-python that referenced this pull request Nov 1, 2020
* 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api Affects the API package. needs reviewers PRs with this label are ready for review and needs people to review to move forward.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants