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

Merge SpanContext into Span and make DefaultSpan private #1712

Closed
wants to merge 2 commits into from

Conversation

anuraaga
Copy link
Contributor

@anuraaga anuraaga commented Sep 26, 2020

While open-telemetry/opentelemetry-specification#999 won't be merged, I think we can say that we have SpanContext, it just happens to be merged into Span as an implementation detail.

The API seems to be vastly simplified by this change. Far less dancing, no creating a Span just to have a container for storing in Context - we always just work with Spans. No need to explain to users what the difference between SpanContext and Context is, we only have one context. How to link to a span? Add a link to the span.

I noticed that we use DefaultSpan for three purposes currently

Let me know any thoughts. Will finish up with javadoc if seems ok.

Fixes #1704
Fixes #1135

@codecov
Copy link

codecov bot commented Sep 26, 2020

Codecov Report

Merging #1712 into master will decrease coverage by 0.19%.
The diff coverage is 86.03%.

Impacted file tree graph

@@             Coverage Diff              @@
##             master    #1712      +/-   ##
============================================
- Coverage     85.48%   85.29%   -0.20%     
- Complexity     1378     1382       +4     
============================================
  Files           164      163       -1     
  Lines          5402     5433      +31     
  Branches        559      566       +7     
============================================
+ Hits           4618     4634      +16     
- Misses          586      595       +9     
- Partials        198      204       +6     
Impacted Files Coverage Δ Complexity Δ
...pentelemetry/opentracingshim/ScopeManagerShim.java 72.72% <0.00%> (-9.10%) 5.00 <0.00> (ø)
.../main/java/io/opentelemetry/sdk/trace/Sampler.java 100.00% <ø> (ø) 0.00 <0.00> (ø)
...telemetry/sdk/trace/export/BatchSpanProcessor.java 86.00% <0.00%> (-3.34%) 8.00 <1.00> (ø)
...ions/trace/jaeger/sampler/JaegerRemoteSampler.java 68.62% <0.00%> (ø) 9.00 <0.00> (ø)
...ions/trace/jaeger/sampler/PerOperationSampler.java 0.00% <0.00%> (ø) 0.00 <0.00> (ø)
...opentelemetry/opentracingshim/SpanBuilderShim.java 54.16% <33.33%> (-0.48%) 22.00 <1.00> (ø)
...telemetry/extensions/trace/propagation/Common.java 72.22% <50.00%> (ø) 10.00 <0.00> (ø)
...ions/trace/jaeger/sampler/RateLimitingSampler.java 70.83% <50.00%> (ø) 8.00 <3.00> (ø)
.../main/java/io/opentelemetry/trace/DefaultSpan.java 70.21% <66.66%> (-10.56%) 26.00 <12.00> (+7.00) ⬇️
api/src/main/java/io/opentelemetry/trace/Span.java 81.25% <70.00%> (-18.75%) 7.00 <7.00> (+7.00) ⬇️
... and 23 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c0969d4...5fe4c94. Read the comment docs.

Comment on lines +33 to +39
String getTraceIdAsHexString();

String getSpanIdAsHexString();

TraceState getTraceState();

byte getTraceFlags();
Copy link
Member

Choose a reason for hiding this comment

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

This actually seems worse than before. Could we return a DefaultSpan here instead?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Link is strange in being over-coupled to export right now. I don't think export structures should be based on e.g., Span so I'll look at it in #1714.

@Oberon00
Copy link
Member

Oberon00 commented Sep 26, 2020

This PR is already huge. I suggest moving the "make DefaultSpan private" to a separate/follow-up PR. You could select this PR's branch as target branch and link it in the PR description. Or ensure it is separate in the commit history of this PR at least.

@anuraaga
Copy link
Contributor Author

@Oberon00 I found a lot of code using SpanContext and DefaultSpan interchangeably. So I think the story of this PR isn't complete without combining both. If the direction is ok, I can split out the DefaultSpan visibility change if others also find it changes the reviewability significantly.

Copy link
Member

@bogdandrutu bogdandrutu left a comment

Choose a reason for hiding this comment

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

