-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Open
Description
Description
ref https://github.com/getsentry/projects/issues/385 and https://www.notion.so/sentry/Project-Improve-Tunneling-1368b10e4b5d80b38557c66fbcf6d8a1
Right now there is a singular option for tunnel
in Sentry.init
that you pass in to enable tunneling. This makes setup very simple, which is a positive, but it has drawbacks.
- Complicates SDK internals because we end up passing tunnel config everywhere
- No finely grained control over what gets tunneled (a user may decide to tunnel only errors so that there is less load on their proxy infrastructure they set up). This came up in [Tunnel Options] Allow Configuration Based on Event CategoryΒ #13520.
- We always send to tunnel endpoints, even when end-users don't have a adblocker set up
- There is a very slight bundle size increase (but not that important): chore: Check bundle size of removing tunnelΒ #14223
To address this, we should improve the tunneling API within the Sentry SDKs
Investigate
- Do ad blockers block based on envelope payload? If they do, we might need to investigate alternate formats.
Explore
- Explore alternate ways to configure tunneling in the SDK. Use
tunnel
transport rather than top leveltunnel
optionΒ #14152 raises a custom transport, but perhaps an integration also works well.
Implement
- Can we detect in our SDKs if an ad blocker blocks our requests? If yes, we could try to send the data first directly to Sentry, and if it doesn't work, use the tunnel.
With that approach, we take most of our load from our user's infrastructure. Furthermore, we could identify how much data comes through the tunnel and how much directly via Sentry when adding metadata to the tunneled envelopes. We could also share that data with our users.
whl83111 and betaorbust
Metadata
Metadata
Assignees
Labels
No labels
Projects
Status
No status