Kibana: [APM] Ability to click through multiple traces collected for a transaction group for a selected time bucket

[nehaduggal-zz]

We collect multiple traces for slow transactions for every bucket but currently the only way a customer can see more of these traces is by switching over to discover. It would be nice to have a button called view similar traces to see other traces that were collected for the selected time bucket, so a customer can visualize those collected traces in the waterfall view.

Implementation issue: https://github.com/elastic/kibana/issues/44078

[elasticmachine]

Pinging @elastic/apm-ui

[katrin-freihofner]

Open questions from the slack discussion with @nehaduggal and @sqren :

1. Can we use the EUI pagination (https://elastic.github.io/eui/#/navigation/pagination)? And where would we place it?
2. Is there a max no. of samples we would like to show (samples can be 1000s, nobody will every look at all of them)
3. Currently we show the most recent sample - do we want it to stay this way?

[nehaduggal]

1. We should use the compressed nav from the EUI pagination link and place it next to the Transaction Sample. Would have been nice to have it in the top right but that space already has too much going on with the Action and View full trace button.
2. Lets limit the no of samples to 10.
3. The 10 samples can be random and we should still show the most recent sample.

[katrin-freihofner]

@nehaduggal An alternative that comes to my mind would look like:

[katrin-freihofner]

As this is related to https://github.com/elastic/kibana/issues/43247 we could add the next prev buttons to the subheadline with the meta info. Like this:

@nehaduggal @hbharding

[sqren]

Since this could be a lot more complex than the redesign I think we should keep it separate (not that you said other-wise).

In you design, where did the "Action" popover and "View full Trace" button go?

[katrin-freihofner]

I tested this with the condensed meta data:

As discussed with @nehaduggal I think the next/prev buttons need a label, like shown in the img.

[sqren]

I agree, the labels make it more clear. Although in the screenshot above they come with a lot of added whitespace and the header becomes taller, pushing the timeline below down. Could the prev/next buttons be positioned next to the Trace sample header; the Action button or somewhere else?

[katrin-freihofner]

I agree, I was working on an update anyhow:

I'm not sure if we should/need to explain that we are limiting the samples we are showing.

[sqren]

I think that looks good. Although I'm not sure we want to show "10 / 1000 samples available". We might not know the exact number of samples (counting can be a little expensive).

Instead I suggest we show "Sample 1/10", "Sample 2/10" as the user clicks through.

[katrin-freihofner]

EUI suggests:

[sqren]

Wouldn't we still need some text to explain what the user is paginating? If not I think we should just go with the compressed version:

I don't see any use cases for being able to jump to a specific sample by its number in the list. They are pretty much random.

[hbharding]

I agree with @sqren - we should indicate how many samples there are, and which sample they are currently looking at. Otherwise, users may feel lost while paging through the samples. Here's a mockup that might work:

[nehaduggal]

Looks great! One small feedback, can we drop the box around the URL because the box makes it look like its editable although its not.

[hbharding]

@nehaduggal I don't have a strong opinion on the hollow white badge. One benefit is that it uses smaller text, which means less ellipsis. Also with badges, visually, it's 3 similar parts that make up a whole... X + Y + Z = "the reuqest". Last point - these mockups only show a portion of the screen, which makes it difficult to get a sense for the scale and font sizes. In other words, the badge might look less like a text input when viewed with the surrounding UI. Not sure.

But like i said, no strong opinion. Maybe try it both ways and make a final decision when we can see it in full context.

[sqren]

can we drop the box around the URL because the box makes it look like its editable although its not.

I can see that - although I think the alternative is worse. Without the borders, the url loses the connectedness to the http method and status code (imo), and it just becomes another piece of text. To understand what it is the user has to actually read it instead of intuitively understanding what it is from its visual appearance.

If there are other approaches to achieve the same effect I'd love to hear!

[katrin-freihofner]

I guess this would work too and the URL would not look editable.

[katrin-freihofner]

I discussed the pagination of samples and the collapsed info in the subheadline yesterday with @nehaduggal. It seems like we can move this to implementation. One more thing that should change compared to the current implementation: if we don't have the information, e.g. about the URL - we don't show it (n/a does not make sense without the labels). @sqren are there any open questions from your side?

[sqren]

I guess this would work too and the URL would not look editable.

Yes totally. Perhaps with GET as bold or something to separate it from the URL (although not important if you don't think so)

[sqren]

if we don't have the information, e.g. about the URL - we don't show it (n/a does not make sense without the labels).

I think if we don't have a url, we won't have a http status code or a http method either. So all that info disappears (which is fine with me)

fyi: I verified this with:

not url.full :* and not transaction.page.url :* and (http.response.status_code: * or http.request.method:* )

and didn't get any results

It seems like we can move this to implementation.

👍

[katrin-freihofner]

@sqren sounds good, do you want me to open a new ticket for this or should we combine it with the summary update https://github.com/elastic/kibana/issues/43247?

[sqren]

@katrin-freihofner Let's keep them separate. The summary update is fairly low-hanging fruit, whereas this could be more complex.