Я использую Sentry (в проекте django), и я хотел бы знать, как я могу правильно собрать ошибки. Я регистрирую определенные действия пользователя как ошибки, поэтому нет основного системного исключения, и я использую атрибут culprit
для установки дружественного имени ошибки. Сообщение шаблонизировано и содержит общее сообщение ( "Пользователь" x "не смог выполнить действие, потому что" y "), но никогда не бывает точно таким же (разные пользователи, разные условия).
Sentry явно использует некоторый набор атрибутов под капотом, чтобы определить, следует ли агрегировать ошибки как одно и то же исключение, но, несмотря на просмотр кода, я не могу понять, как это сделать.
Может ли кто-нибудь сократить мои потребности в копании дальше в код и рассказать мне, какие свойства мне нужно установить, чтобы управлять агрегацией, как мне бы хотелось?
[ОБНОВЛЕНИЕ 1: группировка событий]
Эта строка появляется в sendry.models.Group:
class Group(MessageBase):
"""
Aggregated message which summarizes a set of Events.
"""
...
class Meta:
unique_together = (('project', 'logger', 'culprit', 'checksum'),)
...
Что имеет смысл - проект, регистратор и виновник, который я устанавливаю на данный момент - проблема checksum
. Я буду исследовать далее, однако "контрольная сумма" предполагает, что бинарная эквивалентность, которая никогда не сработает - должна быть возможность группировать экземпляры одного и того же исключения с атрибутами differenct?
[ОБНОВЛЕНИЕ 2: контрольные суммы событий]
Контрольная сумма события исходит из метода sentry.manager.get_checksum_from_event
:
def get_checksum_from_event(event):
for interface in event.interfaces.itervalues():
result = interface.get_hash()
if result:
hash = hashlib.md5()
for r in result:
hash.update(to_string(r))
return hash.hexdigest()
return hashlib.md5(to_string(event.message)).hexdigest()
Следующая остановка - откуда происходит событие interfaces
?
[ОБНОВЛЕНИЕ 3: интерфейсы событий]
Я разработал, что interfaces ссылается на стандартный механизм описания данных, передаваемых в часовые события, и что я использую стандартные sentry.interfaces.Message
и sentry.interfaces.User
.
Оба они будут содержать разные данные в зависимости от экземпляра исключения - и поэтому контрольная сумма никогда не будет соответствовать. Есть ли способ, который я могу исключить из расчета контрольной суммы? (Или, по крайней мере, значение интерфейса User
, поскольку это должно быть другим - значение интерфейса Message
, которое я мог бы стандартизировать.)
[ОБНОВЛЕНИЕ 4: решение]
Вот две функции get_hash
для интерфейсов Message
и User
соответственно:
# sentry.interfaces.Message
def get_hash(self):
return [self.message]
# sentry.interfaces.User
def get_hash(self):
return []
Посмотрев на эти два, только интерфейс Message.get_hash
вернет значение, которое подхвачено методом get_checksum_for_event
, и, таким образом, это тот, который будет возвращен (хэширован и т.д.). Чистый эффект этого что контрольная сумма оценивается только по одному сообщению, что теоретически означает, что я могу стандартизировать сообщение и сохранить уникальное определение пользователя.
Я ответил на свой собственный вопрос здесь, но, надеюсь, мое исследование полезно другим, имеющим ту же проблему. (В стороне, я также представил запрос на тягу к документации Sentry как часть этого; -))
(Обратите внимание на тех, кто использует/расширяя Sentry с пользовательскими интерфейсами - если вы хотите, чтобы ваш интерфейс не использовался для группировки исключений, верните пустой список.)