Wrong grouping of events - different messages / culprits with the same checksum

[dmk23]

I am using Sentry to monitor a Django application with standard Django logging integration.

Sentry for some reason places highly unrelated events into the same groups. The events come from different loggers and I want to be sure they are not mixed up.

I looked into 'sentry_message' table and discovered that these events share the same checksum while having different 'logger', 'message' and 'view' values. This does not seem to be right since I believe checksum is calculated by mashing all these things into one hash.

My code generating the messages is polymorphic and uses somewhat standardized message format. So I believe lots of stacktraces and messages share similar fragments - but they are unique. However I was unable to find anywhere in the documentation what I can or should do on the client / logger side to control the event grouping.

Am I missing something here? I've tried tracing the code and my impression was that message string is used for hashing without any modifications, so it does not make sense...

[dcramer]

If they have a stack trace it's (more or less) the only component we look at. Logger is now a superficial value, and message and view are just labels for display.

On Friday, May 3, 2013 at 5:52 AM, dmk23 wrote:

I am using Sentry to monitor a Django application with standard Django logging integration.
Sentry for some reason places highly unrelated events into the same groups. The events come from different loggers and I want to be sure they are not mixed up.
I looked into 'sentry_message' table and discovered that these events share the same checksum while having different 'logger', 'message' and 'view' values. This does not seem to be right since I believe checksum is calculated by mashing all these things into one hash.
My code generating the messages is polymorphic and uses someone standardized message format. So I believe lots of stacktraces and messages share similar fragments. However I was unable to find anywhere in the documentation what I can or should do on my logging side to control event grouping.

—
Reply to this email directly or view it on GitHub (#889).

[dmk23]

They do have stacktraces, which are identical because they come from the same debug logging function...

Where can I override this behavior? I have polymorphic / centralized logging functions that seem prone to generating similar stacktraces with slightly different data. I'd like to make a hack to make stacktrace not the only thing to look at...

In any case, seems like it could be helpful to have a documentation session on how to organize logs for grouping purposes, especially from Django that has higher level wrappers which may be harder to unwrap...

[dcramer]

You can't override any of the grouping behavior. It should be taking into account the entire stacktrace though, not just the logging function where they end up.

On Friday, May 3, 2013 at 12:15 PM, dmk23 wrote:

They do have stacktraces, which are identical because they come from the same debug logging function...
Where can I override this behavior? I have polymorphic / centralized logging functions that seem prone to generating similar stacktraces with slightly different data. I'd like to make a hack to make stacktrace not the only thing to look at...
In any case, seems like it could be helpful to have a documentation session on how to organize logs for grouping purposes, especially from Django that has higher level wrappers which may be harder to unwrap...

—
Reply to this email directly or view it on GitHub (#889 (comment)).

[dmk23]

Well, this behavior clearly does not look right and I want to override it with a local hack if needed... I just want to find out where in the sentry code I need to change something.

The stack frames are all the same because I have a logging function shared by lots of classes / handlers. Apparently Raven does not take the context into account? Just stack frame function names?

[dcramer]

It takes in quite a bit, including the entire stack trace, so unless you're doing something funny so that its identical it won't group it.

You might also consider installing the latest dev, as at some point we improved the behavior.

pip install sentry==dev

If you want to change the Sentry source you'll have to dig into it yourself, but its described as a "hash" in the code, and its handled in interfaces.py