[Security Solution] Propagate execution context

[xcrzx]

Resolves: #126799
Related to: #129324

Summary

1. Utilized useExecutionContext in Security Solution to ensure all outgoing requests (search, saved objects) are correctly traced back to a page and an entity (in ES, APM, and Fullstory). Security Solution transactions are now properly labelled in APM:

2. Added more descriptive names to the route-change transactions, now they contain destination page path, likesecuritySolutionUI /hosts/:host/anomalies:
   

   Previously those transactions looked like this:
   

How to test this PR

See the #124996 to make sure data is sent properly to APM.

[elasticmachine]

Pinging @elastic/kibana-core (Team:Core)

[elasticmachine]

Pinging @elastic/security-solution (Team: SecuritySolution)

[elasticmachine]

Pinging @elastic/security-detections-response (Team:Detections and Resp)

[rudolf]

I wonder if we can't go one step further and get normalized paths into core / the default execution context. This feels like something all teams can benefit from.

[rudolf]

@lizozom @elastic/kibana-core

I really like what @xcrzx did here and I think in many cases the path template like dashboards/edit/:id is more useful than url. Maybe we can collect it as part of the default values for the execution context.

[pgayvallet]

I like it too, and would love to have it be integrated into Core, but given 1. that our routing system is agnostic and don't know about the underlying app's routing system or structure, and 2. the code that was added in the PR in normalizePath, I'm not sure how we could make this generic/automatic?

[xcrzx]

Yea, I was also thinking about a more generic solution. Probably, it would require wrapping the Route component from react-routing-dom and exporting it from Core. Something like this:

import { useExecutionContext } from '@kbn/kibana-react-plugin/public';
import { Route, useRouteMatch } from 'react-router-dom';

export const WrappedRoute = ({ children, ...props }) => {
  return (
    <Route {...props}>
      <MatchPropagator />
      {children}
    </Route>
  );
};

const MatchPropagator = () => {
  const match = useRouteMatch();
  useExecutionContext({
    page: match.path,
  });

  return null;
};

That way, all solutions that use WrappedRoute in place of Route will have router paths automatically propagated. But there could be issues with that approach:

• All solutions will be tied to react-router. But that is probably fine, as I don't see any other routers in our repository.
• It is unclear what path will be propagated if there are many matches on a page. The one from the last rendered Route? But that is probably worth exploring and building a PoC.

[vitaliidm]

It is unclear what path will be propagated if there are many matches on a page. The one from the last rendered Route? But that is probably worth exploring and building a PoC.

It's definitely worth exploring

[pgayvallet]

Probably, it would require wrapping the Route component from react-routing-dom and exporting it from Core

Core is meant to be agnostic, we won't expose anything react-related from it. But it can be exposed from the kbn-react package/plugin the same way.

That aside, I really like the idea.

[lukeelmers]

cc @elastic/shared-ux for input - they own the kibana_react plugin

[pgayvallet]

I'm not a big fan of re-exporting library exports from plugins/packages, but I see the value here for consistency (importing everything router-related from the same location) and for future-proofing (e.g if we need to also modify the Router component at some point), so I think I'm fine with it. But as Luke said, let's see what @elastic/shared-ux thinks about it

I also agree that we do want to move those things to their dedicated package at some point (which is atm not possible given the custom Route component requires types from kibana_react/Core)

[majagrubic]

Thanx for tagging us. We're in the process of migrating to a package architecture and deprecating kibana_react. So creating a separate package is definitely a way to go, and I would suggest doing it sooner rather than later. Please note though that we have a naming convention in place, so it would need to be nested under shared-ux. I also don't like re-exporting exports from other packages; since we're moving to a package-oriented architecture, plugins will be importing things from multiple packages, I don't really see a problem there. Actually, I think the alternative is even worse: creating two of the same, so some consumers will import from react-router, the others from our package.
Happy to chat offline further if you need help getting started on a package.

[pgayvallet]

@majagrubic the new Route component relies on the useKibana hook and on the executionContext types from Core, moving it to a package now seems difficult? (see https://github.com/elastic/kibana/pull/131805/files#diff-dcbcc6e829e4d48eb4efd34901aea43227549d42e62b1e5fbeb6eb24fc8ed1d3 and https://github.com/elastic/kibana/pull/131805/files#diff-e3c7f3a09f89cd016ae74b17148a26d9414d6dc3f18c78ee18fb2960f3247899)

[xcrzx]

Sooo, we've synced with @majagrubic and agreed that extracting the new Route component to a package is out of the scope of this PR. Especially considering that we want the changes that affect Security Solution to be merged before FF (May 24), reducing the scope of changes would make sense. So in the first iteration, we're exporting only Route from @kbn/kibana-react-plugin/public and replacing Route components only in Security Solution and related plugins.

After FF, we will extract the Route component with other React router stuff to a separate package, as discussed above, and use it inside all other solutions.

UPD: created a task where the rest of work could be tracked #132629

[lizozom]

Chatted with @xcrzx today about this approach: The final decidion should be made with the @elastic/kibana-core team, but personally I'm in favor of this approach, especially if url params get JSON.stringified into the id field as well.

If we do end up doing this, lets remove the existing instances of useExecutionContext from code and close other execution context issues.

Thanks @xcrzx for taking this on!

[majagrubic]

kibana_react changes look good. Two minor questions/comments and then it's good to go

[majagrubic]

Why this change now?

[xcrzx]

To match the executionContext type returned from useKibana().services, it's ExecutionContextSetup | undefined. I believe it definitely could be undefined in some cases, so it's better to handle that.

[rudolf]

Core changes lgtm

[vitaliidm]

rules detections area changes LGTM

[majagrubic]

shared-ux changes look good. code review only, haven't tested it.

[marshallmain]

Alerts Area changes LGTM

[gmmorris]

LGTM for ResponseOps changes

[janmonschke]

👍

[machadoum]

security-threat-hunting-explore changes LGTM

[kibana-ci]

💛 Build succeeded, but was flaky

• Buildkite Build
• Commit: cc84a20
• Storybooks Preview
• Webpack Bundle Analyzer

Failed CI Steps

• Jest Tests #5

Test Failures

• [job] [logs] Jest Tests #5 / index actions should be able to clear an index's cache

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
kibanaReact	316	318	+2

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id	before	after	diff
kibanaReact	212	213	+1

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
cases	300.7KB	300.7KB	+11.0B
kibanaReact	209.6KB	209.6KB	+2.0B
securitySolution	5.0MB	5.0MB	+3.0B
total			+16.0B

Public APIs missing exports

Total count of every type that is part of your API that should be exported but is not. This will cause broken links in the API documentation system. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats exports for more detailed information.

id	before	after	diff
kibana	343	344	+1

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
core	300.7KB	301.0KB	+339.0B
kibanaReact	61.0KB	61.9KB	+897.0B
total			+1.2KB

Unknown metric groups

API count

id	before	after	diff
kibanaReact	248	250	+2

History

• 💚 Build #46423 succeeded d447255816a6626591e1621044acd9ccfe3f620d
• 💔 Build #46375 failed 3cf8861ee00099d9122d86b1dee90374b750b5ed
• 💔 Build #46180 failed 229682f0ca355d64060cd36bad9cf9222edc157b
• 💔 Build #46129 failed f474ac9a50f0427137649beda06f5dee8d3d6da4

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

cc @xcrzx

[nkhristinin]

LGTM!