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

ref(spans): Limit spans on transactions to 800kib #3645

Merged
merged 5 commits into from
May 27, 2024
Merged

Conversation

Dav1dde
Copy link
Member

@Dav1dde Dav1dde commented May 24, 2024

Limits the maximum size of spans to 800kib to stay within the 1mb limit for transactions.

Due to normalization Relay may add more information to spans which can push the event over the 1mib limit causing upstream Relays to reject event, which was initially accepted. Limits the spans to 800kib as a best effort approach to not go past the limit.

Technically it is still possible to go over the limit, but reducing the maximum size for spans even further may compromise existing experiences.

Relates to: getsentry/sentry#68331

@Dav1dde Dav1dde requested a review from a team as a code owner May 24, 2024 10:22
@Dav1dde Dav1dde self-assigned this May 24, 2024
@Dav1dde Dav1dde force-pushed the dav1d/limit-spans branch from a5e89e9 to 3ba01cc Compare May 24, 2024 10:26
Copy link
Member

@jjbayer jjbayer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please add a test case (e.g. programmatically constructed) to see what the trimmed event payload would look like?

@Dav1dde Dav1dde enabled auto-merge (squash) May 27, 2024 06:32
@Dav1dde Dav1dde merged commit 5590aeb into master May 27, 2024
22 checks passed
@Dav1dde Dav1dde deleted the dav1d/limit-spans branch May 27, 2024 08:06
jjbayer added a commit that referenced this pull request Jun 4, 2024
Since #3645, we're seeing
incomplete or missing trace IDs on spans (see linked sentry issues).
What happens is that after visiting a long `span.description`, there is
no budget left for essential fields and the trimming processor drops or
trims them.

* Introduce `trim = "false"` field attribute to disallow trimming of
specific fields.
* Apply the new field to `span.trace_id` and other essential fields to
prevent them from being partially scrubbed or dropped entirely.

Current limitations:

- Not trimming these fields leads to over-accepting bytes. This should
not matter as long as the fields that have `trim = "false"` are limited
in size (which they are currently not, see
#3535 as follow-up).
- The more correct solution would be to subtract the length of `trim =
"false"` fields _before_ trimming any other fields.
- Alternatively, we could decide to never over-accept, and drop items
after visiting them if the budget is negative. I implemented this in
[1136f76](1136f76)
but it resulted in more failing tests, because the current trimming
processor already over-accepts a little bit (key lengths), and I did not
want to touch the default behavior. cc @Dav1dde.

Fixes
[RELAY-2NY7](https://sentry.my.sentry.io/organizations/sentry/issues/1005495/),
[RELAY-2NY8](https://sentry.my.sentry.io/organizations/sentry/issues/1005496/),
[SNUBA-552](https://sentry.sentry.io/issues/5429321769/).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants