Sentryはどのようにエラーを集計しますか？

Question

私はSentry（djangoプロジェクトで）を使用していますが、エラーをどのようにして適切に集めることができるかを知りたいと思います。特定のユーザーアクションをエラーとしてログに記録しているため、基になるシステム例外はなく、culprit属性を使用してフレンドリエラー名を設定しています。メッセージはテンプレート化されており、共通のメッセージ（「User 'x'は 'y'」のためアクションを実行できませんでしたが）は全く同じではありません（異なるユーザー、異なる条件）。

Sentryは、同じ例外としてエラーを集計するかどうかを判断するために、いくつかの属性セットを使用していますが、コードを見ても、どうやって解決するかはわかりません。

誰でもコードを詳しく調べて、私が望むように集約を管理するために設定する必要があるプロパティを教えてもらえますか？

[UPDATE 1：イベントのグループ化]

この行はsentry.models.Groupに表示されます意味になり

class Group(MessageBase): 
    """ 
    Aggregated message which summarizes a set of Events. 
    """ 
    ... 

    class Meta: 
     unique_together = (('project', 'logger', 'culprit', 'checksum'),) 
    ... 

- 私は、現時点では設定していたプロジェクト、ロガーと犯人を - 問題をchecksumです。私はさらに調査するつもりですが、「チェックサム」はバイナリ同値性を示唆しています。これは決して動作しません。同じ例外のインスタンスをdifferenct属性でグループ化する必要がありますか？

[UPDATE 2：イベントのチェックサム]：

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から来るのか

イベントチェックサムがsentry.manager.get_checksum_from_event方法から来ていますか？

[UPDATE 3：イベント・インターフェース]

私はinterfacesはセントリイベントに渡されたデータを記述するための標準メカニズムを指すことが働いており、私は、標準sentry.interfaces.Messageとsentry.interfaces.Userインターフェースを使用していません。

これらの両方に例外インスタンスに応じて異なるデータが含まれるため、チェックサムは決して一致しません。これらをチェックサム計算から除外できる方法はありますか？ （つまり、異なるなければならないとしても、少なくともUserインタフェース値は、 - Messageインタフェース値Iは標準化できた。）

[UPDATE 4：溶液]

ここ

MessageとUserのための2つのget_hash関数でありますそれぞれインターフェース：

# 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方法によってピックアップされた値を返し、これは返される一方（ハッシュ等）Thがありますeの効果は、チェックサムがメッセージだけで評価されるということです。理論的には、メッセージを標準化してユーザー定義をユニークに保つことができます。

私はここで自分の質問に答えましたが、うまくいけば私の調査は同じ問題を抱えている他の人にも役立つはずです。（別に、私はSentryのドキュメンテーションに対して、これの一部としてプルリクエストを提出しました;-)）

（カスタムインターフェイスでSentryを使用している/拡張している人には注意してください。例外をグループ化するために使用し、空のリストを返します）。

Answer 1

質問自体の最終更新を参照してください。イベントは、 'project'、 'logger'、 'culprit'および 'checksum'プロパティの組み合わせで集計されます。これらの最初の3つは比較的制御が簡単です.4番目の「チェックサム」は、イベントの一部として送信されるデータの種類の関数です。

Sentryは渡されたデータの構造を制御するために 'interfaces'という概念を使用し、各インタフェースにはget_hashの実装が付属しています。これは渡されるデータのハッシュ値を返すために使用されます。 （ 'Message'、 'User'、 'HTTP'、 'Stacktrace'、 'Query'、 'Exception'）の標準インタフェースを持ち、それぞれ独自の実装であるget_hashを持っています。デフォルト（Interface基本クラスから継承）は空のリストであり、チェックサムには影響しません。

有効なインターフェイスがない場合、イベントメッセージ自体がハッシュされ、チェックサムとして返されます。つまり、イベントをグループ化するためにメッセージが一意である必要があります。

Answer 2

例外に共通の問題がありました。現在のところ、私たちのシステムは例外だけをキャプチャしていますが、なぜこれらのうちのいくつかが単一のエラーにマージされたのか、他のものがマージされなかったのか混乱しました。 上記の情報を使って、「get_hash」メソッドを追加し、エラーを「発生させる」という相違点を見つけようとしました。私が見つけたのは、グループ化されたエラーはすべて、空のException.message値を持つ自己書き出しのException型から来ているということです。

get_hash出力：

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

と複数のエラーが

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

異なる例外メッセージは、私の中で、さまざまなレポートをトリガー満たさメッセージ値（神社のテンプレートエンジンを）持っている例外クラスから来ましたException.message値がないためにマージが発生した場合

実装：

class StorageException(Exception): 

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