Skip to content

fix transaction quota management content #5114

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Jun 8, 2022
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 8 additions & 8 deletions src/docs/product/accounts/quotas/index.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -39,11 +39,11 @@ Sentry completes a thorough evaluation of each event to determine if it counts t

4. **Event repetition**

Event repetition only applies to error events, not transactions or attachments. The following rules apply for event repetition and your quota:
Event repetition only applies to error events, not transactions or attachments. The following rules apply for event repetition and your quota:

- If you have chosen to "Delete & Discard" an issue, then _future_ error events with the same fingerprint do not count toward your quota.
- If you previously resolved an issue, a new error event counts toward your quota because it may represent a regression in your code.
- If you have chosen to ignore alerts about error events with the same fingerprint, a new event counts toward your quota because the event is still occurring. Learn more in [Inbound Filters](#inbound-data-filters).
- If you have chosen to "Delete & Discard" an issue, then _future_ error events with the same fingerprint do not count toward your quota.
- If you previously resolved an issue, a new error event counts toward your quota because it may represent a regression in your code.
- If you have chosen to ignore alerts about error events with the same fingerprint, a new event counts toward your quota because the event is still occurring. Learn more in [Inbound Filters](#inbound-data-filters).

5. **Spike protection**

Expand All @@ -57,7 +57,7 @@ In addition, depending on your project’s configuration and the plan you subscr

7. **Inbound filters**

If any inbound filter is set for a type of error event, and your subscription allows, the event will not be counted. Learn more in the [Inbound Filters section of our error quota management guide](/product/accounts/quotas/manage-event-stream-guide/#3-inbound-data-filters) or in [Inbound Data Filter](#inbound-data-filters). This does not apply to transactions or attachments.
If any inbound filter is set for a type of event or attachment, and your subscription allows, the event or attachment won't be counted. Learn more in [Inbound Data Filters](#inbound-data-filters).

After these checks are processed, the event counts toward your quota. It is accepted into Sentry, where it persists and is stored.

Expand Down Expand Up @@ -194,7 +194,7 @@ Per-key rate limits allow you to set the maximum volume of error events a key wi

For example, you may have a project in production that generates a lot of noise. A rate limit allows you to set the maximum amount of data to “500 events per minute”. Additionally, you can create a second key for the same project for your staging environment, which is unlimited, ensuring your QA process is still untouched.

To set up rate limits, navigate to **[Project] > Settings > Client Keys** and click "Configure"**". Select an individual key or create a new one, then you’ll be able to define a rate limit as well as view a breakdown of events received by that key. For additional information and examples, see [Rate Limiting in our guide to managing your error quota](/product/accounts/quotas/manage-event-stream-guide/#6-rate-limiting).
To set up rate limits, navigate to **[Project] > Settings > Client Keys** and click "Configure"\*\*". Select an individual key or create a new one, then you’ll be able to define a rate limit as well as view a breakdown of events received by that key. For additional information and examples, see [Rate Limiting in our guide to managing your error quota](/product/accounts/quotas/manage-event-stream-guide/#6-rate-limiting).

<Note>

Expand All @@ -220,7 +220,7 @@ Inbound filters include:
- From specific release versions of your code
- From certain IP addresses.

Explore these by navigating to **[Project] > Settings > Inbound Filters**. Commonly-set filters are discussed here for your quick reference. For additional information and examples, see [Inbound Data Filters in our guide to managing your error quota](/product/accounts/quotas/manage-event-stream-guide/#3-inbound-data-filters). Commonly-set filters include:
Explore these by navigating to **[Project] > Settings > Inbound Filters**.

### IP Filters

Expand Down Expand Up @@ -290,7 +290,7 @@ The 24-hour window ends at the beginning of the current hour, not at the current

This means if you experience a spike, we'll temporarily protect you, but if the increase in volume is sustained, the spike protection limit will gradually **increase until Sentry accepts all events**.

For example, in the last 24 hours, your organization has been receiving, on average, 10 events per minute (after any inbound filters have been applied). That means your current per-minute limit is 6 * 10 or 60 events. There have been no spikes in that time, so spike control is "inactive". Something breaks, and in the next minute, your organization sends Sentry 100 events. When we see the 61st event, three things happen:
For example, in the last 24 hours, your organization has been receiving, on average, 10 events per minute (after any inbound filters have been applied). That means your current per-minute limit is 6 \* 10 or 60 events. There have been no spikes in that time, so spike control is "inactive". Something breaks, and in the next minute, your organization sends Sentry 100 events. When we see the 61st event, three things happen:

1. Spike protection becomes "active".

Expand Down
12 changes: 8 additions & 4 deletions src/docs/product/accounts/quotas/manage-transaction-quota.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -7,13 +7,17 @@ description: "Learn how to use the tools Sentry provides to control the type and

In most cases, sending all [transaction](/product/performance/transaction-summary/#what-is-a-transaction) events to Sentry would generate more performance data than you might find useful and might use up your transactions quota too quickly. Sentry provides tools to control the _type_ and _amount_ of transactions that are monitored. This allows you to have transaction data that's actionable and meaningful, and to manage your quota. Applying the proper SDK configuration is an iterative and on-going process, but these tips will show you how to best use Sentry's tools to get the most out of your transaction events.

## 1. SDK Filtering: beforeSend
## 1. SDK Configuration: Tracing Options {#2-sdk-configuration-tracing-options}

All Sentry SDKs support the `beforeSend` callback method. Once implemented, the method is invoked when the SDK captures an event, right before sending it to your Sentry account. It receives the event object as a parameter, so you can use that to modify the event's data or drop it completely (by returning `null`) based on your custom logic and the data available on the event, like _tags_, _environment_, _release version_, and so on. Learn more in [Filtering Events](/platform-redirect/?next=/configuration/filtering/).
When you configure your the SDK, you can control the number of transactions that are sent to Sentry by setting the [tracing options](/platform-redirect/?next=/configuration/options/%23tracing-options). You can also set up [custom instrumentation](/platform-redirect/?next=/performance/instrumentation/custom-instrumentation/) for performance monitoring to capture certain types of transactions.

## 2. SDK Configuration: Tracing Options
## 2. Inbound Data Filters

When you configure your the SDK, you can control the number of transactions that are sent to Sentry by setting the [tracing options](/platform-redirect/?next=/configuration/options/%23tracing-options). You can also set up [custom instrumentation](/platform-redirect/?next=/performance/instrumentation/custom-instrumentation/) for performance monitoring to capture certain types of transactions.
While SDK configuration requires changes to your source code and depends on your next deployment, server-side filters can be easily configured per project in the "Data Filters" section of **[Project] > Settings > Inbound Filters**. Learn more in [Inbound Filters](/product/accounts/quotas/#inbound-data-filters).

Once applied, you can track the filtered events (numbers and cause) using the graph provided at the top of the "Inbound Filters" page.

![Built-in Inbound Filters](manage-event-stream-03.png)

## 3. Event Usage Stats

Expand Down