Khi nào tôi nên sử dụng Truy tìm vs Logger.NET, Thư viện doanh nghiệp, log4net hoặc Ukadc.Diagnostics?

Question

Làm cách nào để chọn giữa truy tìm chuẩn, Logger.NET, Thư viện doanh nghiệp, log4net hoặc Ukadc.Diagnostics?

Có tình huống nào phù hợp hơn trường hợp khác không? ... đó là gì? (ASP.NET, giao diện điều khiển ứng dụng, Azure Cloud, SOHO, Enterprise ...)

Lợi ích hoặc hạn chế là gì?

Tôi có bỏ lỡ bất kỳ khung khai thác gỗ lớn nào khác không?

Answer 1

Có rất nhiều câu hỏi tương tự ở đây trên SO:

• Logging best practices
• log4net versus TraceSource
• Silverlight Logging framework and/or best practices
• log4net vs. Nlog
• What's the point of a logging facade?
• C# Logging. What should I use?

Bạn đã bỏ lỡ một số khung đăng nhập thường được sử dụng. Dưới đây là danh sách các khuôn khổ thường được sử dụng, một số trong đó bạn liệt kê:

• System.Diagnostics
• log4net
• NLog
• doanh nghiệp Thư viện trừu tượng
• The Object Guy

Logging:

• Common.Logging
• SLF

System.Chẩn đoán addons:

• Ukadc.Dianostics
• Essential.Diagnostics

khác

• Elmah

Một vài khung đăng nhập khác từ CodePlex (mà tôi đã thấy đề cập ông lại trên SO):

• CuttingEdge.Logging
• SpringTail

Tại sao bạn có thể chọn một trong khác không? Đó là một trong những khó khăn. Rất nhiều nó là sở thích cá nhân. Một số trong đó là ưu thế kỹ thuật (hoặc tính năng).

Một nhược điểm rõ ràng của bất kỳ khung đăng nhập nào (đặc biệt là khung công tác của bên thứ ba) là chất lượng hỗ trợ. Điều gì xảy ra nếu bạn gặp vấn đề với log4net, NLog, Common.Logging, v.v ...? Bạn sẽ có thể nhận được một sửa chữa từ các nhà phát triển của những khuôn khổ? Điều này có thể không quan trọng lắm vì mã nguồn có sẵn cho các khuôn khổ này. Tuy nhiên, bạn có thể không muốn "kế thừa" cây nguồn chỉ để sửa lỗi hoặc thêm phần nâng cao. Tôi sẽ nói rằng các khung công tác có thể mở rộng, có thể thêm nhiều cải tiến thông qua các điểm mở rộng thông thường.

Nếu bạn đọc các liên kết mà tôi đăng ở trên, tôi nghĩ rằng nó là công bằng để nói, chỉ dựa trên khối lượng đề cập thuận lợi, rằng log4net sẽ là "người chiến thắng" rõ ràng. Nó sẽ được đề cập thường xuyên hơn là yêu thích lịch sử khai thác gỗ và những gì nhiều người sẽ chọn để sử dụng trong tương lai.

NLog có những người ủng hộ, nó dường như không có sự thâm nhập hay nhận thức "đầu óc" mà log4net thực hiện, mặc dù chúng rất giống nhau. Các khả năng của NLog rất giống với log4net và nó có thêm lợi thế là đã trải qua một chu kỳ phát triển đáng kể gần đây.

Thư viện doanh nghiệp thường được chọn là một lựa chọn tốt, nhưng gần như bằng nhau thường được coi là lựa chọn khủng khiếp. Có lẽ một số danh tiếng tiêu cực của nó có lẽ không phải là phiên bản đầu tiên tốt như vậy? Có lẽ nó tốt hơn bây giờ?

