26

(django プロジェクトで) Sentry を使用していますが、エラーを適切に集計する方法を知りたいです。特定のユーザー アクションをエラーとしてログに記録しているため、根本的なシステム例外はなく、culprit属性を使用してわかりやすいエラー名を設定しています。メッセージはテンプレート化されており、共通のメッセージ (「ユーザー 'x' は 'y' のためアクションを実行できませんでした」) が含まれていますが、完全に同じになることはありません (ユーザーが異なる、条件が異なる)。

Sentry は明らかに内部でいくつかの属性セットを使用して、エラーを同じ例外として集計するかどうかを決定しますが、コードを調べたにもかかわらず、その方法がわかりません。

コードをさらに掘り下げて、必要に応じて集計を管理するために設定する必要があるプロパティを教えてくれる人はいますか?

[更新 1: イベントのグループ化]

次の行が sentry.models.Group に表示されます。

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

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

これは理にかなっています-私が現在設定しているプロジェクト、ロガー、犯人-問題はchecksum. さらに調査しますが、「チェックサム」はバイナリの同等性を示唆していますが、これは決して機能しません。同じ例外のインスタンスを異なる属性でグループ化することが可能でなければなりませんか?

[更新 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: イベント インターフェイス]

インターフェイスは監視イベントに渡されるデータを記述するための標準メカニズムを参照し、標準とインターフェイスを使用していることを理解しました。sentry.interfaces.Messagesentry.interfaces.User

これらはどちらも、例外インスタンスに応じて異なるデータを含むため、チェックサムが一致することはありません。これらをチェックサム計算から除外する方法はありますか? （または、少なくともUserインターフェイス値は異なる必要があるため、Message標準化できるインターフェイス値です。）

[更新 4: 解決策]

それぞれおよびインターフェイスの 2 つのget_hash関数を次に示します。MessageUser

# sentry.interfaces.Message
def get_hash(self):
    return [self.message]

# sentry.interfaces.User
def get_hash(self):
    return []

これら2つを見ると、Message.get_hashインターフェイスのみがメソッドによって取得された値を返すget_checksum_for_eventため、これが返されます（ハッシュなど）。これの最終的な効果は、メッセージでチェックサムが評価されることです。単独 - 理論的には、メッセージを標準化し、ユーザー定義を一意に保つことができることを意味します。

I've answered my own question here, but hopefully my investigation is of use to others having the same problem. (As an aside, I've also submitted a pull request against the Sentry documentation as part of this ;-))

(Note to anyone using / extending Sentry with custom interfaces - if you want to avoid your interface being use to group exceptions, return an empty list.)

4

2 に答える 2

20

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

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

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

于 2012-11-11T15:29:57.660 に答える
1

例外に関する一般的な問題がありました。現在、私たちのシステムは例外のみをキャプチャしていますが、なぜこれらのいくつかが単一のエラーにマージされ、他のものはそうでないのか混乱しました. 上記の情報を使用して、「get_hash」メソッドを抽出し、エラーを「発生させる」違いを見つけようとしました。私が見つけたのは、グループ化されたエラーはすべて、空の Exception.message 値を持つ自己記述の例外タイプから発生したことです。

get_hash 出力:

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

複数のエラーは、メッセージ値が入力された例外クラス (jinja テンプレート エンジン) から発生しました。

[<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
于 2013-10-23T15:50:25.600 に答える