Improve trace navigation in graph

[jotak]

In the graph trace overlay, when a node is selected, we can navigate through spans that originate from that node:

This might lead to some misunderstanding & non-obvious navigation, because the trace contains X spans but only a few of them are accessible from there (only the ones that are from the same node).

So, I think it would be more interesting to allow here to navigate, through these "next" / "prev" arrows, within the whole trace and not only within spans of that node. When moving to a span that comes from another node, that would automatically put the focus on it in the graph.

Any objection?

[lucasponce]

So, I think it would be more interesting to allow here to navigate, through these "next" / "prev" arrows, within the whole trace and not only within spans of that node. When moving to a span that comes from another node, that would automatically put the focus on it in the graph.

Any objection?

+1

It sounds good to me.

As a user I guess from here I'd like to have the minimal info to decide if I need to click and navigate into the trace details or as you say, navigate to other trace.

[jotak]

I have started to work on that. I have a question for the graph folks (@israel-hdez @jshaughn and all)
When "navigating" though the trace spans, it will now be possible to show the span details of other graph nodes, not only the node that was selected at first.
Should it imply re-focusing on that node? What would you expect as a user?

E.g. if node "reviews-v1" is selected, and through the trace I display the information of the next span "rating-v1", is it expected that this "rating-v1" node becomes selected for the whole summary panel? Or do we keep the trace/span details disconnected from the overall logic?

[israel-hdez]

@jotak I'm not familiar to Jaeger and I see counter-intuitive to see all spans. But experienced people may find it better. So, I'm wondering if it's too hard to add a checkbox to let the user decide to see only spans of the selected node, or see all spans of the trace.

Should it imply re-focusing on that node? What would you expect as a user?

Personally, I would expect no re-focusing. I would expect a small message (with an info icon) stating that the span if is for another node. In combination with the checkbox I'm suggesting, IMO this will be a very clear behavior.

[jshaughn]

@jotak My initial feeling is that it will be confusing to re-focus as the user may lose context. But maybe we'll just have to see this in action before we can decide. Another possibility would be some sort of manual click option to re-focus.

[jotak]

@jotak I'm not familiar to Jaeger and I see counter-intuitive to see all spans. But experienced people may find it better. So, I'm wondering if it's too hard to add a checkbox to let the user decide to see only spans of the selected node, or see all spans of the trace.

The rationale is to offer a way to "navigate" into the trace. Clicking on graph nodes isn't a good way to do that, because it loses context of the previously selected span.
I agree that it is still a good thing to be able to choose a span related to the selected node.
Perhaps the good solution would be to keep the current list of spans (perhaps displayed differently), and add links to parent and children. Those links would re-focus.

I can make a try with that.

[jshaughn]

add links to parent and children. Those links would re-focus.

That sort of manual re-focus may be the solution.

[jotak]

Just for reference, here's an example of trace that illustrate why we should disambiguate "spans on node" versus "parent/children relations" :

                    +                        +
                    |                        |
    NODE A          |   NODE B               |   NODE C
                    |                        |
   +------+         |                        |
   |Span 1|         |                        |
   |start |         |                        |
   +------+         |                        |
      |             |                        |
      |             |                        |
      |             |                        |
      |    +------+ |  +-------+             |
      +--->+Span 2+--->+Span 3 |             |
      |    |send  | |  |receive|             |
      |    +------+ |  +-------+             |
      |             |      |                 |
      |             |      |                 |
      |             |      |      +------+   |   +-------+
      |             |      +----->+Span 4+------>+Span 6 |
      |             |      |      |send  |   |   |receive|
      |             |      |      +------+   |   +-------+
      |             |      |                 |
      |             |      |      +------+   |   +-------+
      |             |      |      |Span 5|   |   |Span 7 |
      |             |      +----->+send  +------>+receive|
      |             |             +------+   |   +-------+
      |    +------+ |  +-------+             |
      |    |Span 8| |  |Span 9 |             |
      +--->+send  +--->+receive|             |
           +------+ |  +-------+             |
                    |                        |
                    +                        +

For instance, if we look at node B, it has 4 spans, but it is clear that in terms of relation the next spans of 4 isn't 5 but 6 (on another node). As well as span 9 is a child of 8 and has no direct relation with any other span from node B.

And all of this, in the graph, would be "compressed" like this:

   +-----+     +-----+     +-----+
   |  A  +---->|  B  +---->|  C  |
   +-----+     +-----+     +-----+