-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
Open a new APM transaction for every meaningful page instead of every currentAppId$
#114843
Comments
Pinging @elastic/kibana-core (Team:Core) |
Atm the kibana/src/core/public/apm_system.ts Lines 60 to 68 in 4681a80
Having a better granularity would require to move that to the Now, Technically: we need to hook into something. We could eventually hook into 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 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 kibana/src/core/public/application/application_service.tsx Lines 147 to 152 in 854e0d4
Functionally I'm honestly not sure to see why Now, I agree that Curious to see what the other team members think about this. |
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. |
Partially addressed by #124996 |
AFAIK, in Core we use kibana/src/core/public/application/ui/app_router.tsx Lines 50 to 91 in 04d5762
I wonder if we could use the |
@lizozom WDYT? Do you know if using |
Currently
route-change
transactions are started everytime thecurrentAppId$
changes and are closed uponlargestContentPaint
. 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 aTrackApplicationView
).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.
The text was updated successfully, but these errors were encountered: