jaegertracing / jaeger-ui

Web UI for Jaeger
http://jaegertracing.io/
Apache License 2.0
1.14k stars 482 forks source link

Allow visualizing only part of the trace (starting from given span id) #255

Open atsu85 opened 6 years ago

atsu85 commented 6 years ago

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

Visualizing only part of the trace starting from given span - essentially visualizing only subtree of whole trace

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

Visualizing only part (that i'm currently interested in) of very big trace.

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

In addition to visualizing full trace, allow visualizing only part of the trace, starting from given span.

I understand that probably currently server doesn't allow searching for trace subtrees based on spanId, so for me personally it would be ok if in addition to entering only span id (of the trace that i want to see) i'd have to provide traceId as well (for example in format ${traceId}:${spanIdToVisualize} that would be similar to the format that is used in logs about reported spans where the format seems to be smth like ${traceId}:${activeSpanId}:${parentSpanId}:${tracingFlags})

tiffon commented 6 years ago

@atsu85, thanks for creating this ticket.

Focusing on sub-section(s) of traces is something I've been curious about for some time.

Can you describe your sense of what an ideal user-experience might be?

yurishkuro commented 6 years ago

Can you please describe the use case where this would be needed?

atsu85 commented 6 years ago

@tiffon and @yurishkuro, thanks for your replies.

Can you please describe the use case where this would be needed?

Suppose i have huge trace (trace containing lots of spans) and i have identified span that i want to investigate further. User may have identified the interesting span either

Focusing on sub-section(s) of traces is something I've been curious about for some time.

I'm glad that i'm not alone with this interest :)

Can you describe your sense of what an ideal user-experience might be?

From visual perspective when showing selected part of the trace (based on given span) then UI should probably look pretty similar to visualizing whole trace, except that instead of showing visualization of the trace starting from trace root span, the visualization would filter out all ancestor and sibling spans - just showing selected span and its descendants. Just as if the selected span hadn't been connected to the trace started before it, but as if the trace had been started from that selected span.

To allow deep linking, it would be nice, if url would also be changed when visualizing part of the trace starting from selected span. For example it would be nice if for example instead of '/trace/:traceId' url would be changed to '/trace/:traceId/:selectedSpanId' (or just '/span/:selectedSpanId' when at some point when Jaeger server supports searching traces based on span id) - then it would be possible to easily share a link to it (for example from issue tracker, instant messenger etc.).

Additional nice to have feature would be to include link to full trace visualization from header component - basically zoom out to trace root span.

Depending on how user has identified the interesting span the ideal user-experience is different. When the span has been identified from the trace visualization in Jaeger UI, then it would be most convenient to have a link on each span (except trace root span) that would open visualization of the trace starting from that span - basically zoom in functionality. When the span has been identified for example from application logs, it would be most convenient if Jaeger UI would provide means to open trace subtree visualization based on just span id. But as i suspect that Jaeger server doesn't provide means to search traces by span id, then it would be the easiest to implement it if user also needs to provide traceId in addition to spanId (then no additional endpoints are needed from Jaeger UI). And as the log entries anyway contain ${traceId}:${activeSpanId}:${parentSpanId}:${tracingFlags} then initially we could reuse similar format in search-box that currently works with traceId. If input has format ${traceId}:${spanId} then user should be taken directly to trace subtree visualization instead of to whole trace visualization.

yurishkuro commented 6 years ago

/trace/:traceId/:selectedSpanId

just want to mention that there are two use cases that can benefit from deep link like that. One is what you described (only showing the subtree that starts with the selected span). The other is still showing the whole trace, but somehow highlighting and scrolling into view the selected span. The latter is particularly useful when some problem in the trace is identified by data mining jobs.

yurishkuro commented 4 years ago

Zipkin recently added "re-root" function:

66175135-09287600-e68b-11e9-8871-5e96c3b735b8

everett980 commented 4 years ago

The other is still showing the whole trace, but somehow highlighting and scrolling into view the selected span.

This part is possible through uiFind: /trace/:traceId?uiFind=${spanID}

An "expand all children of span" button may further bridge the gap between current functionality and a full sub-trace view.

quaff commented 4 years ago

"re-root" is a desired feature.