Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[APM] One-line trace summary #44842

Merged
merged 1 commit into from Sep 9, 2019

Conversation

@smith
Copy link
Member

commented Sep 5, 2019

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:

image

An HTTP request with no errors:

image

A non-HTTP request with no result:

image

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

image

Checklist

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

For maintainers

@smith smith requested a review from elastic/apm-ui as a code owner Sep 5, 2019

@elasticmachine

This comment has been minimized.

Copy link
Contributor

commented Sep 5, 2019

@dgieselaar

This comment has been minimized.

Copy link
Contributor

commented Sep 5, 2019

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.

image

  • 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.
    image
<ErrorCountBadge
errorCount={errorCount}
includeText={true}
title={undefined}

This comment has been minimized.

Copy link
@sqren

sqren Sep 5, 2019

Member

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

This comment has been minimized.

Copy link
@sqren

sqren Sep 5, 2019

Member

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

This comment has been minimized.

Copy link
@smith

smith Sep 5, 2019

Author Member

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.

// TODO: Light/Dark theme (@see https://github.com/elastic/kibana/issues/44840)
const theme = euiLightVars;

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

This comment has been minimized.

Copy link
@sqren

sqren Sep 5, 2019

Member

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 = () => (

?

This comment has been minimized.

Copy link
@smith

smith Sep 5, 2019

Author Member

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:

image

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

This comment has been minimized.

Copy link
@sqren

sqren Sep 5, 2019

Member

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 :)

This comment has been minimized.

Copy link
@smith

smith Sep 5, 2019

Author Member

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

This comment has been minimized.

Copy link
@sqren

sqren Sep 5, 2019

Member

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

This comment has been minimized.

Copy link
@dgieselaar

dgieselaar Sep 5, 2019

Contributor

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

import { ErrorCountBadge } from './ErrorCountBadge';
import { truncate } from '../../../../style/variables';

// TODO: Light/Dark theme (@see https://github.com/elastic/kibana/issues/44840)

This comment has been minimized.

Copy link
@sqren

sqren Sep 5, 2019

Member

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

import { NOT_AVAILABLE_LABEL } from '../../../../../common/i18n';
import { isRumAgentName } from '../../../../../common/agent_name';
import { ErrorCountBadge } from './ErrorCountBadge';
import { truncate } from '../../../../style/variables';

This comment has been minimized.

Copy link
@sqren

sqren Sep 5, 2019

Member

Unused?

const Separator: React.FunctionComponent = () => (
<>
{' '}
<SeparatorText aria-hidden={true}>|</SeparatorText>{' '}

This comment has been minimized.

Copy link
@sqren

sqren Sep 5, 2019

Member

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

This comment has been minimized.

Copy link
@dgieselaar

dgieselaar Sep 5, 2019

Contributor

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.

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

This comment has been minimized.

Copy link
@sqren

sqren Sep 5, 2019

Member

Is the fragment needed?

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

This comment has been minimized.

Copy link
@sqren

sqren Sep 5, 2019

Member

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

This comment has been minimized.

Copy link
@smith

smith Sep 5, 2019

Author Member

Opened elastic/eui#2292 to track this.

@sqren

This comment has been minimized.

Copy link
Member

commented Sep 5, 2019

This is how it looks for me:

Screen Shot 2019-09-05 at 11 11 36

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"
color = theme.euiColorVis7;
} else if (status >= 500) {
color = theme.euiColorVis2;
}

This comment has been minimized.

Copy link
@sqren

sqren Sep 5, 2019

Member

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

return null;
} else if (status < 300) {
color = theme.euiColorVis0;
} else if (status >= 300 || status < 400) {

This comment has been minimized.

Copy link
@sqren

sqren Sep 5, 2019

Member

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

}
)}
>
<MethodText>{method}</MethodText>

This comment has been minimized.

Copy link
@sqren

sqren Sep 5, 2019

Member

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

This comment has been minimized.

Copy link
@sqren

sqren Sep 5, 2019

Member

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

This comment has been minimized.

Copy link
@smith

smith Sep 5, 2019

Author Member

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

const isRumAgent = isRumAgentName(transaction.agent.name);
const url = isRumAgent
? idx(transaction, _ => _.transaction.page.url) || NOT_AVAILABLE_LABEL
: idx(transaction, _ => _.url.full) || NOT_AVAILABLE_LABEL;

