Sort tags in expanded span view

[mabn]

Description

Expanding a span on the UI shows collapsed list of tags which can be expanded again. When there are many tags it's hard to find the one a person is looking for

E.g. when all headers are added as tags and I'm looking for a particular one it's usually easier to use ctrl+f and type part of its name.

An example:

Additionally some tags might be more significant than others so it might make sense to have a way to prioritize them (e.g. user_id, or http.url for http client/server spans). But it's something extra.

Steps to reproduce the issue:

Expand any span

Describe the results you received:

Tags which appear to be in random order. It's hard to find the important ones with a first glance.

Describe the results you expected:

Tags ordered in some way which makes it easy to "understand" what's on the list

Additional information you deem important (e.g. issue happens only occasionally):

It's not bug. I'm also not sure if sorting is the best solution but the current display is not ideal.

[mabn]

somewhat related: #181

[tiffon]

@mabn, thanks for creating this ticket!

I think the order has a significance... @black-adder, are tags returned from the query-service in the order they're added to the span?

Regarding organizing the chaos, would sorting and filtering help?

I've added Sort and Filter UI elements just above the Tags table in the screenshot below.

The functionality the Sort and Filter UI elements provide would be local to this particular Tags table. Expanding the Process table or a log message would reveal the same UI elements above those tables.

Some thoughts on how it could work:

• The sort and filter UI elements would only be visible when the content is expanded, e.g. Tags is open, the others are closed, so they only show for Tags
• Sorting could be "natural", initially, and clicking the "Sort" text would toggle through ASC, DESC, "natural"
• The filter could match key or value, as a sub-string
  • Matched results would be rendered at the top of the table
  • Non-matching results would be rendered under matched results with reduced opacity
    • Keeping unmatched results in the table will keep the row the same height and prevent recalculating the height of all rows in the timeline

What do you think?

[yurishkuro]

Side note: while the order of tags reflects how they are stored in the span, many Jaeger clients use maps to store the tags before they are sent out, so the order may not be preserved.

[tiffon]

In that case, maybe we should sort the tables and only add the filter functionality?

[mabn]

Filter - i'm not sure if it's needed in my case - there's probably no more than 50 tags per span and on average there's 15 - a bit of scrolling is faster.

The sort button would be useful, although it's likely that once I sort tags in one span then I'd like to have them most of the time. Some global option might be better - e.g. doing it by default, or a configuration option.

[yurishkuro]

My suggestion is to always sort on display and not complicate the UI further (sorting on demand within a single span sounds weird).

As for filter, I think a better contextual search asked in another ticket is a more general and useful solution.

[nabam]

Was any conclusion on this issue made? We are using jaeger together with istio telemetry and apparently istio produces spans with randomly ordered tags. It would be very convenient to be able see tags sorted by key in the span view.

I wonder when preserved order of tags is useful, are there any use-cases at all?

[yurishkuro]

The conclusion is that the UI should always sort the tags. This issue is up for grabs.