System.Diagnostics thường được khuyến nghị là một lựa chọn hợp lý với ít nhất ba lợi ích: không phụ thuộc bên thứ ba, nhiều thành phần của Microsoft được trang bị System.Diagnostics, nó có thể dễ dàng mở rộng (có lẽ để thêm một số khả năng đã có "miễn phí" trong các khung công tác như log4net và NLog?). Nếu bạn sử dụng System.Diagnostics, tôi nghĩ sự đồng thuận sẽ là (như đề xuất của tôi) để sử dụng các đối tượng TraceSource hơn là Trace.WriteLine/Debug.WriteLine.

Cũng lưu ý rằng System.Diagnostics và WCF hoạt động tốt cùng nhau. Lưu lượng tin nhắn WCF có thể được ghi lại với System.Diagnostics và WCF cũng sẽ truyền bá thông tin hoạt động System.Diagnostics (System.Diagnostics.CorrelationManager.ActivityId) qua các cuộc gọi ranh giới dịch vụ WCF.

Tôi không chắc chắn rằng log4net sẽ tiếp tục giữ lại trạng thái ưa thích nhất của nó. As has been noted elsewhere here on SO, log4net does not seem to be undergoing a lot of development recently (lưu ý rằng tôi nghĩ "log4net đã chết" là cường điệu) trong khi NLog 2.0 hiện đang ở giai đoạn beta với bản phát hành cuối cùng dự kiến ​​trong Q1 2011 (Cập nhật: NLog 2.0 was released vào ngày 17 tháng 7 năm 2011).Điều này làm cho NLog trở thành một lựa chọn rõ ràng hơn log4net? Tôi không biết, nhưng tôi nghĩ rằng, tương đối nói, NLog sẽ nhận được ít nhất bằng cân nhắc khi lựa chọn giữa hai và, có lẽ, nên được coi là yêu thích cho phát triển mới, ít nhất là cho đến khi phát triển log4net cho thấy nhiều dấu hiệu của cuộc sống.

log4net và NLog đều cung cấp các tùy chọn cấu hình rất linh hoạt. Chúng cho phép bạn có độ chi tiết rất tốt trong định nghĩa các câu lệnh ghi nhật ký của bạn (theo mẫu "chuẩn" định nghĩa một trình ghi nhật ký cho mỗi loại). Chúng cũng cho phép bạn mở rộng các thư viện một cách dễ dàng bằng cách cho phép bạn phát triển các đối tượng "đích đến ghi" của riêng bạn (các đối tượng log4net và các mục tiêu NLog) và các đối tượng "định dạng" (các trình chuyển đổi mẫu log4net và các Trình sắp xếp NLog).

Bên cạnh lựa chọn khung ghi nhật ký, một số người (nhiều?) Ủng hộ cách mã ứng dụng của bạn từ sự phụ thuộc cứng trên một khung khai thác cụ thể bằng cách sử dụng lớp trừu tượng. Điều này có thể mang hình thức giao diện ILogger của riêng bạn mà bạn thực hiện, có lẽ trên đầu khung công tác hiện có. Trong tương lai, bạn có thể thay đổi các khung công tác bằng cách thực hiện ILogger của bạn trên một khung công tác khác. Hoặc, bạn có thể sử dụng DI/IoC để tiêm "ILogger" vào mã của bạn. Nhiều khung công tác DI/IoC cung cấp khả năng trừu tượng hóa ILogger có thể được cấu hình để sử dụng log4net, NLog hoặc Enterprise Library hoặc bạn có thể viết thực thi ILogger của riêng mình và tiêm nó). Ai quan tâm những gì thực hiện là? Một cách khác để cách ly mã của bạn khỏi việc có sự phụ thuộc cứng vào một khung khai thác gỗ cụ thể là thông qua việc sử dụng khung trừu tượng khai thác gỗ hiện có như Common.Logging hoặc SLF. Lợi ích là, một lần nữa, ứng dụng của bạn không phụ thuộc vào một khung khai thác cụ thể. Tuy nhiên, một số sẽ nói rằng bạn vừa giao dịch một phụ thuộc (trên một khung khai thác gỗ) cho một khung công tác khác (khai thác khung trừu tượng).

hơn Hai lưu ý về khai thác gỗ trừu tượng:

