Repository navigation
[Tunnel Options] Allow Configuration Based on Event Category #13520
Description
Problem Statement
(related to this comment getsentry/sentry#65180 (comment))
When tunneling events to your own infrastructure before sending them to Sentry you effectively pay for the event 3 times:
- Ingesting it in your tunnel route
- Egress to Sentry
- Ingesting it in Sentry
This is probably acceptable in most cases but certain environments make this behaviour very cost prohibitive (see https://sentry.zendesk.com/agent/tickets/107289)
Solution Brainstorm
I would like to be able to pass an option to my tunnel config that allows me to tunnel certain event types but not others.
Examples:
- I am using Release health and want to ensure that Session data is as complete as possible but I am okay with dropping the error event payloads
- I am using Tracing and Profiling - Profiles are much heavier and require span data to be ingested. I am okay with dropping profiles but tunneling spans.
- I am using the User Feedback widget. Sentry fails transparently in all cases when errors cannot be submitted but I want to ensure that envelopes related to User Feedback are submitted
Activity
souredoutlook commentedon Aug 29, 2024
Following up with a conversation about this with @bruno-garcia just now. Specifically in the case of User Feedback submission failures it may be more beneficial to simply flip a flag the first time the transport fails to send an event and then render a different widget or a fallback message.
Lms24 commentedon Aug 30, 2024
We blacklogged this for the moment but I had some thoughts.
Please correct me if I'm wrong but I think the general ask here is to use the tunnel as a fallback (i.e. try sending it directly first and only then send via
tunnel), right?I get the idea but this sounds hard to get right and might not always be what users want.
As of today, as soon as
tunnelis specificed, the SDK always sends events to the tunnel, and never to the specified URL in the DSN directly. Changing this is a massive potential behaviour break because users are for sure relying on this behaviour in one way or another.Let's assume we'd do this, we'd need to be able to know with certainty why we fall back to the tunnel. Event sending can fail for various reasons. Should we simply always fall back to the tunnel?
Side note: Users are free to implement their tunnel proxy however they like. Theoretically, they could filter or re-sample out any type of event as soon as the tunnel proxy handles an incoming request. The noteable exception here is the NextJS SDK
tunnelRouteoption, where we add the proxy for users. Here I don't think users can configure anything but they are always free to fall back to usingtunnelinstead.AbhiPrasad commentedon Dec 11, 2024
This is going to happen as part of #14248 - going to track this there so closing this issue.