OpenNeo/impress-2020
OpenNeo/impress-2020
1
0
Fork 0
Code Pull requests Activity

Stop sending client-side nav transaction to Sentry

Browse source 
Oops, we hit our Sentry transaction limit after 3 days!

This is in part because we selected a 100% sample rate to start, but also because our app has a lot of client-side navs that don't represent real navigation, and are just to update the state in the URL.

I'm not using most of Sentry's performance tracing features, though! I don't have logging that helps us understand once the page is really done, and I'm only really able to use Web Vitals right now - which only applies to first-time pageload events, anyway. So, that's now all we track!
This commit is contained in:
Emi Matchu 2021-01-18 16:31:02 -08:00
parent b39914976b
commit 8aa644a031
1 changed files with 12 additions and 6 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

18
src/app/App.js
View file

@ -75,17 +75,23 @@ Sentry.init({
...context, ...context,
// Assume any path segment starting with a digit is an ID, and replace // Assume any path segment starting with a digit is an ID, and replace
// it with `:id`. This will help group related routes in Sentry stats. // it with `:id`. This will help group related routes in Sentry stats.
// NOTE: I'm a bit uncertain about the timing on this? This seems to // NOTE: I'm a bit uncertain about the timing on this for tracking
// work on initial pageload, but I feel like this won't help for // client-side navs... but we now only track first-time
// describing the page we're navigating _to_... but maybe that's // pageloads, and it definitely works correctly for them!
// okay in practice? I'm just following the Sentry docs.
name: window.location.pathname.replaceAll(/\/[0-9][^/]*/g, "/:id"), name: window.location.pathname.replaceAll(/\/[0-9][^/]*/g, "/:id"),
}), }),
// We have a _lot_ of location changes that don't actually signify useful
// navigations, like in the wardrobe page. It could be useful to trace
// them with better filtering someday, but frankly we don't use the perf
// features besides Web Vitals right now, and those only get tracked on
// first-time pageloads, anyway. So, don't track client-side navs!
startTransactionOnLocationChange: false,
}), }),
], ],
// I'm figuring our traffic is low enough that 100% sample rate is fine. // Since we're only tracking first-page loads and not navigations, 100%
// Let's see if we hit any usage limits! // sampling isn't actually so much! Tune down if it becomes a problem, tho.
tracesSampleRate: 1.0, tracesSampleRate: 1.0,
}); });