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

Config SENTRY_MAX_MESSAGE_LENGTH does not work #13585

Open
nbhuy89 opened this issue Jun 7, 2019 · 8 comments

Comments

@nbhuy89
Copy link

commented Jun 7, 2019

Hi,
I config SENTRY_MAX_MESSAGE_LENGTH to another number, but the message always be truncated at 1000 characters, how can i make it work?
I'm using sentry server version Sentry 9.1.1
Thanks,

@untitaker

This comment has been minimized.

Copy link
Member

commented Jun 10, 2019

9.1.1 should have a limit of 8000 chars. Which message attribute do you mean? Could you provide a screenshot?

@nbhuy89

This comment has been minimized.

Copy link
Author

commented Jun 17, 2019

Sorry, I rechecked, I see it truncate at 8000 chars like you said, Is there any way to increase this limit number?

@caseyduquettesc

This comment has been minimized.

Copy link

commented Jun 17, 2019

I found in 9.1 that SENTRY_MAX_MESSAGE_LENGTH was not working because the Rust processor (new) had a hardcoded message field size. Since 9.1's release, we've been running with this patch that disables the Rust processor trimming, which appears to be optional, with no problems. We increased max message length from 8KB to 256KB.

--- sentry/src/sentry-dev/src/sentry/event_manager_9.1.py	2019-04-25 10:06:31.000000000 -0700
+++ sentry/src/sentry-dev/src/sentry/event_manager_new.py	2019-04-25 10:06:48.000000000 -0700
@@ -444,7 +444,7 @@
             valid_platforms=list(VALID_PLATFORMS),
             max_secs_in_future=MAX_SECS_IN_FUTURE,
             max_secs_in_past=MAX_SECS_IN_PAST,
-            enable_trimming=True,
+            enable_trimming=False,
             is_renormalize=self._is_renormalize
         )

And in our Dockerfile,

patch /usr/local/lib/python2.7/site-packages/sentry/event_manager.py /etc/sentry/patchfiles/event_manager.patch
@BYK

This comment has been minimized.

Copy link
Contributor

commented Jun 18, 2019

@untitaker do you know whether this was intentional or not?

@untitaker

This comment has been minimized.

Copy link
Member

commented Jun 18, 2019

We didn't think that people would care about this setting. I would be cool with a single setting that just turns of trimming altogether (like in @caseyduquettesc's patch) assuming that's fine-grained enough for most people who want this. Just make sure it's false by default :)

@troyvo

This comment has been minimized.

Copy link

commented Jun 26, 2019

@caseyduquettesc , just tested. It works like a charm. you save my time. Thanks

@jan-auer

This comment has been minimized.

Copy link
Member

commented Jul 17, 2019

It might be worth noting here that we're planning to move all of that code into a new, separate service. As part of this, many of these settings might no longer be configurable going forward (such as trimming, for instance).

Might I ask what the use case is for such large messages? With event attachments (basically file uploads that show up on the issue details screen), we might have a suitable alternative in Sentry 10.

@caseyduquettesc

This comment has been minimized.

Copy link

commented Jul 17, 2019

@jan-auer
One of our projects in our on-prem setup is for android crashes. But the crashes don't come directly to Sentry; they go through a proxy for automatic triaging, symbolication, and doing Jira integrations before it gets forwarded to Sentry using the standard java client to send. These crashes don't use the exception interface, and dump all the information into the message field plus tags. This data can be large (up to 0.5MB) if it includes thread dumps. I understand this is arguably improper use of the tool, but that process was before my time. Ideally it would use extra data and exception fields properly, but for now, this is what I'm stuck with.

I completely understand that your roadmap may not necessarily support my use case and we've accepted that we have sort of gone off book here. I appreciate that you asked though and hope you just continue to keep doing what's best for the product, it's great.

A warning for anyone else disabling trimming and inserting large messages - it will absolutely kill your snuba/clickhouse service with searching large messages. I had to just disable message searching entirely for this one project until I can figure out either how to reduce the message size just in clickhouse or migrating message searching to something like elastic search.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.