Exception grouping with sentry


#1

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?


#2

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).


#3

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.


#4

@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.


#5

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.