[APM] UI changes to trace summary (above waterfall/timeline)

[katrin-freihofner]

This issue is about a small UI update for the information grid within the Transaction sample panel. The goal is to remove the generic grid of label/values to a single line of values without labels. (Discussion initiated by: #42357)

Sub tasks:

• Truncate url to a max-width (some urls can be very long)
• Show the sum of all errors in the trace (Fixes: [APM] Transaction sample error count doesn't match the errors in the trace #42357) (Fixed in [APM] Display all errors in child transactions/spans in trace overview #44274)
• Highlight http status code (Fixes: [APM] Enhance status code presentation in the Transaction sample header #29928)
• Display timestamp, duration, url, http method and http status code on a single line
• Add user_agent fields to metadata
• Add transaction.result field to metadata

Implementation notes:

• use euiText--small
• I used the euiColorMediumShade #98A2B3 for the pipes |
• the method (GET,...) should be bold

It should look similar to:

This work does not include the arrows which is specified in this issue #35574

[katrin-freihofner]

@sqren, @nehaduggal should we stay with Transaction sample as a headline, or is there a better solution?

[elasticmachine]

Pinging @elastic/apm-ui

[dgieselaar]

This is from Stackdriver:

What I really like about this is that if you click on a dot, it's much more clear that you're going to inspect the trace that that dot represents. To me it's really hard to (intuitively) make the connection between clicking on a bucket and then inspecting a sample in that bucket. And perhaps having a scatter plot opens up more visualisation possibilities, e.g. color by result, or size by the number of child spans.

(Probably out of scope though 😀)

[sorenlouv]

To me it's really hard to (intuitively) make the connection between clicking on a bucket and then inspecting a sample in that bucket

I didn't intuitively understand the histogram in the beginning, whereas the dots do make sense immediately. It also gives the user a second dimension (time) that they can select from.
It is a little less clean, and the histogram is a bit better at showing the distribution (I think). And many overlapping dots could make the navigation a little awkward.

But I'm definitely open to discussing whether it could replace the histogram.

[sorenlouv]

Another problem with the current histogram: it is the only viz where x-axis is not time. This is confusing initially I think.

[katrin-freihofner]

I'm biased - I can clearly see that ;)
I like the idea of having another iteration about the bucket chart. It obviously has some drawbacks. But I would also like to move forward with the small changes to the info-grid above the timeline. Is it ok if we move the chart discussion to a new issue?

[sorenlouv]

@katrin-freihofner We currently use a custom component StickyProperties to build the list but agree we should use the EUI description list if possible. This change will affect the lists on the following pages:

• Transaction details page (the one we are talking about here)
• Error details page
• Transaction flyout
• Span flyout

Is that ok? If so, I think this looks good, and the issue can be moved to the APM UI board.

[katrin-freihofner]

@sqren yes, actually that's perfect!

[nehaduggal]

How about we call it Trace sample instead of Transaction sample? The waterfall essentially surfaces a trace with one or more transactions so calling it Transaction sample can be misleading.

[sorenlouv]

@katrin-freihofner Did you see this related issue?
#29928

Do you think the two issues should be kept separate, or do you want to combine them?

[katrin-freihofner]

@sqren no, I have not been aware of this issue. Thank you. I'm fine with combining them.

[katrin-freihofner]

Summarising our discussion in slack:

Instead of the pretty big description list/grid we want to try to fit the information in one line beneath the headline, like:
Trace sample
19. Aug 2019 09:50:12 | 153 ms | 10% of trace | https://myurl.com | <EuiBadge>5XX</EuiBadge>

I suggest to move the labels to tooltips. Additionally, as discussed in this issue #29928 we should use the EUI Badge for 4XX and 5XX response codes.

@sqren, @roncohen, @nehaduggal, @dgieselaar should we drop the error info if there are no errors? And can we move user ID, device and agent to the meta info?

[sorenlouv]

@katrin-freihofner

Instead of the pretty big description list/grid we want to try to fit the information in one line beneath the headline

++

I suggest to move the labels to tooltips.

Also fine with me. For many fields we have both a label (eg. "Duration") and a field name ("transaction.duration.us")

I'm okay with moving the label into the tooltip, and thus getting rid of the field name. If people want to know where the value resides in elasticsearch they can find that in the metadata.

should we drop the error info if there are no errors

I think we should. I don't see any good reasons to show "No errors for trace". Wouldn't this be the expected default? And then draw attention to errors with a red badge if there are any.

And can we move user ID, device and agent to the meta info?

We already show user.id but none of the user agent fields. We probably want to show these:

[katrin-freihofner]

I updated the description according the our discussion. @sqren I think this is ready for implementation. What's your opinion?

[sorenlouv]

@katrin-freihofner I updated the description with some more sub tasks. LMK if that aligns with your thinking.

Questions:

• How should we handle very long urls? I think we could truncate above, say 50 chars, and then show the full url in a tooltip.
• I don't see http method or http status code in the screenshot. I think it would be great if we could somehow "group" those together with the url graphically.

Swagger.io (API tool) groups http method and url like this:

Insomnia (REST client) groups http details like this:

I think the use of badges can help the information stand out more clearly. Right now all the information has the same formatting which makes it harder to distinguish.

[katrin-freihofner]

@sqren that is perfect, thank you.
Regarding your questions:

• If possible I would suggest to use an ellipsis like: https://api.github.c...aphql

• I think this is a good idea. We could use an EuiBadge (default color) for the http method and response code (like described here: [APM] Enhance status code presentation in the Transaction sample header #29928)

[sorenlouv]

@katrin-freihofner What do you think about something like this?
https://codesandbox.io/s/eui-badges-h8vhj

[katrin-freihofner]

@sqren I would use the hollow style for the url but otherwise - yes, that's a good idea.

[sorenlouv]

Just brainstorming here, but instead of using | as dividers could we use the hollow badges? And additionally combine the duration and percentage of trace in a single badge (that also makes the percentage tangible)

200:

300:

500:

[smith]

For non-HTTP requests, we talked on Slack about doing the following:

• Leaving out the URL and method
• Using transaction.result instead of http.status_code

(A non-HTTP reques is a request that does not have a http key in its transaction, so things like background or batch jobs, or possibly other network protocols like grpc or thrift that aren't going over HTTP.)

You can see some non-http requests in the sample data under apm-server > Process Pending and on opbeans-python if you change the transaction type to "celery" (a background job processing framework).

The celery traces have a SUCCESS or FAILURE result while the apm-server one has none.

We can probably apply the same colors as 2xx/5xx to SUCCESS/FAILURE but I think a result could be anything.

@katrin-freihofner let me know if this sounds good or if you would like any more changes to the non-HTTP requests.

[katrin-freihofner]

@smith, in general, this sounds good to me. As far as I know, we did not pick a specific success color yet. Looking at the Eui Badges (https://elastic.github.io/eui/#/display/badge) I propose to go for secondary.

[sorenlouv]

We can probably apply the same colors as 2xx/5xx to SUCCESS/FAILURE but I think a result could be anything.

Yes, transaction.result could be any string so I don't think we should attempt to apply colors to it.

[smith]

@katrin @sqren a few questions:

The only thing left in the StickyTransactionProperties after we move everything to the single line and metadata is “Errors”, which we only show if there are related errors.

It seems like it would look weird if that label and error count were just sitting there alone, so where and how should we be displaying the “[ N ] Related Errors”?

For the tooltips when hovering over the values on the single-line summary, there’s some comments on the issue:

Would the tooltip only show the label name or the value too?

The tooltip will only show the value.

Does that mean when hovering over “20ms” I would see “transaction.duration.us” in the tooltip or “Duration”? Not sure about what we mean by “name” and “value” in this context.

and also:

I’m okay with moving the label into the tooltip, and thus getting rid of the field name. If people want to know where the value resides in elasticsearch they can find that in the metadata.

But the metadata tab only shows some values and does not include the span.duration or transaction.result for example. Should we add those to the metadata as well?

[sorenlouv]

@smith fyi: @dgieselaar has a fix for #42357 in #44274.

I think we should get entirely rid of StickyTransactionProperties and the error count should be displayed on the single line.

[sorenlouv]

But the metadata tab only shows some values and does not include the span.duration or transaction.result for example. Should we add those to the metadata as well?
@smith

I added a todo for adding the transaction.result to metadata.
Regarding span.duration: we are currently only retiring the StickyTransactionProperties component. There is still a StickySpanProperties component when the user clicks on a span. We haven't decided what to do with that, and this issue shouldn't be blocked by that.

[smith]

we are currently only retiring the StickyTransactionProperties component. There is still a StickySpanProperties component when the user clicks on a span. We haven't decided what to do with that, and this issue shouldn't be blocked by that.

@sqren StickyTransactionProperties is also used on the flyout, so I'm leaving it alone but removing it from the transaction page.

[sorenlouv]

@smith Makes sense to leave it for now. We can do that as a follow-up.

[katrin-freihofner]

@smith regarding the tooltip I think it is fine to show Duration. transaction.duration.us is for a more advanced use case and as far as I know, it will be visible in the flyout.

[smith]

@dgieselaar @sqren these things seem to be in conflict:

The timestamp and duration labels are relatively long...

The summary relatively quickly starts wrapping...

and

URL shouldn't be truncated so aggressively

In addition to status code we should also show status text, eg "200 Success"

@katrin-freihofner would you mind taking a look to see if there's changes we can make to present more information and prevent it from wrapping so much?