1. Một logging trừu tượng tốt nên cho phép bạn chụp ra từ khung đăng nhập khác nhau trong các tập tin đầu ra tương tự. Common.Logging gọi "cầu nối" này. Giả sử bạn đã viết một ứng dụng bằng Common.Logging, được hỗ trợ bởi NLog. Bây giờ nói rằng bạn đang sử dụng thư viện lớp của bên thứ ba được viết trực tiếp bằng cách sử dụng log4net. Với hệ thống cầu nối, bạn có thể thu được đầu ra log4net (thông qua một appender tùy chỉnh) và định tuyến lại nó thông qua Common.Logging để có thể xem đầu ra của thư viện lớp bên thứ ba trong ngữ cảnh đầu ra của ứng dụng của bạn.

2. Sử dụng tính trừu tượng khai thác gỗ cũng cho phép bạn "kiểm tra ổ đĩa" khung nhật ký trong khi phát triển. Bạn có thể bắt đầu nghĩ rằng log4net là như vậy để đi, nhưng bạn muốn để cho mình mở để thử NLog. Bằng cách sử dụng một trừu tượng khai thác gỗ, nó là tương đối dễ dàng để chuyển đổi giữa hai. Cuối cùng, bạn có thể lựa chọn khung công tác ghi nhật ký nào, nhưng trong thời gian chờ đợi, bạn có thể viết các mã của mã KHÔNG phụ thuộc vào bất kỳ cách nào trên một khung khai thác gỗ cụ thể.

Một lý do khác khiến bạn có thể chọn một khuôn khổ so với môi trường khác là môi trường bạn làm việc. Nếu bạn đã sử dụng một phần của Thư viện Doanh nghiệp, điều đó có thể đủ để đẩy bạn vào việc sử dụng ghi nhật ký Thư viện Doanh nghiệp.

Điều gì xảy ra nếu bạn đang phát triển trong Silverlight? Bạn có thể chọn sử dụng một cái gì đó như Clog - part of Calcium. Bạn cũng có thể chọn sử dụng NLog 2.0, tương thích với Silverlight và WP7.

System.Diagnostics addons (Ukadc.Diagnostics, Essential.Diagnostics). Đây không phải là khung công tác đăng nhập mỗi lần. Thay vào đó, chúng đại diện cho các bộ sưu tập các đối tượng hữu ích và các điểm mở rộng có thể được sử dụng với khung System.Diagnostics hiện có. Một trong những điều tốt nhất, theo ý kiến ​​của tôi, rằng mỗi addons bổ sung này là khả năng định dạng đầu ra ghi nhật ký của bạn, tương tự như cách bạn có thể định dạng nó với log4net và NLog.Tôi đã không sử dụng Essential.Diagnostics, nhưng tôi đã thử nghiệm với Ukadc.Diagnostics và nghĩ rằng nó thực sự là mát mẻ. Nó thậm chí còn dễ dàng để viết "mã thông báo định dạng" của riêng bạn.

Tôi không biết nếu điều này hoàn toàn trả lời câu hỏi của bạn (dù đó là khá rộng), nhưng tôi nghĩ rằng có rất nhiều thực phẩm cho suy nghĩ ở đây.

Answer 2

Tôi vừa mới bắt đầu sử dụng log4net trong VS2010 và phát hiện ra rằng nó có sự phụ thuộc vào System.Web ... làm cho nó không tương thích với các mục tiêu khung ".NET xx Client Profile" ... Xem xét những gì ai đó đã đăng Cập nhật Windows bằng cách sử dụng Hồ sơ khách hàng dưới dạng .NET phân phối lại lựa chọn, điều này có nghĩa là log4net có thể không còn là trình ghi nhật ký lựa chọn nếu bạn muốn mã của bạn chạy trên phần lớn các máy ...

Cảm ơn thông tin trên các tùy chọn khác - Tôi sẽ kiểm tra xem chúng ...

Answer 3

