openzipkin
Track usability problems when RPC are split across span IDs
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.
cc @openzipkin/instrumentation-owners @fedj @openzipkin/core @cburroughs @rogeralsing
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
added https://github.com/openzipkin/zipkin/pull/1656 to fix dependency linking. Noticed this when implementing the simple json thing
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