[Django]-How does Sentry aggregate errors?

20👍

✅

See my final update in the question itself. Events are aggregated on a combination of ‘project’, ‘logger’, ‘culprit’ and ‘checksum’ properties. The first three of these are relatively easy to control – the fourth, ‘checksum’ is a function of the type of data sent as part of the event.

Sentry uses the concept of ‘interfaces’ to control the structure of data passed in, and each interface comes with an implementation of get_hash, which is used to return a hash value for the data passed in. Sentry comes with a number of standard interfaces (‘Message’, ‘User’, ‘HTTP’, ‘Stacktrace’, ‘Query’, ‘Exception’), and these each have their own implemenation of get_hash. The default (inherited from the Interface base class) is a empty list, which would not affect the checksum.

In the absence of any valid interfaces, the event message itself is hashed and returned as the checksum, meaning that the message would need to be unique for the event to be grouped.

1👍

I’ve had a common problem with Exceptions. Currently our system is capturing only exceptions and I was confused why some of these where merged into a single error, others are not.
With your information above I extraced the “get_hash” methods and tried to find the differences “raising” my errors. What I found out is that the grouped errors all came from a self written Exception type that has an empty Exception.message value.

get_hash output:

[<class 'StorageException'>, StorageException()]

and the multiple errors came from an exception class that has a filled message value (jinja template engine)

[<class 'jinja2.exceptions.UndefinedError'>, UndefinedError('dict object has no attribute LISTza_*XYZ*',)]

Different exception messages trigger different reports, in my case the merge was caused due to the lack of the Exception.message value.

Implementation:

class StorageException(Exception):

def __init__(self, value):
    Exception.__init__(self)
    self.value = value

Leave a comment