（Windows）異常處理：事件日誌或數據庫？

Question

我已經在我已經在事件日誌中實現異常處理的商店中，並在數據庫中的表中。

各有各的優點，而我可以突出一些基於我的經驗：

事件日誌

• 行業標準位置異常（+）
• 易於記錄的（+）
• 可以登錄此數據庫連接問題（+）
• 可以建立在事件日誌（+）
的頂部報告和查看應用程序10個
• 需要被經常刷新每一個，如果很多報道有（ - ）
• 沒有可擴展的SQL日誌[添加自定義字段，如在SQL方法名稱]（ - ）

SQL /數據庫

• 能處理大量數據（+）的
• 處理異常的快速卷插入（+）的平衡負載環境（+）異常
• 單個存儲位置
• 非常定製（+）
• 一點更容易建立報告/通知關閉SQL存儲（+）
• 從不同的地方典型的例外存儲（ - ）

我失去了任何重大事項？

我敢肯定，其中的一些觀點值得商榷，但我很好奇什麼對其他團隊效果最好，以及爲什麼你對選擇感到強烈。

Answer 1

你需要記錄和跟蹤之間進行區分。雖然線條有些模糊，但我傾向於認爲日誌記錄是「非開發人員的東西」。像未處理的異常，損壞的文件等，這些絕對不正常，應該是一個非常罕見的問題。

跟蹤是開發人員感興趣的事情。堆棧跟蹤，方法參數，Web服務器返回HTTP狀態401.3等等。這些實際上很嘈雜，並且可以在很短的時間內產生大量數據時間。通常我們有不同程度的跟蹤，以減少噪音。

對於在客戶端應用程序日誌，我認爲事件日誌是要走的路（我不得不仔細檢查，但我認爲ASP.NET健康監測可以寫入到事件日誌以及）。普通用戶有權寫入事件日誌，只要您有安裝程序（由管理員安裝）創建事件源。

你的大部分優勢，爲SQL日誌記錄，而真正的，並不適用於事件日誌：

• 可以處理大量的數據： 你真的有大量未處理的異常或其他高級失敗？
• 處理異常的快速卷插入：單未處理的異常應該把你的應用程序下來 - 它本質上速率的限制。對非開發者的其他有趣事件應該進行類似的彙總。
• 非常定製：在事件日誌消息是相當多的自由文本。如果您需要更多信息，只需指向文本或結構化XML或二進制文件日誌
• 從SQL存儲生成報告/通知有點簡單：報告內置了事件日誌查看器，通知系統，或者是固有的 - 由於應用程序崩潰 - 或者與其他真正關鍵的通知混合在一起 - 沒有任何理由錯過事件日誌消息。對於公司或其他聯網應用程序，有一千個和1個不同的應用程序已經從事件日誌中剔除錯誤...可能是您的系統管理員已經在使用一個。

對於跟蹤，其中的異常或錯誤的具體細節的一部分，我喜歡平面文件 - 它們很容易維護，易到grep，並可以導入到SQL進行分析我是否喜歡。

90％的時間，你不需要他們，他們被設置爲警告或錯誤。但是，當您將它們設置爲INFO或DEBUG時，您將生成一個數據文件。 RDBMS有很多開銷 - 性能（ACID，併發等），存儲（事務日誌，SCSI RAID-5驅動器等）和管理（備份，服務器維護等） - 所有這些都是跟蹤日誌不必要。

Answer 2

關於寫入事件日誌的一個注意事項是：需要某些權限給您的應用程序用戶，這些權限在某些環境中可能會被默認限制。

我在哪裏我們將大部分日誌記錄到數據庫中，並將平面文件作爲備份。這很不錯，我們可以做一些事情，比如獲取應用程序的RSS提要，以便在我們進行更改時觀看幾天。

Answer 3

需要考慮事件日誌的一件事是，那裏有產品可以監控您的服務器的事件日誌（如Microsoft Operations Manager）並智能地執行通知，並收集其內容的統計信息。

基於SQL的日誌記錄的「減號」是它嚮應用程序添加了另一層依賴關係，這可能會也可能不總是可以接受的。我在我的職業生涯中都做過。我曾經使用過一次或兩次甚至使用基於MSMQ的消息隊列對日誌事件進行排隊，並將隊列清空到MSSQL數據庫中，以免我的客戶端軟件需要連接到數據庫。

Answer 4

我不會記錄直接到數據庫。正如你所說，數據庫問題變得棘手的日誌:)

我會登錄到文件系統，然後有一個從文件批量插入到數據庫的作業。我個人喜歡有在主要的縮放情況日誌運行數據庫日誌 - 我幾乎以爲我會有不止一級機器中運行，它很方便，能夠有效地有一個聯合的日誌。 （當然，每個條目應該說明它來自哪臺機器。）

報告和查看應用程序可以很容易地從數據庫完成 - 目前可能有更少的日誌專用報告工具，但幾乎沒有所有數據庫都具有通用的報告功能。

爲了便於記錄的，我會使用像log4net一個框架，它需要很多的努力出來的，而且是一個經得起考驗的解決方案。除此之外，這意味着您可以在不更改代碼的情況下更改您的輸出策略。如有必要，您甚至可以登錄到事件日誌和數據庫，或者將一些日誌發送到一個地方，另一些發送到另一個地方。 （我認爲.NET在這裏，但也有許多平臺類似的日誌框架。）