2011-01-23 72 views

回答

89

這裏有這麼多類似的問題:

您錯過了幾個常用的日誌框架。下面是常用的框架的列表,其中您列舉了一些:

記錄抽象:

系統。診斷插件:

其他

CodePlex從一對夫婦的其他日誌框架(我見過他提到重新上SO):

你爲什麼會選擇一個比其他?這是一個艱難的。很多都是個人喜好。其中一些是技術(或功能)優勢。

任何日誌框架(特別是第三方日誌框架)的一個明顯缺點是支持的質量。如果您遇到log4net,NLog,Common.Logging等問題會怎麼樣?你能從這些框架的開發者那裏得到解決嗎?這可能不是非常重要,因爲源代碼可用於這些框架。但是,您可能不希望「繼承」源代碼樹,只是爲了修復或添加增強功能。我會說框架是如此可擴展的,許多增強功能可以通過正常的擴展點添加。

如果您閱讀了我上面發佈的鏈接,我認爲僅僅根據有利提及的數量來說,公平地說log4net將是明確的「勝利者」。它將被更頻繁地提及爲歷史採伐喜好以及許多人選擇繼續使用的內容。

NLog有它的支持者,雖然它們非常相似,但它似乎並沒有滲透,或者說log4net的「頭腦」意識。 NLog的功能與log4net非常相似,它具有最近經歷了重要開發週期的額外優勢。

企業圖書館經常被吹捧爲一個不錯的選擇,但幾乎同樣被經常吹捧爲可怕的選擇。也許它的一些負面聲譽可能不是很好的早期版本?也許現在更好?

System.Diagnostics通常被推薦爲一個合理的選擇,至少有三個好處:沒有第三方依賴性,很多Microsoft組件都裝有System.Diagnostics,它很容易擴展(大概是添加一些已經存在的功能「免費」在像log4net和NLog的框架中?)。如果您使用System.Diagnostics,我認爲共識將(如我的建議)使用TraceSource對象而不是Trace.WriteLine/Debug.WriteLine。

還要注意System.Diagnostics和WCF一起工作良好。可以使用System.Diagnostics記錄WCF消息流量,並且WCF還會跨WCF服務邊界調用傳播System.Diagnostics活動信息(System.Diagnostics.CorrelationManager.ActivityId)。

我不太確定log4net應該繼續保持其最受青睞的狀態。 As has been noted elsewhere here on SO, log4net does not seem to be undergoing a lot of development recently(請注意,我認爲「log4net已經死了」是誇張的),而NLog 2.0目前處於測試階段,預計2011年第一季度的最終版本(更新日期:2011年7月17日的NLog 2.0 was released)。這是否使得NLog成爲比log4net更好的選擇?我不知道,但我認爲,相對而言,NLog在兩者之間進行選擇時至少應該得到同等的考慮,並且可能應該是新開發的推定最喜歡的事情,至少在log4net開發顯示出更多生命跡象之前。

log4net和NLog都提供了非常靈活的配置選項。它們允許您在日誌語句的定義中具有非常精細的粒度(通過爲每種類型定義日誌記錄器的「標準」模式)。它們還允許您開發自己的「日誌記錄目標」對象(log4net Appenders和NLog目標)和「格式化」對象(log4net模式轉換器和NLog LayoutRenderers),從而輕鬆擴展庫。

除了日誌框架選擇外,一些(很多?)倡導通過使用抽象層將應用程序代碼與特定日誌框架的硬依賴關係隔離。這可以採用您實現的自己的ILogger接口的形式,也許在現有的框架之上。將來,您可以通過在不同的框架上實現您的ILogger來更改框架。或者,您可以使用DI/IoC在代碼中注入「ILogger」。許多DI/IoC框架提供了一個內置的ILogger抽象,可以配置爲使用log4net,NLog或企業庫,或者您可以編寫自己的ILogger實現並注入)。誰關心實施是什麼?另一種將代碼與特定日誌框架硬依存的方法是通過使用現有的日誌抽象框架,如Common.Logging或SLF。好處是,您的應用程序不再依賴於特定的日誌記錄框架。然而,有些人會說你剛剛爲另一個(日誌抽象框架)交易了一個依賴項(在日誌框架上)。有關日誌抽象

另外兩個注意事項:

  1. 一個好的日誌抽象應該讓你捕捉來自不同的日誌框架輸出相同的輸出文件。 Common.Logging稱之爲「橋接」。假設您已經使用CommonLogging編寫了一個應用程序,並由NLog支持。現在說您正在使用直接使用log4net編寫的第三方類庫。使用橋接系統,您可以捕獲log4net輸出(通過自定義appender)並通過Common.Logging重新路由它,以便第三方類庫的日誌輸出可以在應用程序日誌輸出的上下文中查看。

  2. 使用日誌抽象還允許您在開發過程中「測試驅動器」日誌框架。你可能會開始認爲log4net是該走的路,但你想讓自己開放嘗試NLog。使用日誌抽象在兩者之間切換相對比較容易。最終,您可以選擇哪種日誌框架,但同時,您可以編寫大量不依賴於特定日誌框架的代碼。

