Add errorsSampler for Sentry config to match functionality with tracesSampler

[JohnDuncanScott]

Problem Statement

Traces can be adjusted with a global sample rate or a tracesSampler for more fine-grained sampling (see https://docs.sentry.io/platforms/javascript/configuration/sampling/). Errors have a global sample rate but no sampler option. Given captureMessage uses the errors budget in Sentry, it is useful to have separate sample rates for, as an example, captureMessage vs captureException. It is not possible to do this with Sentry currently.

Solution Brainstorm

Introduces an errorsSampler hook that works the same way as tracesSampler.

[Lms24]

Hi @JohnDuncanScott, thanks for writing in!

Have you tried using the beforeSend hook? This callback allows you to filter your events and to decide which should be sent/discarded.

Let me know if this works for you.

[JohnDuncanScott]

That's not the same as a sample rate. We've used that for other things successfully but this is about sample rates, not turning things on or off.

[Lms24]

I might lack some context of what exactly you're trying to achieve but sticking to your example (captureMessage vs captureException), you could filter on the type of event and decide based on different probabilities per event type if you want to send the event or not.

[JohnDuncanScott]

You could apply the same logic to not having tracesSampler and just doing probability logic in beforeSend, yet the tracesSampler exists. The point is it exists for traces but not for errors. There should be parity here. Of course you can almost always fix a missing feature by adding your own custom code :). Get Outlook for Android<https://aka.ms/ghei36>

…

________________________________ From: Lukas Stracke ***@***.***> Sent: Monday, March 28, 2022 10:01:58 AM To: getsentry/sentry-javascript ***@***.***> Cc: Duncan Scott ***@***.***>; Mention ***@***.***> Subject: Re: [getsentry/sentry-javascript] Add errorsSampler for Sentry config to match functionality with tracesSampler (Issue #4800) I might lack some context of what exactly you're trying to achieve but sticking to your example (captureMessage vs captureException), you could filter on the type of event and decide based on different probabilities per event type if you want to send the event or not. — Reply to this email directly, view it on GitHub<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgetsentry%2Fsentry-javascript%2Fissues%2F4800%23issuecomment-1080381065&data=04%7C01%7C%7Cd7a97dedd01340804df908da10999df8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637840549226316468%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=TSv20%2BRVoEcKvxX2ujkY50CPqO9gBCa0cQ76flng6P4%3D&reserved=0>, or unsubscribe<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAEO7MT7VBLTXZJ64UGN2VZDVCFYQNANCNFSM5R2KND5Q&data=04%7C01%7C%7Cd7a97dedd01340804df908da10999df8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637840549226316468%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=TL8VTQOPisYtAWA%2FKphGP9P5mrPSGlPX%2BxJOJKV6fI8%3D&reserved=0>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[Lms24]

Thanks for the reply. I discussed this with the team and for now we're going to stick with beforeSend for such cases. The thing is, something like an errorSampler would essentially be syntactic sugar around beforeSend. Meaning, everything that this function would do, can also be done in beforeSend. While I agree, that it would provide parity with transactions/tracing from a high-level perspective, it is not necessary to have it (also, it would increase bundle size, which we are currently trying to reduce).

For tracing/transactions, that's another story. They do not go through beforeSend but it is decided earlier in the process if a transaction is sent or not. That's also the reason why tracesSpampler is available - because it cannot be done in beforeSend.

I hope this explanation helps to understand our point of view. Please feel free though to make other improvement suggestions or feature requests in the future. Feedback is always appreciated :)

[AbhiPrasad]

Hey we will be closing this issue given as you can accomplish this with beforeSend, or writing custom event processors. We are currently not looking to expand the Sentry public API with an errorsSampler. We might re-visit this in the future. Thanks for the feedback!