getsentry / getsentry/sentry

events filtration on sentry side (ie server-side analogue of sample rate)

Open
#70,314 3 comments 4 reactions 0 assignees View on GitHub
Feature
Dominant language
Python
Stars
44.8k
Forks
4.9k
Avg merge
22h 21m
Merged PRs (30d)
586

Description

### Problem Statement

The main purpose of the sentry is to capture application errors with some contextual info that will allow us to solve the problem. But do we really need all error events to understand the context?

### Solution Brainstorm

By setting up `sample_rate` on the application level, we will limit the number of events sent to the sentry. But by doing so we might skip some important rare issues. So to achieve low numbers of unnecessary events in sentry but also capture rare problems we need to always send the first occurrence of an issue and filter out some percent of the events that follow.

We can implement this in two ways:
- client-side: store events in some temporary storage to check if they ever occurred.
- cumbersome to implement in many projects
- server-side: check an event before ingestion: if it has an issue - apply sample rate filtration, if it doesn't have an issue - save.
- The downside of straightforward server-side implementation - ingestion will be noticeably slower. With preloaded fingerprints or by using some fast key-value storage we can achieve some speedup.
- some cronjob that will remove unnecessary events from DBs every day.
- easiest solution, kind of improved version of the `cleanup` command

### Product Area

Ingestion and Filtering

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.