ELMAH（ASP.NET錯誤記錄檔記錄與通知）系列文章-概念篇

    最近在研究幾個ASP.NET的開源項目時，發現都在使用ELMAH來作為記錄整個應用程式的錯誤記錄檔，於是拿來小研究了一下，在這裡和各位分享一下，如果有使用過的，請多指教。

    對於ELMAH，將用三篇系列文章來介紹：

•     概念篇
•     基本應用篇
•     進階應用程式篇

   概念篇

    ELMAH（The Error Logging Modules And Handlers），直譯過來就是“錯誤記錄檔模組和處理”，它提供了一個用於集中記錄和通知錯誤記錄檔的機制。它是專用於ASP.NET的完全可熱插拔的錯誤記錄檔記錄工具。其特點就是無需ASP.NET程式重新編譯，即可通過配置web.config（或machine.config）來實現整個應用程式甚至是IIS中所有ASP.NET應用程式的錯誤記錄檔記錄工作。它支援日誌的多種儲存方式（各種資料庫、XML、記憶體儲存），除了提供一個介面用於查詢日誌詳細資料外，還可以通過E-MAIL、RSS訂閱或Twitter發布方式通知錯誤資訊給相關人員。

 

    對於一個已經運行於生產環境的ASP.NET程式，如果想用ELMAH為程式增加錯誤記錄檔記錄的功能，只需要將ELMAH的dll檔案複製到程式的bin目錄下，然後修改此ASP.NET程式的web.config檔案，就完成了所有的配置工作。以後，想查看系統發生了哪些錯誤資訊，直接輸入在web.config中事先指定的頁面地址，即可看到日誌資訊。具體操作請看下一篇：應用篇。本文將簡單介紹其基本概念和運行機制。

1.ELMAH是一個可熱插拔的解決方案。也就是說可以動態加入到ASP.NET應用程式，而不需要對項目進行重新編譯和部署，因為僅需要在web.config中配置，並將一些程式集複製到bin目錄下即可，而不需要更改項目中其他任何內容（如果你項目中的代碼有可能導致ELMAH無法記錄一些異常資訊，則需要修改相關代碼，具體請看下面第4條）。

2.ELMAH僅僅是後台記錄未處理的異常，在異常發生時，它並不會改變使用者體驗，也就是說根據軟體自身設定情況，使用者依然可能看到黃顏色的報錯介面或者被定位到一個錯誤提示頁面。實際上，從使用者體驗角度，應該制定一個友好的錯誤頁面, 可以參考文章2。

3.ELMAH是通過HTTP modules與HTTP handlers來記錄和展示軟體中未捕獲的異常（如果異常通過catch被捕獲了就無法記錄了，除非捕獲後又throw。也就是在異常鏈上，最終的異常必須拋給了ASP.NET運行時，才可以被捕獲）。另外，如果那個未處理的異常是ASP.NET Web service的，因為這種異常不發給HTTP modules，ELMAH也是無法記錄到的.這種異常被ASP.NET運行時截獲並返回一個SOAP falut（SOAP訊息中傳輸錯誤及狀態資訊），因此，如果想記錄這種異常，可以建立一個SOAP擴充來監聽SOAP faults。

這裡簡單介紹一下HTTP modules與HTTP handlers：

當一個請求到達IIS，如果這個請求資源被配置為由ASP.NET ISAPI來處理，那麼IIS將把這一請求分發給aspnet_isapi.dll，而這個dll將請求又交給了ASP.NET引擎來處理。在這一引擎裡，有多個HTTP modules（可以在web.config中配置），每個請求都要依次通過這些HTTP modules，這就使得各個HTTP modules可以根據自己需要處理這些請求，當經過所有的HTTP modules後，將由一個（只能是一個）HTTP handler來處理這一請求（可以在web.config中配置由哪個HTTP handler來處理，它是根據被請求資源的路徑名稱或者尾碼名來決定，比如可以指定如果請求error.axd這個資源檔，則由名稱為ErrorLog的HTTP handler來處理。）。處理後這個HTTP handler將結果返回給使用者，其過程是上述的相反過程，通過各個HTTP modules，最終到達使用者端，如下：

 