This comment has been minimized.

Copy link
@sqren

sqren Sep 5, 2019

Member

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 />
} 

This comment has been minimized.

Copy link
@vigneshshanmugam

vigneshshanmugam Sep 5, 2019

Member

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

This comment has been minimized.

Copy link
@sqren

sqren Sep 5, 2019

Member

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

This comment has been minimized.

Copy link
@smith

smith Sep 5, 2019

Author Member

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

This comment has been minimized.

Copy link
@vigneshshanmugam

vigneshshanmugam Sep 6, 2019

Member

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 comment has been minimized.

Copy link
Member Author

commented Sep 5, 2019

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
Copy link
Contributor

left a comment

Great work Nathan!

export const ErrorCountBadge = ({ errorCount = 0, ...rest }: Props) => (
export const ErrorCountBadge = ({
errorCount = 0,
includeText = false,

This comment has been minimized.

Copy link
@dgieselaar

dgieselaar Sep 5, 2019

Contributor

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.

transaction={transaction}
/>
)
).not.toThrowError();

This comment has been minimized.

Copy link
@dgieselaar

dgieselaar Sep 5, 2019

Contributor

how useful is this test?

This comment has been minimized.

Copy link
@smith

smith Sep 5, 2019

Author Member

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.

// TODO: Light/Dark theme (@see https://github.com/elastic/kibana/issues/44840)
const theme = euiLightVars;

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

This comment has been minimized.

Copy link
@dgieselaar

dgieselaar Sep 5, 2019

Contributor

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

);

return (
<Item>

This comment has been minimized.

Copy link
@dgieselaar

dgieselaar Sep 5, 2019

Contributor

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

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

(iirc)

const Separator: React.FunctionComponent = () => (
<>
{' '}
<SeparatorText aria-hidden={true}>|</SeparatorText>{' '}

This comment has been minimized.

Copy link
@dgieselaar

dgieselaar Sep 5, 2019

Contributor

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.

@@ -0,0 +1,255 @@
/*

This comment has been minimized.

Copy link
@dgieselaar

dgieselaar Sep 5, 2019

Contributor

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

}) => {
let color = 'default';

if (!status) {

This comment has been minimized.

Copy link
@dgieselaar

dgieselaar Sep 5, 2019

Contributor

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;
};

const HttpInfoBadge = styled(EuiBadge)`
max-width: 250px;

This comment has been minimized.

Copy link
@dgieselaar

dgieselaar Sep 5, 2019

Contributor

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.

)}
>
<MethodText>{method}</MethodText>
</EuiToolTip>{' '}

This comment has been minimized.

Copy link
@dgieselaar

dgieselaar Sep 5, 2019

Contributor

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).

duration={transaction.transaction.duration.us}
totalDuration={totalDuration}
/>
{(isHttp || result) && <Separator />}

This comment has been minimized.

Copy link
@dgieselaar

dgieselaar Sep 5, 2019

Contributor

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.

This comment has been minimized.

Copy link
@smith

smith Sep 5, 2019

Author Member

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

@smith

This comment has been minimized.

Copy link
Member Author

commented Sep 5, 2019

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

@sqren

This comment has been minimized.

Copy link
Member

commented Sep 5, 2019

@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.

@sqren

This comment has been minimized.

Copy link
Member

commented Sep 5, 2019

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
Screen Shot 2019-08-20 at 17 33 17

Yellow for 3xx
Screen Shot 2019-08-20 at 17 33 26

Red for 4xx and 5xx
Screen Shot 2019-08-20 at 17 33 31

Screen Shot 2019-08-20 at 17 33 37

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

This comment has been minimized.

Copy link

commented Sep 6, 2019

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.

@sqren

This comment has been minimized.

Copy link
Member

commented Sep 6, 2019

Eui provides nice colors for indicating status

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

@katrin-freihofner

This comment has been minimized.

Copy link

commented Sep 6, 2019

@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.)
@sqren

This comment has been minimized.

Copy link
Member

commented Sep 6, 2019

@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

This comment has been minimized.

Copy link
Member Author

commented Sep 6, 2019

@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

This comment has been minimized.

Copy link
Member Author

commented Sep 6, 2019

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

@sqren

This comment has been minimized.

Copy link
Member

commented Sep 6, 2019

@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

This comment has been minimized.

Copy link
Member Author

commented Sep 6, 2019

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?

@smith smith force-pushed the smith:nls/43247/trace-summary branch from ccfb859 to 99099ea Sep 6, 2019

@sqren
Copy link
Member

left a comment

lgtm. just nits

) : (
`(${percentOfTraceText})`
)}
</>

This comment has been minimized.

Copy link
@sqren

sqren Sep 9, 2019

Member

nit: you can avoid the ternary and fragment like this. This makes it a little less indented and easier to read. But mostly a personal pref so feel free to change or leave as-is:

if (!isOver100) {
  return `(${percentOfTraceText})`;
}

return (
  <EuiToolTip
    content={i18n.translate(
      'xpack.apm.transactionDetails.percentOfTraceLabelExplanation',
      {
        defaultMessage:
          'The % of trace exceeds 100% because this transaction takes longer than the root transaction.'
      }
    )}
  >
    <>{percentOfTraceText}</>
  </EuiToolTip>
);
) : (
asPercent(duration, totalDuration, NOT_AVAILABLE_LABEL)
),
val: <PercentOfTrace duration={duration} totalDuration={totalDuration} />,

This comment has been minimized.

Copy link
@sqren

sqren Sep 9, 2019

Member

Good idea creating a dedicated component for this 👍

[APM] One-line trace summary
Replace the `StickyTransactionProperties` with a trace summary that puts everything on one line.

Fixes #43247.

@smith smith force-pushed the smith:nls/43247/trace-summary branch from 99099ea to 03f58bf Sep 9, 2019

@smith

This comment has been minimized.

Copy link
Member Author

commented Sep 9, 2019

Added status code text in 03f58bf.

@elasticmachine

This comment has been minimized.

Copy link
Contributor

commented Sep 9, 2019

@smith smith merged commit fda600c into elastic:master Sep 9, 2019

55 checks passed

API integration tests node scripts/functional_tests --config test/api_integration/config.js --bail --debug
Details
Browser tests yarn run grunt test:browser-ci
Details
Build kbn_tp_sample_panel_action yarn build
Details
CLA All commits in pull request signed
Details
Check core API changes node scripts/check_core_api_changes
Details
Check file casing node scripts/check_file_casing --quiet
Details
Check licenses node scripts/check_licenses --dev
Details
Firefox smoke test node scripts/functional_tests --bail --debug --kibana-install-dir /var/lib/jenkins/workspace/elastic+kibana+pull-request/JOB/kibana-firefoxSmoke/node/linux-immutable/install/kibana --include-tag smoke --config test/functional/config.firefox.js
Details
Functional tests / Group 1 yarn run grunt run:functionalTests_ciGroup1
Details
Functional tests / Group 10 yarn run grunt run:functionalTests_ciGroup10
Details
Functional tests / Group 11 yarn run grunt run:functionalTests_ciGroup11
Details
Functional tests / Group 12 yarn run grunt run:functionalTests_ciGroup12
Details
Functional tests / Group 2 yarn run grunt run:functionalTests_ciGroup2
Details
Functional tests / Group 3 yarn run grunt run:functionalTests_ciGroup3
Details
Functional tests / Group 4 yarn run grunt run:functionalTests_ciGroup4
Details
Functional tests / Group 5 yarn run grunt run:functionalTests_ciGroup5
Details
Functional tests / Group 6 yarn run grunt run:functionalTests_ciGroup6
Details
Functional tests / Group 7 yarn run grunt run:functionalTests_ciGroup7
Details
Functional tests / Group 8 yarn run grunt run:functionalTests_ciGroup8
Details
Functional tests / Group 9 yarn run grunt run:functionalTests_ciGroup9
Details
Internationalization check node scripts/i18n_check --ignore-missing
Details
Interpreter functional tests node scripts/functional_tests --config test/interpreter_functional/config.js --bail --debug --kibana-install-dir ./build/oss/kibana-8.0.0-SNAPSHOT-linux-x86_64
Details
Jest integration tests yarn run grunt test:jest_integration
Details
Jest tests yarn run grunt test:jest
Details
Kibana visual regression tests yarn run percy exec node scripts/functional_tests --debug --bail --kibana-install-dir /var/lib/jenkins/workspace/elastic+kibana+pull-request/JOB/kibana-visualRegression/node/linux-immutable/install/kibana --config test/visual_regression/config.ts
Details
Mocha tests node scripts/mocha
Details
Plugin functional tests node scripts/functional_tests --config test/plugin_functional/config.js --bail --debug --kibana-install-dir ./build/oss/kibana-8.0.0-SNAPSHOT-linux-x86_64
Details
Project tests yarn run grunt test:projects
Details
Type check node scripts/type_check
Details
TypeScript - all files belong to a TypeScript project node scripts/check_ts_projects
Details
Verify NOTICE.txt node scripts/notice --validate
Details
Verify dependency versions yarn run grunt verifyDependencyVersions
Details
X-Pack Chrome Functional tests / Group 1 node scripts/functional_tests --debug --bail --kibana-install-dir /var/lib/jenkins/workspace/elastic+kibana+pull-request/JOB/x-pack-ciGroup1/node/linux-immutable/install/kibana --include-tag ciGroup1
Details
X-Pack Chrome Functional tests / Group 10 node scripts/functional_tests --debug --bail --kibana-install-dir /var/lib/jenkins/workspace/elastic+kibana+pull-request/JOB/x-pack-ciGroup10/node/linux-immutable/install/kibana --include-tag ciGroup10
Details
X-Pack Chrome Functional tests / Group 2 node scripts/functional_tests --debug --bail --kibana-install-dir /var/lib/jenkins/workspace/elastic+kibana+pull-request/JOB/x-pack-ciGroup2/node/linux-immutable/install/kibana --include-tag ciGroup2
Details
X-Pack Chrome Functional tests / Group 3 node scripts/functional_tests --debug --bail --kibana-install-dir /var/lib/jenkins/workspace/elastic+kibana+pull-request/JOB/x-pack-ciGroup3/node/linux-immutable/install/kibana --include-tag ciGroup3
Details
X-Pack Chrome Functional tests / Group 4 node scripts/functional_tests --debug --bail --kibana-install-dir /var/lib/jenkins/workspace/elastic+kibana+pull-request/JOB/x-pack-ciGroup4/node/linux-immutable/install/kibana --include-tag ciGroup4
Details
X-Pack Chrome Functional tests / Group 5 node scripts/functional_tests --debug --bail --kibana-install-dir /var/lib/jenkins/workspace/elastic+kibana+pull-request/JOB/x-pack-ciGroup5/node/linux-immutable/install/kibana --include-tag ciGroup5
Details
X-Pack Chrome Functional tests / Group 6 node scripts/functional_tests --debug --bail --kibana-install-dir /var/lib/jenkins/workspace/elastic+kibana+pull-request/JOB/x-pack-ciGroup6/node/linux-immutable/install/kibana --include-tag ciGroup6
Details
X-Pack Chrome Functional tests / Group 7 node scripts/functional_tests --debug --bail --kibana-install-dir /var/lib/jenkins/workspace/elastic+kibana+pull-request/JOB/x-pack-ciGroup7/node/linux-immutable/install/kibana --include-tag ciGroup7
Details
X-Pack Chrome Functional tests / Group 8 node scripts/functional_tests --debug --bail --kibana-install-dir /var/lib/jenkins/workspace/elastic+kibana+pull-request/JOB/x-pack-ciGroup8/node/linux-immutable/install/kibana --include-tag ciGroup8
Details
X-Pack Chrome Functional tests / Group 9 node scripts/functional_tests --debug --bail --kibana-install-dir /var/lib/jenkins/workspace/elastic+kibana+pull-request/JOB/x-pack-ciGroup9/node/linux-immutable/install/kibana --include-tag ciGroup9
Details
X-Pack Jest node scripts/jest --ci --verbose
Details
X-Pack Mocha yarn test
Details
X-Pack SIEM cyclic dependency test node legacy/plugins/siem/scripts/check_circular_deps
Details
X-Pack firefox smoke test node scripts/functional_tests --debug --bail --kibana-install-dir /var/lib/jenkins/workspace/elastic+kibana+pull-request/JOB/x-pack-firefoxSmoke/node/linux-immutable/install/kibana --include-tag smoke --config test/functional/config.firefox.js
Details
X-Pack visual regression tests yarn run percy exec node scripts/functional_tests --debug --bail --kibana-install-dir /var/lib/jenkins/workspace/elastic+kibana+pull-request/JOB/x-pack-visualRegression/node/linux-immutable/install/kibana --config test/visual_regression/config.js
Details
elasticsearch-ci/docs Build finished.
Details
eslint node scripts/eslint --no-cache
Details
kibana-ci Build finished.
Details
percy/kibana Visual review automatically approved, no visual changes found.
Details
prbot:outdated run `node scripts/update_prs 44842` to update
prbot:release note labels
prbot:release version labels
sasslint node scripts/sasslint
Details

@smith smith deleted the smith:nls/43247/trace-summary branch Sep 9, 2019

smith added a commit to smith/kibana that referenced this pull request Sep 9, 2019
[APM] One-line trace summary (elastic#44842)
Replace the `StickyTransactionProperties` with a trace summary that puts everything on one line.

Fixes elastic#43247.
smith added a commit that referenced this pull request Sep 10, 2019
[7.x] [APM] One-line trace summary (#44842) (#45215)
Replace the `StickyTransactionProperties` with a trace summary that puts everything on one line.

Fixes #43247.
@sqren

This comment has been minimized.

Copy link
Member

commented Sep 10, 2019

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):

Screen Shot 2019-09-10 at 11 10 20

I think the contrast would be better with white:

Screen Shot 2019-09-10 at 11 10 53

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)

@sqren sqren referenced this pull request Sep 10, 2019
@cchaos

This comment has been minimized.

Copy link
Contributor

commented Sep 10, 2019

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.

jloleysens added a commit to jloleysens/kibana that referenced this pull request Sep 10, 2019
Merge branch 'master' of github.com:elastic/kibana into chore/console…
…-to-np-ready

* 'master' of github.com:elastic/kibana: (138 commits)
  [Canvas] i18n work on workpad header (and a few header CTAs) and convert to typescript (elastic#44943)
  update close/delete system index modals (elastic#45037)
  TS return type of createIndexPatternSelect (elastic#45107)
  [ML] Fix focus chart updating. (elastic#45146)
  [ML] Data frame transform: Fix progress in wizard create step. (elastic#45116)
  [Graph] Re-enable functional test (elastic#44683)
  [SIEM] unique table id for each top talkers table (elastic#45014)
  [SIEM] ip details heading draggable (elastic#45179)
  [Maps][File upload] Set complete on index pattern creation (elastic#44423)
  [Maps] unmount map embeddable component on destroy (elastic#45183)
  [SIEM] Adds error toasts to MapEmbeddable component (elastic#45088)
  fix redirect to maintain search query string (elastic#45184)
  [APM] One-line trace summary (elastic#44842)
  [Infra UI] Display non-metric details on Node Detail page (elastic#43551)
  [Maps][File upload] Removing bbox from parsed file pending upstream lib fix (elastic#45194)
  [Logs UI] Improve live streaming behavior when scrolling (elastic#44923)
  [APM] Fix indefinite loading state in agent settings for unauthorized user roles (elastic#44970)
  [Reporting] Rewrite addForceNowQuerystring to getFullUrls (elastic#44851)
  [Reporting/ESQueue] Improve logging of doc-update events (elastic#45077)
  [Reporting] Make screenshot capture less noisy by default (elastic#45185)
  ...
@smith

This comment has been minimized.

Copy link
Member Author

commented Sep 10, 2019

@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

This comment has been minimized.

Copy link
Contributor

commented Sep 10, 2019

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

This comment has been minimized.

Copy link
Member Author

commented Sep 10, 2019

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

This comment has been minimized.

Copy link

commented Sep 11, 2019

@smith I guess this would work better. 👍

@sqren

This comment has been minimized.

Copy link
Member

commented Sep 11, 2019

@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

This comment has been minimized.

Copy link

commented Sep 11, 2019

@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.

@sqren

This comment has been minimized.

Copy link
Member

commented Sep 11, 2019

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

@sqren

This comment has been minimized.

Copy link
Member

commented Sep 11, 2019

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

This comment has been minimized.

Copy link

commented Sep 11, 2019

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

@sqren

This comment has been minimized.

Copy link
Member

commented Sep 11, 2019

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

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

@smith

This comment has been minimized.

Copy link
Member Author

commented Sep 11, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.