Repository navigation
Improve paramaterization of transaction names #5342
Description
Activity
Always happy to refine/discuss this. Since this became a very important issue, we should sync with everyone here who has context on how transaction names/parameterization/routing instrumentation currently works
Reacted by Steven Eubank- changed the title
[-](draft)Re-visit transactions name capturing[/-][+](draft)Re-visit transaction name capturing[/+]on Jul 7, 2022 - changed the title
[-](draft)Re-visit transaction name capturing[/-][+]Improve parametariaztion of transaction names[/+]on Jul 7, 2022 - changed the title
[-]Improve parametariaztion of transaction names[/-][+]Improve paramaterization of transaction names[/+]on Jul 8, 2022 Apologies if there is a better place for me to ask about this, but I have been unable to get parameterization to work with react-router v6.
Here are some excerpts of what I believe to be the relevant code:
Sentry.init({ ... integrations: [ new BrowserTracing({ routingInstrumentation: Sentry.reactRouterV6Instrumentation( useEffect, useLocation, useNavigationType, createRoutesFromChildren, matchRoutes, ), }), ], }); const SentryRoutes = Sentry.withSentryReactRouterV6Routing(Routes); const MyRoutes = () => { return ( <SentryRoutes> <Route index element={<Navigate to="/projects" />} /> <Route path="/account" element={<AccountPage />} /> <Route path="/projects"> <Route index element={<ProjectBrowser />} /> <Route path=":projectId" element={<ProjectPage />}> <Route index element={<ProjectPageRoot />} /> <Route element={<EditorPage />}> <Route path="views/:viewId" element={<ViewCanvas />} /> <Route path="spaces/:spaceId" element={<SpaceCanvas />} /> </Route> </Route> </Route> <Route path="*" element={<NoMatchPage />} /> </SentryRoutes> ); }; export default MyRoutes
As far as I can tell, I'm not doing anything unusual, except possibly the use of react router's Outlets and Layout Routes.
With this configuration I would expect to see a single transaction for
/projects/*/views/*, but instead I'm seeing separate transactions for each individual page.Is there something obvious that I'm doing wrong here, or does the sentry integration not support parameterization with this usage?
- added a commit that references this issue
on Jul 26, 2022 Hi @jamesbvaughan, would you mind opening a dedicated issue for this? Makes it easier to track this for us.
cc @AbhiPrasad maybe you have a quick idea?Reacted by James VaughanI've created #5513 to track my issue separately. Thanks!
This issue has gone three weeks without activity. In another week, I will close it.
But! If you comment or otherwise update it, I will reset the clock, and if you label it
Status: BacklogorStatus: In Progress, I will leave it alone ... forever!
"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀
Tracking the nextjs and remaining issues in #5505
Describe the idea
We need to revisit how the JS SDK captures transactions (URL routes) and sends them to sentry.
Reasons for doing this and things we need to consider:
Because
Best effort has been decent so far, but the fallback to unparameterized or whole URL maybe sub-optimal.
Examples:
{"transaction": "/users/{username}", "transaction_source": "route"}{"transaction": "/users/123235", "transaction_source": "uri"}{"transaction": "my_transaction_name", "transaction_source": "custom"}Requirement:
what should be sent and where?
baggage header
sentry-transactiontraceEnvelope Headertransaction(string)Possible implementation
There's a couple of things we can do or at least check:
Existing Routing Instrumentations with parameterization
As listed in #5345, we have a lot of popular routers covered with routing instrumentations. However, we might be able to improve paramenterizations in some of them. Hence, for each instrumentation
Existing Routing Instrumentations without parameterization
TODO: Check to which routers this applies
There are some routing instrumentations that don't parameterize currently.
TBD: Approximative Parameterization
This has been discussed quite a bit in the past but given that we have to make our best effort for parameterization, let's revisit this topic. The idea is seemingly simple: We could try to add a mechanism that takes a raw URL and tries to guess parts of that URL that might be parameters (e.g. IDs, tokens, etc). The mechanism would then replace these parts with a generic param placeholder.
Example:
/users/1235/credentials==>users/:id/credentialsThere are a lot of possible issues with this because obviously, there are going to be loads of edge cases, where this approximation might be off or miss parameters completely.
Why is this challenging?
Places to improve parameterization