[APM] One-line trace summary

[smith]

Summary

Replace the StickyTransactionProperties with a trace summary that puts everything on one line.

Fixes #43247.

Some example screenshots

An HTTP request with an error:

An HTTP request with no errors:

A non-HTTP request with no result:

A non-HTTP request with an error an a result:

Checklist

Use strikethroughs to remove checklist items you don't feel are applicable to this PR.

• This was checked for cross-browser compatibility, including a check against IE11
• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Documentation was added for features that require explanation or tutorials
• Unit or functional tests were updated or added to match the most common scenarios
• This was checked for keyboard-only and screenreader accessibility

For maintainers

• This was checked for breaking API changes and was labeled appropriately
• This includes a feature addition or change that requires a release note and was labeled appropriately

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request

[dgieselaar]

Really like how this looks in general 👍

Some things that caught my eye (will review code later):

• The timestamp and duration labels are relatively long, and because they're the same size/color it makes it a bit hard to scan for me. Maybe we can do something here with shorter labels or displaying some of the text in a slightly lighter shade.

• The summary relatively quickly starts wrapping. Maybe another reason to make the labels a little more compact, either by truncating, styling, or simply displaying less (detailed) information.
  

[sorenlouv]

Why title={undefined}? Can't that be dropped?

[sorenlouv]

(Same with other occurrences of title={undefined})

[smith]

An EuiBadge by default apparently sets the title attribute of the element to the contents of the element, so if you hover over "1 Error" you get a title tooltip that says "1 Error". This also occurs when an EuiToolTip is present, so you get a weird double-tooltip.

[sorenlouv]

I've never understood the appeal of these annotations (but I'm definitely in the minority here :D). If we are going to use them what do you think about the shorthand:

const Heading: React.FC = () => (

or perhaps even:

import React, { FC } from 'react';

// ...

const Heading: FC = () => (

?

[smith]

I'm fine with using FC. The annotations are helpful because a function component is not just a regular function. If you use these annotations you get autocomplete for react-specific properties:

I like it because it's more explicit and gives the user and the type checker more context.

[sorenlouv]

Yeah, I can see that. However, I barely think you can find any usages of those props anywhere. I recall displayName was needed for HOC (replaced by hooks),defaultProps is replaced with es6 default parameters and propTypes is replaced with Typescript.
I can't remember how contextTypes - we don't use it even though we use context a lot.

So to me it is a solution to a problem I don't have :)

[smith]

For me it's less about the autocomplete and more about explicitly stating, "this is what this thing is."

[sorenlouv]

Makes sense. I find great value in Typescript's explicitness . It's like code comments that are guaranteed to be up to date.

[dgieselaar]

FWIW, @sqren previously argued that FC implicitly types children which I think is a good reason to avoid it.

[sorenlouv]

As mentioned in the issue we also have this one #29725

[sorenlouv]

Unused?

[sorenlouv]

Instead of using whitespace {' '} for styling, you should add padding to the styled component.

[dgieselaar]

You could perhaps also opt for border-right: 1px solid ${euiColorMediumShade}, and have a TraceSummaryBlock component or something like that. Not sure if that would be better though.

[sorenlouv]

Is the fragment needed?

Suggested change

	<>({percentOfTraceText})</>
	({percentOfTraceText})

[sorenlouv]

Oh - is it because it's required by EuiToolTip? Then it makes sense (although EuiToolTip should just accept strings in the first place)

[smith]

Opened elastic/eui#2292 to track this.

[sorenlouv]

This is how it looks for me:

A couple of adjustments:

• URL shouldn't be truncated so aggressively
• The http containers should be vertically aligned with the text (duration and timestamp)
• In addition to status code we should also show status text, eg "200 Success"

[sorenlouv]

Perhaps extract this to a separate method const color = getStatusCodeColor(status)

[sorenlouv]

Shouldn't this be && instead of ||? afaict anything above 300 will always return euiColorVis5

[sorenlouv]

Perhaps simply use <strong>{method}</strong> ?

[sorenlouv]

Or maybe that's abuse to use semantic tags for styling. I'm okay with either

[smith]

Using an explicit styled component is probably safer and more "semantic", but I'll just use strong because it's less code.

[sorenlouv]

I'm not 100% but I don't think a RUM transaction will ever have http. We have to double check with @vigneshshanmugam or @jahtalab .

If that's the case we should remove the transaction.page.url from HttpInfo (since it will never be rendered) and instead render the RUM url as a separate use case aka:

if (isHttp) (
 <HttpInfo />
} else if (result) {
  <TransactionResult />
} else if (isRumAgent()) {
  <RumAgentUrl />
} 

[vigneshshanmugam]

As @sqren mentioned, We don't have transaction.http field at the moment for RUM agent.

[sorenlouv]

Thank @vigneshshanmugam. Do you plan to add it in the near-ish future?

[smith]

I changed this to remove the check for http which really wasn't necessary in the first place.

[vigneshshanmugam]

Atleast for spans, we have the http info, But cant for transaction everything is grouped under page, request and response so wont be added in the nearish future.

[smith]

This is how it looks for me:

@sqren do you have an example of a trace where it looked like that for you or was it all of them? Does not look like that for me.

[dgieselaar]

Great work Nathan!

[dgieselaar]

instead of includeText, maybe this component should just support children? Also this label is pretty similar to xpack.apm.transactionDetails.errorsOverviewLink, which we use in StickyTransactionProperties.

[dgieselaar]

how useful is this test?

[smith]

It asserts that the thing actually can render given those props. I usually use a test like this as a starting point and then use Jest coverage mapping or just TDD to fill in all the use cases.

So, it's not that useful but more useful than having nothing.

[dgieselaar]

FWIW, @sqren previously argued that FC implicitly types children which I think is a good reason to avoid it.

[dgieselaar]

EUIToolTip supports the className prop, so you might be able to use that with styled-components:

const ToolTipWithoutWhitespace = styled(EUIToolTip)`
  white-space: nowrap;
`;

(iirc)

[dgieselaar]

You could perhaps also opt for border-right: 1px solid ${euiColorMediumShade}, and have a TraceSummaryBlock component or something like that. Not sure if that would be better though.

[dgieselaar]

Might be useful to split this file up? e.g. TraceSummary/{index,Duration,HttpStatusBadge}.tsx

[dgieselaar]

maybe this looks better as:

const colors = {
  2: theme.euiColorVis0,
  3: theme.euiColorVis5,
  4: theme.euiColorVis7,
  5: theme.euiColorVis2
};	
const resultGroup = status ? status.substr(0) : null;

const color = colors[resultGroup] || null;

[dgieselaar]

I think we should use units here to make elements align better. Those units are located in x-pack/legacy/plugins/apm/public/style/variables.ts.

[dgieselaar]

it might make sense to use EUIFlexGrid and EUIFlexItem here, instead of using spaces (or even padding. There's some additional benefits we get, responsiveness for instance (well, sort of).

[dgieselaar]

I think this can be improved a little. The conditions and different branches make it a little hard to follow for me. What do you think of:

const items = [
  <Timestamp transactionTimestamp={transaction['@timestamp']} />,
  <Duration
    duration={transaction.transaction.duration.us}
    totalDuration={totalDuration}
  />
];

if (isHttp) {
  items.push(<HttpInfo transaction={transaction} />);
} else if (result) {
  items.push(<Result result={result} />);
}

if (errorCount > 0) {
  items.push(
    <ErrorCountBadge
      errorCount={errorCount}
      includeText={true}
      title={undefined}
    />
  );
}

and then:

{items.reduce(
  (acc, item, index) => {
    const next = acc.concat(item);
    if (index !== items.length - 1) {
      next.push(<Separator />);
    }
    return next;
  },
  [] as React.ReactElement[]
)}

I think this would improve further if you use a EUIFlexItem with padding/border-right too.

[smith]

I find that much harder to follow, but I'll try to make what I have there easier to follow.

[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?

[sorenlouv]

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

hehe, true :) I think there is a bit of truth to both though. We talked about using the short month format. That'll help a bit.
And then I suggest we move the line down below the "Action" and "View full trace" buttons, so it can take the full width if needed (relevant on my 13").

If we do that I think it'll be possible to show both more of the url and have the status text without it wrapping.

[sorenlouv]

Regarding the status code colors: I don't think we should stick to the EUI colors. Normally I'm totally for following a color scheme but in this case it just looks really off (imo). I previously mentioned the colors Google Chrome (and many others) use:

Green for 2xx

Yellow for 3xx

Red for 4xx and 5xx

I thought we agreed on them but maybe not. @katrin-freihofner ?

EDIT: Okay, maybe we should stick to the EUI color palette but at least still use green-ish for 2xx, yellow-ish for 3xx and red for 4xx and 5xx.

[katrin-freihofner]

Eui provides nice colors for indicating status: https://elastic.github.io/eui/#/utilities/color-palettes
I would stick to these: euiPaletteForStatus ...there is a red, green and yellow.

[sorenlouv]

Eui provides nice colors for indicating status

Yay! Those colors are much better! Thanks for pointing that out.

[katrin-freihofner]

@smith good work! I have two questions:

1. Should the errors be clickable? They are in the current version, linking to the errors page.
2. Can we add aria attributes to state the labels? Currently, the screen reader reads the values but without the labels (as they are only available in the tooltips.)

[sorenlouv]

@katrin-freihofner

Should the errors be clickable? They are in the current version, linking to the errors page.

Since #42357 the errors badge in the header is no longer clickable. So I think it is fine as-is.
The reason is there can be more than one error. In that case we don't have a single page to link to. The user will still be able to click the error in the waterfall

[smith]

@dgieselaar

FWIW, @sqren previously argued that FC implicitly types children which I think is a good reason to avoid it.

I'm ok with that. Do we have any kind of team-specific style guide or do we suggest changes to the kibana JS style guide for decisions like this?

[smith]

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

@sqren not sure if we have this in the transaction data. http.response has status_code but not status_text. Should I be looking somewhere else?

[sorenlouv]

@sqren not sure if we have this in the transaction data. http.response has status_code but not status_text. Should I be looking somewhere else?

No, we only have the status code. There are probably lots of libraries that can do this but keeping out own list is probably simpler. Porting it from this php gists should do the trick: https://gist.github.com/henriquemoody/6580488

[smith]

No, we only have the status code. There are probably lots of libraries that can do this but keeping out own list is probably simpler. Porting it from this php gists should do the trick: gist.github.com/henriquemoody/6580488

https://github.com/prettymuchbryce/http-status-codes seems to be exactly what we want and it has no other dependencies. It's MIT licensed. Would it be better just to copy the code in or add as a dependency in x-pack?

[sorenlouv]

This looks great. Good job @smith !

I'm surprised why the status code/text is black on red (whereas the error is white on red):

I think the contrast would be better with white:

I think EUI does some contrast calculation and determines the color, so not something we should have to override. Just wondering why it decided for black instead of white.

Any idea about this, @cchaos ? (we use EUIBadge btw)

[cchaos]

Technically the calculations are correct. Black text on that color has better contrast and passes WCAG levels.

Where white does not

If you're concerned by those colors, consider just sticking to our danger color instead of a custom value.

[smith]

@cchaos we're using the euiPaletteForStatus from https://elastic.github.io/eui/#/utilities/color-palettes. Do you think these are the correct colors to use for HTTP status codes?

[cchaos]

That status palette is more for creating a larger spectrum between green and red. Though they can be used for badges as well, we haven't tested them in that capacity as they were originally created for charts (no text).

[smith]

That status palette is more for creating a larger spectrum between green and red. Though they can be used for badges as well, we haven't tested them in that capacity as they were originally created for charts (no text).

@katrin-freihofner should we replace these with Secondary/Warning/Danger? I can make a ticket.

[katrin-freihofner]

@smith I guess this would work better. 👍

[sorenlouv]

@katrin-freihofner Maybe it's just me, but I find the green in the status palette (#58BA6D) much more indicative of success than the primary badge color (#76a29e) which is closer to a off blue than green.

I've tried to find a bunch of examples of http status code colors, and even though they don't have exactly the same shades they all have green, yellow and red that closer corresponds to success, warning and error imo.

https://www.steveschoger.com/status-code-poster/img/status-code.png

https://i0.wp.com/csharpcorner.mindcrackerinc.netdna-cdn.com/article/create-api-with-asp-net-core-day-three-working-with-http-status-codes-in-asp/Images/image002.jpg?zoom=2

https://i.ytimg.com/vi/LtNSd_4txVc/maxresdefault.jpg

http://1.bp.blogspot.com/-d36gBYfZutc/UIlqyr9JEfI/AAAAAAAAA0g/Gbx_73pNrXg/s1600/HTTP+status+code+defenitions.gif

[katrin-freihofner]

@sqren we can use the Eui badge's color prop to set a custom color. I suggest euiColorSecondary #017D73. This color is used to indicate success all over the UI. If we use this, the text should be white.

[sorenlouv]

Oh yes, sorry if that's what you meant in the first place. That's much better.

What do you think about:
2xx: #017D73
3xx: #017D73
4xx: #F5A700
5xx: #BD271E

[sorenlouv]

2xx is definitely success and 5xx is definitely error.
3xx and 4xx are a little harder to categorize, since they could be both.
I'd say that 3xx should still be considered successful since the redirect happens correctly.
4xx could both be caused by the end user and the web application so warning is more applicable than error.

[katrin-freihofner]

In my opinion, a warning is fine for 4xx. What if we use a more neutral color like euiColorDarkShade #69707D for 3xx?

[sorenlouv]

What if we use a more neutral color like euiColorDarkShade #69707D for 3xx?

Works for me 👍 We could use the same for 1xx

[smith]

@katrin-freihofner @sqren opened #45406 for color updates.

[sorenlouv]

Tested in Chrome and Firefox. This should also be cross-browser tested in IE.