,你可能會選擇在一個又一個框架的另一個原因是在你的工作環境。如果您已經在使用企業庫的一部分,那可能足以推動您使用企業庫日誌記錄。

如果您在Silverlight中開發,該怎麼辦?你可以選擇使用類似Clog - part of Calcium的東西。您也可以選擇使用與Silverlight和WP7兼容的NLog 2.0。

System.Diagnostics插件(Ukadc.Diagnostics,Essential.Diagnostics)。這些本身不是日誌框架。相反,它們表示可用於現有System.Diagnostics框架的有用對象和擴展點的集合。在我看來,最好的事情之一就是每個插件都增加了格式化日誌記錄輸出的能力,類似於如何使用log4net和NLog格式化它。我沒有使用Essential.Diagnostics,但我已經試用了Ukadc.Diagnostics,並認爲它非常酷。編寫自己的「格式化令牌」甚至很容易。

我不知道這是否完全回答了你的問題(反正這個問題相當廣泛),但我認爲這裏有很多值得思考的東西。

+1

+1百萬,感謝您的回答,似乎來自經驗和廣泛的知識! – LamonteCristo 2011-01-24 00:40:58

+5

我想對關閉這個問題進行投票,因爲這已經在SO這裏問過數百次了。但是,您的答案非常好。它確實增加了這裏給出的答案的價值。出於這個原因,沒有投票結束,但爲你+1。 – Steven 2011-01-25 14:25:27

+0

@Steven - 感謝您的客氣話! – wageoghe 2011-01-26 03:46:28

5

我剛剛在VS2010中開始使用log4net,發現它對System.Web有一個依賴......這使它與「.NET xx Client Profile」框架目標不兼容......考慮到某人在這裏發佈了什麼Windows更新使用客戶端配置文件作爲可選的.NET可再發行組件,這意味着如果您想讓代碼在大多數計算機上運行,​​log4net不再是您首選的記錄器......

感謝您其他選項 - 我會檢查出來...

1

我不是log4j或log4net的粉絲。我喜歡java.util.net日誌工具,因此我大部分都是在名爲NetLog的github項目https://github.com/greggwon/NetLog/上重新創建它。隨時提供反饋。我想花點時間在logging.properties文件的liu中放入基於ConfigurationManager的配置。使用java.util.logging,使用命令行屬性設置來指定日誌配置所在的位置總是很容易。如果不使用ConfigurationManager,使用.net會更加痛苦。爲CM提供支持,將爲記錄器和處理程序之間的某些不同關係打開大門,這可能會使某些事情變得更好。

NetLog包含一個EventLogHandler,它將登錄到系統事件日誌。它還有一個Level.EventLog級別設置爲低於「警告」,這將允許您在不使用「警告」或「嚴重」的情況下擁有指定EventLog的命名「級別」。我還有一個TCPSocketHandler,它可以讓你遠程登錄到「日誌記錄」,這樣你就可以在窗口上有一個「尾巴」,沒有「尾巴」程序可用。

3

我想補充微軟的Build 2013大會學到了一些東西:

  • log4net的在重負載下已經寫入文件,主要是因爲這個過程是同步的。在某些情況下可能會出現爭用和超時。這可以使用AppDynamics或任何其他類似的工具進行驗證。

  • NLog沒有在負載情況下實現排隊,IO調用堆棧起來。據微軟稱,ETW使用高效的內核環緩衝區。 .NET 4.5和事件日誌框架結合Semantic Logging Application Bock (AKA SLAB)將使這個更有效率。

0

看看GitHub上的NetLog.Logging包,它是我的創建。它有一個監控應用程序,並遵循java.util.logging API範例,因爲這就是我喜歡使用的。它具有用於訪問「書寫」的自旋鎖,並且鎖持有人在繼續之前寫入排隊的所有記錄,達到極限。這將允許日誌減少基於I/O的爭用並提供良好的折衷。

0

出於某種原因,System.Diagnostics不支持將所有跟蹤輸出定向​​到單個偵聽器的方式。如果您希望將多個源指向同一個偵聽器,則必須按名稱明確列出每個源。

在一個有很多依賴關係的大系統中,你可能不知道所有的來源,你可能不關心。你只是想讓輸出看看下面發生了什麼。必須爲每個源單獨設置偵聽器,使得使用System.Diagnostics難以在大型系統中使用。

log4net不僅支持根級別的appender(偵聽器),還支持分層日誌記錄,允許您將邏輯集的日誌記錄配置爲一個組。在我看來,這使得log4net成爲明智的選擇。

相關問題