This needs to go to the specs, because we remove an important concept from the API

@anuraaga
Copy link
Contributor Author

Yeah but since open-telemetry/opentelemetry-specification#999 is marked after-ga it won't be acted on right? Are we stuck with the cruft because of that? I would still say we haven't really removed anything, it's just a matter of presentation within the Java code.

Comment on lines +32 to +35
private final String traceId;
private final String spanId;
private final byte traceFlags;
private final TraceState traceState;
Copy link
Member

Choose a reason for hiding this comment

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

does it work to store a propagated Span here instead?

@trask
Copy link
Member

trask commented Sep 27, 2020

@bogdandrutu can you give us some options for how we can move forward with this before GA?

This looks like a really good change, especially now with Propagated Span, SpanContext class doesn't seem to be pulling any weight.

I also think this is a very good point from @anuraaga:

When users come to tracing for the first time, I think they understand the concept of a span. And they notice that a span is supposed to have a trace id and span id, they see this in tracing UIs. The presence of SpanContext seems to just add indirection that complicates the model for new users. It's especially confusing with a similarly named but very different Context.

@trask
Copy link
Member

trask commented Sep 27, 2020

@anuraaga maybe go ahead and send spec PR for open-telemetry/opentelemetry-specification#999? IIRC after-ga means not required for ga, it doesn't preclude a spec PR from being accepted prior to GA, I would think especially a spec PR that doesn't require other SDKs to do any new work

@Oberon00
Copy link
Member

Spec is already frozen for non-editorial changes. Maybe you can get an exception for that one though? As it does not increase (required) work for SIGs.

@trask
Copy link
Member

trask commented Sep 28, 2020

I added this topic to the maintainers meeting agenda for tomorrow to explore our options

@anuraaga
Copy link
Contributor Author

@trask (I think) it's just a one line change so doesn't hurt to make a PR indeed :) open-telemetry/opentelemetry-specification#1022

@iNikem
Copy link
Contributor

iNikem commented Sep 28, 2020

Does current spec prevent us from having SpanContext as interface, btw?

@anuraaga
Copy link
Contributor Author

@iNikem Nope that was changed in open-telemetry/opentelemetry-specification#969. So for issues of bridging, I think an interface would be fine too if this can't be accepted. But I realized the API could be made much simpler here while working on that PR :)

@iNikem
Copy link
Contributor

iNikem commented Sep 28, 2020

If we make SpanContext an interface, and make Span implement it, maybe we can still simplify Java API significantly without direct contradiction to spec?

@anuraaga
Copy link
Contributor Author

@iNikem Didn't think of that idea - seems to be an ok option if SpanContext must survive but a bit of an unnecessary interface. Guess I can start with it to get this out of draft

io.opentelemetry.trace.Span span = tracer().getCurrentSpan();
if (DefaultSpan.getInvalid().equals(span)) {
if (!span.isValid()) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Slightly incorrect, as in OT it's possible to set an invalid Span (one with zero-ed ids) as the active instance. We should check against Span.getInvalid()

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Do you think you can give me a unit test that fails with the current code? OTel has many invalid checks, for example in instrumentation - I'd be surprised if we could even support a zero'd but live span in OTel. I'm guessing OT would propagate such a span, but OTel won't - so maybe we can just unify this behavior with the OTel semantics? Anyways a unit test would probably make things very clear, I'm not changing it back if we can't get the current code to fail first :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Another way to phrase my point of confusion - I would think returning a singleton for an invalid span is a performance optimization but wouldn't expect any behavior change. So if the use of a singleton is relied on here, it's unexpected and seems fragile. If it's required I need to add some more detailed docs.

Copy link
Member

@Oberon00 Oberon00 Sep 29, 2020

Choose a reason for hiding this comment

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

Not supporting valid spans with all zero trace or span ID is something that irks me about OTel actually, see open-telemetry/opentelemetry-specification#753

@anuraaga
Copy link
Contributor Author

Separated out #1791 so closing this

@anuraaga anuraaga closed this Oct 13, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Update DefaultSpan to match the new spec Why is there a DefaultSpan?
6 participants