Identify dependencies in the UI when remote is not instrumented

Requirement - what kind of business use case are you trying to solve?

Visual distinction of service calls in a trace, when the target service does not implement tracing.

Problem - what in Jaeger blocks you from solving the requirement?

From what I can find in documentation/issues, you can get the serviceName set only if you use the Zipkin ingestion or if there is a span.kind=server span that is receiving your remote call. In my scenario, I’d rather use Jaeger-first APIs if possible, and there is no instrumentation on the receiving side. But it seems that span.kind=client doesn’t use the peer.service tag (instead it tries to just hide if there’s instrumentation on both ends).

Proposal - what do you suggest to solve the problem or improve the existing situation?

Since the instrumentation-on-both-ends scenario hides the client span anyway, I propose (if there’s not a workaround) to use peer.service as the span’s service name when there is no server receiving span.

I’m open to any other way to visually distinguish my off-service calls too! (Aside from the workaround that involves spinning up a new Tracer object for each, which was noted in gitter as a workaround but discouraged of its use.

Any open questions to address

[yurishkuro]

I have a concrete proposal how this can be implemented visually, using already existing functionality. But default, Jaeger shows client-server calls like this:

The middle span is the client span, which would become the leaf if the route service was not instrumented. When this span is collapsed, the view changes to show the destination service:

I think the same display can be re-purposed for cases when route is not instrumented, but still known via peer.service tag on the client span.

[yurishkuro]

This would only touch the jaeger-ui, right?

Yes.