Skip to content
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

chore: Clarification around size limits and stats #9911

Merged
merged 9 commits into from
May 11, 2024
32 changes: 32 additions & 0 deletions docs/concepts/data-management/size-limits.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,32 @@
---
title: Size Limits
sidebar_order: 7
description: "Learn about the size limits for events and attachments, and how to avoid exceeding them."
---

Sentry imposes size limits on events, attachments, requests, and various event fields.

## Behavior

The following describes how Sentry treats size limits:

- Events, attachments, and requests exceeding payload size limits are immediately dropped with a `413 Payload Too Large` error.
- Sentry allows compressed content encoding, and applies separate limits before and after decompression.
- Events that exceed 200KB compressed or 1MB decompressed will be rejected.
- Minidump uploads that exceeed 20MB compressed or 100MB decompressed (for all files combined) will also be rejected.
- Event fields exceeding the individual size limits are trimmed and truncated afterwards.
- The number of events rejected due to size limits is counted towards the _Dropped_ category in [usage stats](/product/stats/#usage-stats)

## Recommendations

To avoid using up your attachments quota — which is based on size and not number of instances of attachments data sent — or having the event dropped entirely, consider limiting the size of values passed into Sentry's APIs. For example, if your application attaches application state or request bodies to Sentry events, truncate them first.

## Size Limit References

Sentry's exact size limits may change over time. For more information, please refer to the following resources:

- [Envelope Size Limits](https://develop.sentry.dev/sdk/envelopes/#size-limits)
- [Store Endpoint Size Limits](https://develop.sentry.dev/sdk/store/#size-limits)
- [Minidump Size Limits](/platforms/native/guides/minidumps/#size-limits)
- [Variable Size Limits](https://develop.sentry.dev/sdk/data-handling/#variable-size)

22 changes: 3 additions & 19 deletions docs/organization/quotas/manage-attachments-quota.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -94,24 +94,8 @@ SDK configuration requires changes to your source code and depends on your next

While you can't set filters for attachments directly, when you set inbound filters for error events, their associated attachments are indirectly filtered. Learn more about setting data filters for error events in [Manage Your Error Quota](/account/quotas/manage-event-stream-guide/).

## Size Limits
## Attachments Size

Sentry imposes limits on various fields within an event, as well as the size of full events and the requests they are sent in:
To avoid using up your attachments quota — which is based on size and not number of instances of attachments data sent — or having the attachment dropped entirely, consider limiting the size of values passed into Sentry's APIs. For example, if your application attaches application state or request bodies to Sentry events, truncate them first.

- Events, attachments, and requests exceeding payload size limits are immediately dropped with a `413 Payload Too Large` error. Sentry allows compressed content encoding, and applies separate limits before and after decompression.
- Fields exceeding the individual size limits are afterwards trimmed and truncated at a best effort.

To avoid using up your attachments quota — whch is based on size and not number of instances of attachments data sent — or having the event dropped entirely, consider limiting the size of values passed into Sentry's APIs. For example, if your application attaches application state or request bodies to Sentry events, truncate them first.

The precise limits may change over time. For more information, please refer to the following resources:

- [Envelope Size Limits](https://develop.sentry.dev/sdk/envelopes/#size-limits)
- [Store Endpoint Size Limits](https://develop.sentry.dev/sdk/store/#size-limits)
- [Minidump Size Limits](/platforms/native/guides/minidumps/#size-limits)
- [Variable Size Limits](https://develop.sentry.dev/sdk/data-handling/#variable-size)

<Alert>

If the event exceeds 200KB compressed or 1MB decompressed for events and 20MB compressed or 100MB decompressed for minidump uploads (all files combined), the event will be rejected.

</Alert>
For more information, refer to our [Size Limits](/concepts/data-management/size-limits) guide.
2 changes: 1 addition & 1 deletion docs/product/stats/index.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -10,7 +10,7 @@ The "Usage" tab shows your organization’s event and attachments usage, while a

## Usage Stats

The "Usage" tab shows you the events (errors and transactions) and attachments Sentry has received across your entire organization along with a list of all projects and their consumption of each of those. Your usage falls into one of three categories: _Accepted_, _Filtered_, or _Dropped_. Filtered events and attachments are ones that were blocked due to your [inbound data filter](/concepts/data-management/filtering/) rules. Dropped events and attachments are ones the system dropped or discarded due to rate limits, quotas, spike protection, or because of invalid data.
The "Usage" tab shows you the events (errors and transactions) and attachments Sentry has received across your entire organization along with a list of all projects and their consumption of each of those. Your usage falls into one of three categories: _Accepted_, _Filtered_, or _Dropped_. Filtered events and attachments are ones that were blocked due to your [inbound data filter](/concepts/data-management/filtering/) rules. Dropped events and attachments are ones the system dropped or discarded due to rate limits, quotas, spike protection, size limits, or because of invalid data.
vivianyentran marked this conversation as resolved.
Show resolved Hide resolved

You can see which projects have had a recent spike or are the most active and may need more attention. On this page, you can also control the date range that’s displayed, allowing you to focus on a smaller period of time or zoom out for a longer view. The page is designed for org admins, but is available to all team members. This is helpful if a team member who isn't an admin is tasked with reviewing these statistics. Also, this allows team members associated with specific projects to use this page to investigate why their events are being dropped.

Expand Down