下面來看看ELMAH是如果根據如上的機制，來配置httpModules和handlers的。

//ELAMH添加了一個HTTP module，從而讓每個請求和回應都通過它。當使用者請求一個資源而報錯後，返回給這個錯誤資訊時，//當通過了ErrorLog這個HTTP module，ELMAH擷取到回應中的錯誤資訊，並記錄下來。<httpModules>     <add name="ErrorLog" type="Elmah.ErrorLogModule, Elmah" /> </httpModules>   //當使用者想查看記錄下來的錯誤記錄檔時，他將請求叫做elmah.axd的資源檔，這個請求最終被叫做Elmah的這個handler來//處理，他查詢錯誤記錄檔的資訊後，將結果返回給使用者，從而實現了查詢功能。<handlers>   <add name="Elmah" verb="POST,GET,HEAD" path="elmah.axd" type="Elmah.ErrorLogPageFactory, Elmah"/></handlers>

4.ELMAH捕獲異常是基於HttpApplication對象的Error事件。如果軟體項目中的一些處理導致了HttpApplication事件無法被觸發（比如在發生異常後，還沒來得及執行Application_Error，就執行了Server.ClearError()方法，他會阻止Error事件的觸發，再比如，如果一個異常被try-catch捕獲到，並且沒有再次throw，那麼異常也是不會最終觸發Error事件），那ELMAH也就無能為力了。因此要確保這一點。

5.既然可以通過配置某一項目的web.config檔案並將DLL檔案Copy到項目的bin目錄下即可實現對某一項目的錯誤記錄檔記錄，那麼同樣可以通過配置machine.config以及將dll檔案置於GAC中，從而實現對IIS中所有ASP.NET項目實現錯誤記錄檔記錄。

6.還有一個常用的用於.NET異常處理的解決方案：Exception Management Application Block (EMAB)。他是Enterprise Library的一個模組。這裡並不主要討論它與ELMAH誰更好，只有哪個更適合某一應用，以下簡單對比：

(1)：ELMAH的機制決定他只用於ASP.NET，而EMAB同時適用於.NET的WinForm和ASP.NET，但是更適合用於WinForm，因為預設它將日誌記錄於作業系統的事件檢視器，事件檢視器適用於記錄精簡的日誌資訊，而這對於ASP.NET，如果是運行於共用主機等空間，還需要分配給ASP.NET讀寫事件檢視器的許可權，這顯然有時候並不可行。當然，EMAB也可定製其他記錄日誌的方式，但這一切都需要開發人員去實現。

(2)：EMAB不是熱插拔的解決方案，需要在Global.asax的Application_Error中（或其它位置）編寫相應代碼。而ELMAH是熱插拔的，不需要編寫代碼，不需要重新編譯軟體。

7.其實.NET下的日誌記錄工具還是不少的，比如著名的Log4net以及Enterprise Library中的Logging Application Block。可以說，這些工具相對ELMAH來說，太重量級了，他們可以記錄各種日誌資訊，比如監視代碼中變數的變化情況，周期性的記錄到檔案中供其他應用進行統計分析工作；跟蹤代碼運行時軌跡，作為日後審計的依據；擔當整合式開發環境中的調試器的作用，向檔案或控制台列印代碼的調試資訊。因此，如果僅僅是記錄ASP.NET的錯誤記錄檔，ELMAH應該是首選，而其他功能，ELMAH就無能力為了，也就是說，沒有所謂好壞，只有哪個更適合之說吧。

基本概念就這樣吧，要想深入理解其運行機制，可以參考下面的參考文章1，講的很詳細。

備忘：感謝周公幫我指出了一個筆誤，不知道你會不會解夢啊：）

參考文章：
1.《Using HTTP Modules and Handlers to Create Pluggable ASP.NET Components》

2.《customErrors Element (ASP.NET Settings Schema)》

3.《ASP.NET中的HTTP模組和處理常式》

4. ELMAH首頁

5.《ELMAH的web.config詳細配置（v1.1）》