Exception grouping with sentry

KaranMalhotra · October 5, 2016, 8:03am

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?

zeeg · October 5, 2016, 6:23pm

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

bittner · August 3, 2017, 4:21pm

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.

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

zeeg · August 3, 2017, 5:01pm

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

github.com

getsentry/sentry/blob/master/src/sentry/event_manager.py#L83


      
              load_grouping_config,
          )
          from sentry.grouping.result import CalculatedHashes
          from sentry.ingest.inbound_filters import FilterStatKeys
          from sentry.issues.grouptype import GroupCategory
          from sentry.issues.issue_occurrence import IssueOccurrence
          from sentry.issues.producer import PayloadType, produce_occurrence_to_kafka
          from sentry.killswitches import killswitch_matches_context
          from sentry.lang.native.utils import STORE_CRASH_REPORTS_ALL, convert_crashreport_count
          from sentry.locks import locks
          from sentry.models.activity import Activity
          from sentry.models.environment import Environment
          from sentry.models.event import EventDict
          from sentry.models.eventattachment import CRASH_REPORT_TYPES, EventAttachment, get_crashreport_key
          from sentry.models.files.file import File
          from sentry.models.group import Group, GroupStatus
          from sentry.models.groupenvironment import GroupEnvironment
          from sentry.models.grouphash import GroupHash
          from sentry.models.grouphistory import GroupHistoryStatus, record_group_history
          from sentry.models.grouplink import GroupLink
          from sentry.models.grouprelease import GroupRelease

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

github.com

getsentry/sentry/blob/master/src/sentry/interfaces/exception.py#L142


      
                  "type",
                  "synthetic",
                  "description",
                  "help_link",
                  "handled",
                  "data",
                  "meta",
                  "source",
                  "is_exception_group",
                  "exception_id",
                  "parent_id",
              ):
                  data.setdefault(key, None)
          
              return super().to_python(data, **kwargs)
          
          def to_json(self):
              return prune_empty_keys(
                  {
                      "type": self.type,
                      "synthetic": self.synthetic,

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.

alexandrul · September 20, 2017, 10:32am

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.

kennethjiang · May 22, 2019, 2:04pm

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!

Topic		Replies	Views
Same events don't get grouped?	0	894	April 29, 2019
Grouping with Sentry	0	848	June 30, 2019
Grouping similar events On-Premise	1	692	October 12, 2020
Event grouping ignores stack trace?	9	1631	March 2, 2020
Grouping by stacktrace SDKs	2	1172	October 22, 2017

Exception grouping with sentry

Ignoring and Grouping

Related topics