識別Bug跟蹤的重複例外

Question

我開發了一個「概念證明」應用程序，它將未處理的例外從應用程序記錄到一個錯誤跟蹤系統（在這種情況下，Team Foundation Server，但它可以是任何錯誤跟蹤系統） 。這種想法的侷限性在於，我不希望每次拋出相同的異常時都會打開重複的錯誤項目（例如，許多用戶遇到異常 - 它仍然是一個「錯誤」）。

我的第一次嘗試是將異常類型，消息和堆棧跟蹤作爲字段存儲在Bug跟蹤系統中。日誌組件然後將對Bug「Store」進行查詢，以查看是否存在與相同的信息。 （這個例子是.NET - 但我認爲這個概念是獨立平臺）。

問題顯然是這些字段可能非常大（尤其是堆棧跟蹤） - 並且需要「全文」類型的實現來存儲它們，並且搜索非常昂貴。

我想知道爲這個問題定義了什麼方法。我聽說FogBugz例如有一個用於自動化錯誤跟蹤的功能，並且很好奇它是如何實現的。

Answer 1

您可以創建堆棧跟蹤的校驗和散列，並將其作爲索引列存儲。這樣，對Bug Store的查詢將非常快速，以避免重複插入。

Answer 2

如果您有堆棧跟蹤，可以在堆棧跟蹤中找到最後一條語句，並將其與已經記錄的語句進行比較。如果包含這些符號，您還可以獲得行號。所以，現在你有兩件事要比較，實際的錯誤號和失敗的聲明，以及可能的實際行號。如果已經記錄了所有這些內容，那麼它很可能（當然不是100％）同一個問題。

實際上，您可能可以使用「at」字來解析堆棧跟蹤，因爲堆棧跟蹤中的每一行都以「at」開頭。因此，查找最後一個「at」，獲取該行，將其與存儲的堆棧跟蹤的最後一行「at」進行比較，並且實際上可能有某些內容。

HTH！

Answer 3

您可以查看聚合異常的現有開源解決方案之一的源代碼。

例如：https://github.com/getsentry/sentry/tree/master/src/sentry

它不是一個簡單的問題，有複雜的啓發式算法（例如相同的異常報告不同的瀏覽器不同的方式，例如引起瀏覽器擴展的異常是常見的，很少是重要的）。