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

Open
adriancole opened this Issue Jan 10, 2017 · 1 comment

Projects

None yet

1 participant

@adriancole
Contributor
adriancole commented Jan 10, 2017 edited

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) #963
  • Clock skew correction (correct skew when "cs" "cr" is the parent of "sr" "ss")
  • Dependency linking (ensure split spans increment service link only once)
  • 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment