.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_MACHINESYSTEMCurrentControlSetServicesEventlog]
看一下註冊表，或許你會明白一些。
最後就是用日誌實例物件來寫日誌。你可以指定一個Log名和一個Source名來寫日誌，但要注意，必須是Log與Source匹配，否則也會出現錯誤。這比直接用靜態方法來寫日誌要複雜一點點，但你有更多的自由空間。
系統事件日誌不好的地方就是日誌只保存三個月，而且不好管理。如果你可以直接管理伺服器，或者就在本機上運行應該會好一些，否則你就必須自己寫些程式碼來管理日誌了。當然，如果一些重要的日誌，可以匯出到其它檔案中。
它的好處是很多的：
1.不必與資料庫鏈接，效率會高一些，也不會有資料庫存取失敗的問題。
2.不會有進程衝突問題，它是系統的日誌，不管是什麼應用程式都可以寫日誌。
3.全域可用，不管在哪裡都可以直接寫日誌，而且可讀。因此可以把它當成一個訊息通訊平台。 （當然，可能只有那些大腦有點問題的人會這樣做。）然而我只是想說明：A進程寫的日誌，B進程可以直接讀取。
好了，關於日誌這次就總結這些。
http://www.cnblogs.com/WuCountry/archive/2006/08/22/483090.html