Exception grouping with sentry

As per my current understanding, Sentry will group exception of similar type i.e all NPE would be grouped as a single event, this might not be the perfect scenario for us.

Can I somehow group exception in a different way? like the first line of the trace or something similar?

We document how we do rollups here:

https://docs.sentry.io/learn/rollups/

You can control them by passing a fingerprint (which often is doable via the ‘send callback’ in SDKs).

David, can you give references to relevant source code pieces?

Is this all done in the Sentry code base (interfaces?), or is the client code (Raven) also involved? I’m having a hard time to find this in the code.

Ignoring and Grouping

According to the learning resource you quoted only the exception data is relevant for grouping, given it is available:

If a stacktrace or exception is involved in a report then grouping will only consider this information.

  1. Does this mean if we need to filter or ignore the same exception, say, for different web browsers then this information is not possible to have; you get a single, aggregated logging item (event) in Sentry regardless of other, say, front-end related, details. Is this correct?
  2. What happens with additional information (that causes aggregation not to happen) when events are merged manually in Sentry? Which information is thrown away (if any)?
  3. Does this mean filtering or ignoring exceptions for specific tags, say, specific browsers, devices or OSes is not reliably possible (because some information may be thrown away or ignored to facilitate aggregation)?

I need to be able to explain to my fellow developers:

  • Filtering seems to be possible from the Sentry user interface, but is all data, are all reported exceptions, represented?
  • When we ignore an event “what” will actually be ignored? An identical exception when it pops up again? Or does everything have to match (even, say, the web browser version, device or OS)?
  • Ignoring seems to be “generic” from the Sentry user interface. Ignoring very specific events (e.g. based on an exact match of specific tags, such as a web browser), is that possible?
  • Does Sentry “learn” from performing manual merges on events? I.e., will similar events be merged automatically into the now merged event the next time they pop up? (It doesn’t seem so.)

P.S.: We’re currently interested in JavaScript and PHP exception logging only. If that helps to make an answer more concise.

@bittner its almost all inside of Sentry itself. The SDKs do provide a way override the behavior (‘checksum’, deprecated, and ‘fingerprint’).

Here’s more or less how it works:

Each interface provides a couple of hash abstractions. For example, here’s where a portion of an exception enters:

To answer a few of your questions:

Does this mean if we need to filter or ignore the same exception, say, for different web browsers then this information is not possible to have; you get a single, aggregated logging item (event) in Sentry regardless of other, say, front-end related, details. Is this correct?

Our long term goal is to aggregate by root cause. We dont achieve this as well as we’d like, and there’s some efforts going to improve our standard heuristics as well as some basic machine learning concepts to find similar-but-not-exact matches.

What happens with additional information (that causes aggregation not to happen) when events are merged manually in Sentry? Which information is thrown away (if any)?

At this stage I believe we say “no data is lost on merging”. That may not be 100% true yet, but there’s an effort undergoing that allows you to merge, split, rehash, etc events (on the backend) which is needed to power some upcoming things.

Does this mean filtering or ignoring exceptions for specific tags, say, specific browsers, devices or OSes is not reliably possible (because some information may be thrown away or ignored to facilitate aggregation)?

Nope, works very well. Filtering/ignore behavior happens before aggregation, but after processing.

I have two errors for which the stacktrace is not present in the application log (internal java application).

The good part is that Sentry is showing the same stacktrace for both of them.
The bad part is that they are not grouped.

What are the rules for grouping errors based on the actual text (since the stacktrace is ignored)?

The current error messages:

  • Document ABC/Def/123 is not valid. customField is missing.
  • Document ABC/Def/124 is not valid. customField is missing.

Sorry for reviving this old thread. But a problem related to exception grouping has caused us to start ignoring alerts from Sentry and I’m wondering if we missed something obvious.

This problem is: whenever we add a few lines to a file, line no will change for a good part of that file. The any exception that involves that file will likely have its stack trace changed with it.

For example:


changed_file.py in not_changed_method at line 217

becomes

changed_file.py in not_changed_method at line 223

Essentially what has been happening to us is every time we push a release, we will get quite a few “new” errors that are just duplicates of existing ones. Since we release very often, this problem has caused us to start not paying attention to emails from Sentry, which has largely defeated our original motivation to adopt Sentry.

Document https://docs.sentry.io/data-management/rollups/?platform=python mentioned “normalized” context line. I’m not sure what that exactly means but in our experience we have not found any case when Sentry is smart enough to understand some line no changes in the stack trace actually don’t matter.

Other than this problem, Sentry is a great piece of software. Thank you for creating it all developers in the world!