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

Track usability problems when RPC are split across span IDs #1480

Open
4 of 5 tasks
codefromthecrypt opened this issue Jan 10, 2017 · 5 comments
Open
4 of 5 tasks

Track usability problems when RPC are split across span IDs #1480

codefromthecrypt opened this issue Jan 10, 2017 · 5 comments
Labels

Comments

@codefromthecrypt
Copy link
Member

codefromthecrypt commented Jan 10, 2017

Some are intentionally or accidentally splitting RPCs across different span IDs. For example, they might intentionally fork a span ID when receiving B3 headers. This could also happen when an intermediary forks a new span, but fails to report it to Zipkin. In either case, the client ends up as a parent span as opposed to the same span as the server.

The goal of this issue is to support the case where a client span is a parent of the server span in the existing model. This is a precondition of any work that assumes single-host (like #939), or at least a warning of what glitches will occur until single-host RPC spans are supported.

Here are the main feature areas to explore:

  • UI Usability (how to make split span events appear in the same detail panel) zipkin-ui does not support non-shared spans #1799
  • Clock skew correction (correct skew when "cs" "cr" is the parent of "sr" "ss")
  • Dependency linking (ensure split spans increment service link only once) Supports dependency linking on single-host RPC spans #1656
  • B3 propagation (ensure single-host process is captured so it can be used consistently)
  • Document how to handle grey-box intermediaries (proxies that once added annotations between client and server ones in the same span)

transparent proxies should be unimpacted as they just sent headers across without changing them or reporting anything to zipkin anyway.

@codefromthecrypt
Copy link
Member Author

cc @openzipkin/instrumentation-owners @fedj @openzipkin/core @cburroughs @rogeralsing

@codefromthecrypt
Copy link
Member Author

cc @reta

@codefromthecrypt
Copy link
Member Author

one can model single producer multiple consumer messages with a parent-child relationship similar to single-host spans in RPC. For example, by using X-B3-SpanId as the parent id of the consumer span, many consumers will end up as different spans. So, this pattern for single-host spans also applies to SPMC

https://github.com/openzipkin/b3-propagation#why-is-parentspanid-propagated

codefromthecrypt pushed a commit that referenced this issue Jul 20, 2017
Before, if a client span was a parent of a server span, linking wouldn't
work.

See #1480
@codefromthecrypt
Copy link
Member Author

added #1656 to fix dependency linking. Noticed this when implementing the simple json thing

codefromthecrypt pushed a commit to openzipkin/brave that referenced this issue Oct 6, 2017
Similar to ClientServerSameSpan in zipkin-go, this adds the ability to
opt out of span sharing between the client and server side of an RPC.
This is important when reporting to systems that do not share span IDs,
such as Google Stackdriver and Amazon X-Ray.

Note: this still defaults to true, in favor of existing Zipkin
implementations. See openzipkin/zipkin#1480
codefromthecrypt pushed a commit to openzipkin/brave that referenced this issue Oct 6, 2017
Similar to ClientServerSameSpan in zipkin-go, this adds the ability to
opt out of span sharing between the client and server side of an RPC.
This is important when reporting to systems that do not share span IDs,
such as Google Stackdriver and Amazon X-Ray.

Note: this still defaults to true, in favor of existing Zipkin
implementations. See openzipkin/zipkin#1480
codefromthecrypt pushed a commit to spring-cloud/spring-cloud-sleuth that referenced this issue Oct 6, 2017
This adds the ability to opt out of span sharing between the client and
server side of an RPC. This is important when reporting to systems that
do not share span IDs, such as Google Stackdriver and Amazon X-Ray.

Note: this still defaults to true, in favor of existing Zipkin
implementations. See openzipkin/zipkin#1480

See #395
See #459
codefromthecrypt pushed a commit to openzipkin/brave that referenced this issue Oct 6, 2017
Similar to ClientServerSameSpan in zipkin-go, this adds the ability to
opt out of span sharing between the client and server side of an RPC.
This is important when reporting to systems that do not share span IDs,
such as Google Stackdriver and Amazon X-Ray.

Note: this still defaults to true, in favor of existing Zipkin
implementations. See openzipkin/zipkin#1480
codefromthecrypt pushed a commit that referenced this issue Nov 8, 2018
@codefromthecrypt
Copy link
Member Author

please take a look at #2302 and let me know if this is still desirable! I think this is the last step cc @ivantopo

abesto pushed a commit to abesto/zipkin that referenced this issue Sep 10, 2019
thgoexpt added a commit to thgoexpt/Java-distributed-tracing-implementation that referenced this issue Apr 7, 2022
Similar to ClientServerSameSpan in zipkin-go, this adds the ability to
opt out of span sharing between the client and server side of an RPC.
This is important when reporting to systems that do not share span IDs,
such as Google Stackdriver and Amazon X-Ray.

Note: this still defaults to true, in favor of existing Zipkin
implementations. See openzipkin/zipkin#1480
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant