Open a new APM transaction for every meaningful page instead of every currentAppId$

[lizozom]

Currently route-change transactions are started everytime the currentAppId$ changes and are closed upon largestContentPaint. This diagram illustrates it - You can see that navigations within the app don't create an APM transaction at all.

We want to change the integration in such a way that a new transaction is started every time a page changes. This would require a way of letting apps communicate page changes. @Bamieh mentioned the TrackApplicationView component, but that one may open multiple view contexts one withing the other (for example a flyout within a page can use a TrackApplicationView).

The end result should look something like this (includes changing page-load behavior as described here:

Once we have this, we will proceed to track individual events within each transaction.

[elasticmachine]

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

[pgayvallet]

Atm the route-change transaction is handled outside of the application service, directly in apm_system

kibana/src/core/public/apm_system.ts

Lines 60 to 68 in 4681a80

	start.application.currentAppId$.subscribe((appId) => {
	const apmInstance = (window as any).elasticApm;
	if (appId && apmInstance && typeof apmInstance.startTransaction === 'function') {
	apmInstance.startTransaction(`/app/${appId}`, 'route-change', {
	managed: true,
	canReuse: true,
	});
	}
	});

Having a better granularity would require to move that to the application service to have better control over it.

Now,

Technically:

we need to hook into something. We could eventually hook into navigateToApp, but most intra-app navigations are NOT using this, and are directly using their nested router, meaning that we would miss all of those, so this is not an option.

we could listen to the root history itself, but this would be extremely verbose. e.g a parameter change would cause a new event to fire. Plus, if we hook into the history, we would be very low level and would not have the info about the current app. We would just have the path and state of the current location.

Plugging into the mounted app wrapper would not work either, as an application if not re-mounted when their internal path changes. And we don't have the path information here (even if we could probably find a way to access it somehow).

kibana/src/core/public/application/application_service.tsx

Lines 147 to 152 in 854e0d4

	const wrapMount = (plugin: PluginOpaqueId, app: App<any>): AppMount => {
	return async (params) => {
	this.currentAppId$.next(app.id);
	return app.mount(params);
	};
	};

Functionally

I'm honestly not sure to see why core should manage internal application transactions. I think applications may want different level of granularity in their transactions, and I doubt we could provide something that would suit everyone?

Now, I agree that route-change is misleading. But I'm not sure we could (or should) do anything else at core's level than rename it to app-change?

Curious to see what the other team members think about this.

[lizozom]

I strongly agree @pgayvallet - I don't think this core should manage internal application transactions..

Instead, for example, we could have some observable (it can be part of the reporting package we want to create) to allow apps easily emit page changes on it.

There are multiple technical solutions, but eventually, in the context of event reporting (be it to APM, fullstory or telemetry-next), we still need a reliable way to set the start point of a well-defined page visit.

[lizozom]

Partially addressed by #124996

[afharo]

AFAIK, in Core we use react-router-dom's Router - Switch - Route to route to different apps:

kibana/src/core/public/application/ui/app_router.tsx

Lines 50 to 91 in 04d5762

	return (
	<Router history={history}>
	<Switch>
	{[...mounters].map(([appId, mounter]) => (
	<Route
	key={mounter.appRoute}
	path={mounter.appRoute}
	exact={mounter.exactRoute}
	render={({ match: { path } }) => (
	<AppContainer
	appPath={path}
	appStatus={appStatuses.get(appId) ?? AppStatus.inaccessible}
	createScopedHistory={createScopedHistory}
	{...{ appId, mounter, setAppLeaveHandler, setAppActionMenu, setIsMounting, theme$ }}
	/>
	)}
	/>
	))}
	{/* handler for legacy apps and used as a catch-all to display 404 page on not existing /app/appId apps*/}
	<Route
	path="/app/:appId"
	render={({
	match: {
	params: { appId },
	url,
	},
	}: RouteComponentProps<Params>) => {
	// the id/mounter retrieval can be removed once #76348 is addressed
	const [id, mounter] = mounters.has(appId) ? [appId, mounters.get(appId)] : [];
	return (
	<AppContainer
	appPath={url}
	appId={id ?? appId}
	appStatus={appStatuses.get(appId) ?? AppStatus.inaccessible}
	createScopedHistory={createScopedHistory}
	{...{ mounter, setAppLeaveHandler, setAppActionMenu, setIsMounting, theme$ }}
	/>
	);
	}}
	/>
	</Switch>
	</Router>

I wonder if we could use the ApmRoute component exposed by @elastic/apm-rum-react as a direct replacement of Route to get some "Application Changed" metrics "for free". What do you think?

[pgayvallet]

@lizozom WDYT? Do you know if using ApmRoute would provide more value that what we're manually doing in src/core/public/apm_system.ts ?