.Net下幾種日志管理方法
日志是應用程序中不可缺少的一部份，不僅可以記錄應用程序的運行狀態，還可以記錄一些BUG，便於應用程序的更新與修改。
在.Net有好幾種方法可以對日志進行管理。
1、數據庫日志。
2、文本日志。
3、系統事件日志。
首先，對於數據庫日志而言，它的使用簡單而且方便。這裡就不做太多的討論，相信寫過與數據相關的項目的人都會用數據來記錄一些日志。然而它唯一不好的就是：必須先保證你的數據庫鏈接是正確無誤的。
然而這一保證不是必然的，所以這裡我再討論一下其它的兩種情況，文本日志及系統事件日志。
文本日志：
它使用簡單，而且查看也方便。不好的就是不便於做大量的日志，而且日志內容的查看與分析都不方便。然而它還是可在在一些不適合數據庫日志的地方使用。例如一些測試消息的輸出，一些獨立組件的少量日志等。
一般情況下，為了方便管理，以天為單位對日志文件進行分類。這樣一來也可以簡單的對文件進行管理。例如：你的文件名可以知道這個日志是什麼時候的，然後可以簡單的做一個類似數據庫一樣的查詢，管理也還方便。畢竟文本對系統來說是如此的簡單。
.Net有一個診斷類，可以把文本以監聽的方式添加到Trace以及Debug上，這樣一來，你的所有指向Trace和Degug的輸出都會記錄到文件裡去。這是一個很不錯的方法。
using System.Diagnostics;
Debug.Listeners.Add(new System.Diagnostics.TextWriterTraceListener(DateTime.Now.ToString("yyyyMMdd")+"..log"));
Debug.Listeners.Add(new System.Diagnostics.TextWriterTraceListener(Console.Out));
或者：
Trace.Listeners.Add(new System.Diagnostics.TextWriterTraceListener(DateTime.Now.ToString("yyyyMMdd")+"..log"));
Trace.Listeners.Add(new System.Diagnostics.TextWriterTraceListener(Console.Out));
這裡的區別是：Trace在Release下可以使用，而Debug只在Debug下使用。
我覺得所有的文本日志中，上面的方法是最好用的。你只須要再做一個日志管理的類就行了。
當然，還要注意，就是監聽在24小時後要更新一次，應該把當前的監聽清理掉，然後重新添加一個。這也簡單。
另一個方法就是自己寫文本進行管理。這樣的方法要略麻煩一點點，道也不難。
然而文本日志除了不便於做大量日志的工作以還，還有一個致命的問題：進程沖突！
因為文本日志要鎖定正在寫的文本文件，所以其它要寫該文件的程序會出現錯誤。一般情況下，如果應該程序只有一個副本在運行，而且把日志做為一個全局的靜態對象來處理，也不會有什麼太大的問題。但程序的第二個副本會因為文件不能打開而啟動失敗。
這並不是一個無法解決的問題，只用保證程序有一個副本就行了。如果不保證的話，那麼小有一點復雜，這裡就不再討論了，下次有機會再討論這個問題。
對於上面的問題，我想暫時放棄文本日志，用系統的事件日志來處理。
系統事件日志：
.Net下有一個EventLog類，它直接與系統的事件日志關聯。
簡單的一個：
EventLog.WriteEntry("LogSource","This is a test log.");
就可以往系統裡寫一個事件了。
然而把它用好也還有點點麻煩。首先是上面的方法會在系統的Application下寫一個事件日志，而且為默認為Information類型。這樣很不利於管理，大家可以在管理工具裡看一下日志，就會發現大量的日志，自己寫的一個小日志簡直無法找到。
然而.Net為我們提供了幾個方法來更好的管理日志。
1、添加一個新的LogSource。
什麼是LogSource？其實簡單的說，它就是日志的一個分類標記，例如你可以用程序一次取出所以LogSource為指定內容的日志。這樣一來，只要你記得這個Source名，你就可以讀取和分類管理日志了。
默認情況下，你在直接用EventLog的靜態函數寫日志的時候，要指定一個LogSource，如果LogSource不存在，那麼它就自動在Application下建立一個，因此，創建LogSource就這麼簡單了。
2、添加一個新的Log.
什麼是Log.這裡的Log是指系統事件日志裡的大日志分類，一般情況下，系統有Application，System和Sercuity三個日志，每個下面有不同的Soucce，這樣就構成了日志系統。
你不能獨立的創建一個Log，因為.Net裡沒有提供任何方法來創建一個Log,只能通過函數：CreateEventSource(string,string)
來創建一個Sourcce，此時如果你這樣做：CreateEventSource("MySource","MyLog");
你就會在日志管理器裡看到多了一個MyLog類，然而再這樣寫日志：
EventLog.WriteEntry("MySource","This is a test log.");
就可以寫一條記錄到MyLog分類下，這樣就可以很好的管理自己的日志了。
需要說明的是：
如果Source已經存在，那麼創建會失敗。注意：不管Source的哪個Log下，只要Source的名字已經存在，那麼你的創建都會失敗。例如：如果有一個"Source1"的日志在Application裡，那麼你就不能再到其它Log裡再創建一個名為"Source1"的日志了。另外：你用程序創建的日志不能在日志管理器裡刪除它（Messages可以刪除，但日志分類不能刪除）。方法是你還是用程序可以來刪除，或者在注冊表裡來刪除它。它的位置：[HKEY_LOCAL_MacHINE\SYSTEM\CurrentControlSet\Services\Eventlog\]
看一下注冊表，或許你會明白一些。
最後就是用日志實例對象來寫日志。你可以指定一個Log名和一個Source名來寫日志，但要注意，必須是Log與Source匹配，否則也會出現錯誤。這比直接用靜態方法來寫日志要復雜一點點，但你有更多的自由空間。
系統事件日志不好的地方就是日志只保存三個月，而且不好管理。如果你可以直接管理服務器，或者就在本機上運行應該會好一些，否則你就不得不自己寫些代碼來管理日志了。當然，如果一些重要的日志，可以導出到其它文件中。
它的好處是很多的：
1、不必與數據庫鏈接，效率會高一些，也不會有數據庫訪問失敗的問題。
2、不會有進程沖突問題，它是系統的日志，不管是什麼應用程序都可以寫日志。
3、全局可用，不管在哪裡都可以直接寫日志，而且可讀。因此可以把它當成一個消息通信平台。（當然，可能只有那些大腦有點問題的人會這樣做。）然而我只是想說明：A進程寫的日志，B進程可以直接讀取。
好了，關於日志這次就總結這些。
http://www.cnblogs.com/WuCountry/archive/2006/08/22/483090.Html
