Description
Problem Statement
Projects with a lot of traffic tend to be a lot more expensive to integrate with Sentry because during error conditions there will be many times more errors sent. Roughly speaking, there's a linear correlation between traffic and $ cost for Sentry errors. Of course there is sampling to reduce this cost, but then you lose critical information because errors that happen at a lower rate than the sample rate could be cut out if other errors are happening at a high frequency.
One could argue that if there are errors happening at high frequency, then they should be addressed, deleted or filtered. But in my experience that's not reasonable - frontend projects with many users will frequently get into this state and by the time some thought has been put into mitigation you may have already exhausted many wasted $$ or missed a load of new errors that were sampled out.
Why can't there be a sample rate per event fingerprint? I understand that would still incur higher costs for high traffic projects (for example, you'll need to store those fingerprints somewhere) but the cost-errorrate relationship would not be linear and you'd barely lose any functionality by applying the sampling. You could even continue counting the errors correctly but not put the full error event information into the system.
Solution Brainstorm
- Switch in the UI for turning on sampling by error fingerprint. Select a sample rate.
- When switched on, server will apply fingerprint logic to the error and check against a counter in a key:value store to check whether it should be sampled out.
- (optionally) Add the timestamp to the error log without any detailed info (adding to the cost).