Track usability problems when RPC are split across span IDs

codefromthecrypt commented 7 years ago

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:

[x] UI Usability (how to make split span events appear in the same detail panel) #1799
[x] Clock skew correction (correct skew when "cs" "cr" is the parent of "sr" "ss")
[x] Dependency linking (ensure split spans increment service link only once) #1656
[x] 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 commented 7 years ago

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

codefromthecrypt commented 7 years ago

cc @reta

codefromthecrypt commented 7 years ago

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 commented 7 years ago

added https://github.com/openzipkin/zipkin/pull/1656 to fix dependency linking. Noticed this when implementing the simple json thing

codefromthecrypt commented 5 years ago

please take a look at https://github.com/openzipkin/zipkin/pull/2302 and let me know if this is still desirable! I think this is the last step cc @ivantopo

openzipkin / zipkin

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