Tôi không phải là người hâm mộ của log4j hoặc log4net. Tôi thích tiện ích ghi nhật ký java.util.net, và vì vậy tôi đã tạo lại nó, cho hầu hết các phần, về dự án github có tên NetLog tại https://github.com/greggwon/NetLog/. Vui lòng cung cấp phản hồi. Tôi đang cố gắng dành chút thời gian để đưa vào cấu hình dựa trên ConfigurationManager trong một tệp tin logging.properties. Với java.util.logging, nó luôn luôn dễ dàng, đủ để sử dụng các thiết lập thuộc tính dòng lệnh để xác định nơi cấu hình đăng nhập đã ở. Nó sẽ đau đớn hơn rất nhiều với .net, nếu bạn không sử dụng ConfigurationManager. Cung cấp hỗ trợ cho CM, sẽ mở cửa cho một số mối quan hệ khác nhau giữa logger và xử lý mà có thể làm cho một số điều tốt hơn.

NetLog bao gồm EventLogHandler sẽ đăng nhập vào systemlog sự kiện. Nó cũng có mức Level.EventLog được đặt ở ngay dưới "cảnh báo" cho phép bạn có một "mức" được đặt tên để nhắm mục tiêu EventLog mà không sử dụng "WARNING" hoặc "SEVERE". Tôi cũng có một TCPSocketHandler cho phép bạn telnet vào "đăng nhập" để bạn có thể có một "đuôi" trên cửa sổ, mà không có một "đuôi" chương trình đang có sẵn.

Answer 4

Chỉ cần thêm một vài điều rút ra từ xây dựng hội nghị 2013 của Microsoft:

• log4net dưới tải nặng đã viết vào một tập tin chủ yếu là do quá trình này là đồng bộ. Có thể tranh luận và hết thời gian trong một số điều kiện nhất định. Điều này có thể được xác minh bằng cách sử dụng AppDynamics hoặc bất kỳ công cụ tương tự nào khác.

• NLog không thực hiện xếp hàng để tải, các cuộc gọi IO sẽ xếp chồng lên nhau.

• Theo Microsoft, ETW sử dụng bộ đệm vòng hạt nhân có hiệu quả cao. .NET 4.5 và khung Event Log kết hợp với Semantic Logging Application Bock (AKA SLAB) sẽ làm cho việc này hiệu quả hơn nhiều.

Answer 5

Nhìn vào gói NetLog.Logging trên GitHub, đó là sáng tạo của tôi. Nó có một ứng dụng giám sát, và theo mô hình API java.util.logging, bởi vì đó là những gì tôi muốn sử dụng. Nó có một khóa quay để truy cập vào "viết", và người giữ khóa viết tất cả các bản ghi xếp hàng, lên đến giới hạn, trước khi tiếp tục. Điều này sẽ cho phép đăng nhập để có ít tranh chấp dựa trên I/O và cung cấp một thỏa hiệp tốt.

Answer 6

Vì một số lý do, System.Diagnostics không hỗ trợ cách hướng tất cả đầu ra dấu vết đến một người nghe đơn lẻ. Nếu bạn muốn một số nguồn được chuyển hướng đến cùng một trình nghe, bạn phải liệt kê rõ ràng từng nguồn theo tên.

Trong một hệ thống lớn với nhiều phụ thuộc, bạn có thể không biết tất cả các nguồn và có thể bạn không quan tâm. Bạn chỉ muốn đầu ra để xem những gì đang xảy ra dưới nắp.Việc thiết lập riêng từng người nghe cho từng nguồn sẽ làm cho việc sử dụng System.Diagnostics khó sử dụng hơn trong các hệ thống lớn.

log4net không chỉ hỗ trợ trình cắm thêm cấp độ gốc (trình nghe), nó còn hỗ trợ ghi nhật ký phân cấp cho phép bạn định cấu hình ghi nhật ký cho một nhóm nguồn hợp lý làm nhóm. Trong tâm trí của tôi, điều này làm cho log4net trở thành sự lựa chọn rõ ràng.