How should we handle single-host RPC spans in the UI?

[codefromthecrypt]

At least htrace, opentracing, google cloud trace and sleuth use single-host spans. For example, client send and server receive are in different spans, based on the client or the server tracer.

Zipkin's v1 model was designed to have client and server in the same span, hence the need for the annotations "cs" "sr" "ss" "sr". Zipkin v2 will probably move to single-host (per #939)

Zipkin's UI was designed for when a single span contained both client and server sides. Ex. there's a single bar for a client+server span, and there are dots for each of the major client or server events (such as client receive or server send). This cuts the visual depth of a trace quite a bit.

Conversely, single-host spans have a separate span for a client or a server. This means that a server span is visually below its client counterpart. For the same amount of RPCs, this is double the "bars" vs client+server spans.

Do we need any UI work wrt single-tracer RPC spans, or is status quo ok?

[codefromthecrypt]

cc'ing some who might have an opinion: @marcingrzejszczak @yurishkuro @clehene

[yurishkuro]

@adriancole the examples you asked for. Looks fairly normal, the one weird thing is the query service adds server annotations to the middle span client.post. Also, the server span is centered, even though the IP is the same (though I haven't used the latest code).

3b47c02255029f91.json.txt

[codefromthecrypt]

closed in favor of #1799