Sentry的一個重要部分是如何將類似事件聚合在一起並建立彙總。事實證明這是一個相當複雜的問題，並且可能會讓使用者感到困惑，因為有些資訊可能無法正確分組。 事件的結構化資料決定了如何建立彙總。這取決於可用資料和語言。

一、分組優先順序

分組根據事件中可用的介面（介面）切換行為。

• 如果事件中使用的介面不同，則這些事件不會組合在一起。
• 如果報表中涉及堆疊跟蹤或異常，則分組將僅考慮此資訊。
• 如果涉及模板，則分組將考慮模板。
• 作為後備，事件的訊息將用於分組。

二、由Stacktrace分組

當Sentry在事件資料中檢測到堆疊跟蹤時（直接或作為異常的一部分），分組有效地完全基於堆疊跟蹤。這種分組相當複雜，但很容易理解。 第一個也是最重要的部分是Sentry僅按應用程式中報告的堆疊跟蹤幀進行分組。並非所有SDK都可以報告此情況，但如果提供了該資訊，則會將其用於分組。這意味著如果堆疊跟蹤僅在堆疊的與應用程式無關的部分中從一個事件修改為另一個事件，則它仍然將其分組。 根據資訊，可以為每個堆疊跟蹤幀使用以下資料：

• 模組名稱
• 規範化檔名（從修訂雜湊等中刪除）
• 規範化的上下文行（如果提供的話，基本上是受影響行的原始碼的清理版本）

這種分組通常效果很好，但如果不處理，會導致兩個惱人的問題。

• 最小化的JavaScript原始碼將以非常糟糕的方式破壞分組。 因此，您應確保Sentry可以訪問您的Source Map檔案。
• 如果通過使用裝飾器引入新級別來修改堆疊跟蹤，則堆疊跟蹤將發生更改，分組也將發生更改。 對於這個問題，許多SDK支援隱藏不相關的堆疊跟蹤幀。 例如，Python SDK將跳過所有堆疊幀，並將一個名為__traceback_hide__的區域性變數設定為True。

三、按異常分組

如果沒有可用的堆疊跟蹤但是異常資訊，則分組將考慮異常的型別和值。如果其中任何一個不存在，則跳過它。由於更改錯誤訊息，此分組的可靠性要低得多。

四、按模板分組

如果涉及模板，則邏輯類似於通過堆疊跟蹤進行分組，但顯然資訊較少，因為模板跟蹤具有較少的可用資料。然而，一般概念適用。

五、後備分組

如果其他一切都失敗了，分組會回落到訊息中。理想情況下，分組僅使用不帶引數的訊息，但如果不可用，則使用訊息屬性。

六、使用指紋自定義分組

對於一些非常高階的用例，SDK可以覆蓋Sentry預設分組。 通常會出現兩種常見情況：

• 查詢RPC或外部API服務，因此堆疊跟蹤通常是相同的（即使傳出請求非常不同）
• 一般錯誤（例如資料庫連線錯誤）具有許多不同的堆疊跟蹤，並且從不組合在一起。

要解決這些問題，Sentry協議支援指紋屬性。

在支援的SDK中，此屬性可以與事件資訊一起傳遞，並且應該是字串陣列：

Sentry.configureScope((scope) => {
  scope.setFingerprint(['my-view-function']);
});

此外，如果您只是希望附加資訊，從而使分組略顯不那麼激進，您也可以通過新增特殊字串{{default}}作為其中一項來實現。