log4net проти Nlog

Хтось має досвід для обох? Як вони складаються один проти одного?

Ми плануємо використовувати один з них для входу в корпоративну програму.

Список літератури:

log4net

nlog

EDIT: У нас немає існуючих залежностей ні nlog, ні log4net.

Нещодавно мені поставили завдання "прототипувати деякий логін" для майбутнього проекту. Я не мав жодного досвіду фреймворків. Я досліджував, пробігав підручники, робив додатки для іграшок тощо в Log4Net, NLog та Enterprise Library протягом декількох днів. Повернулися через 3-4 тижні і склали їх у згуртовану демонстрацію. Сподіваємось, щось із цього вам корисне.

Моя рекомендація для нашого проекту:

1. Використовуйте фасад журналу (наприклад, Common.Logging , SimpleLoggingFacade ), щоб уникнути прямих залежностей.
2. Якщо ми в кінцевому підсумку використовуємо Enterprise Library для інших об'єктів, тоді також використовуємо її для ведення журналів.
3. Якщо ми зрештою використовуємо щось із залежністю від Log4Net, використовуємо Log4Net.
4. Якщо нічого з перерахованого вище, використовуйте NLog. Якому б я віддав перевагу.

На основі цих висновків (думок!):

• Усі 3 рамки здатні і можуть робити деякі складні речі. Ми хочемо якісне рішення, але, чесно кажучи, не потрібні надвисокі показники продуктивності або 60 видів раковин.
• Усі 3 мають дуже схожі базові поняття.
• У кожного є свої цікаві хитрощі, як-от справді вдосконалена маршрутизація, або динамічні назви файлів журналу, обрізка файлів тощо.
• Усі 3 досить добре зафіксовані по-своєму.
• Для повного новобранця, як я, вони були спочатку трохи незграбними. Тут немає різких відмінностей щодо основ. Я здолав це.
• Переглядаючи речі через кілька тижнів, NLog явно було найпростіше відновити. Мені потрібно було зовсім небагато пензлика. З Log4Net мені довелося переглянути кілька онлайн-прикладів, щоб продовжити роботу. З EntLib я відмовився від навчання і робив підручники знову з нуля - я повністю втратив.
• Я не міг зрозуміти, як змусити EntLib робити такі речі, як журнал у базі даних. Це може бути легко, але це було поза моїм часовим обмеженням.
• Log4Net і NLog мають невеликий слід коду. EntLib є спам-файлом, але я все одно використовую фасад над ним.
• Я випадково неправильно налаштував EntLib, і це мені повідомило під час виконання. Log4Net не зробив. У мене не було випадкового неправильного налаштування з NLog.
• EntLib постачається з приємним виглядом редактором app.config, який вам потрібен на 100%. NLog має схему конфігураційного файлу, тому ви отримуєте "інтеліссенс". Log4Net поставляється з нада.

Тож очевидно мені поки що подобається NLog. Недостатньо, щоб використовувати його, незважаючи на те, що є ще одне рішення, доступне.

Ключовим питанням, про яке багато не говорилося, є підтримка та оновлення.

Log4Net не оновлювався з моменту опублікування версії 1.2.10 19 квітня 2006 року .

На відміну від цього, NLog активно підтримується з 2006 року, незабаром випустить NLog 2.0, що підтримує багато платформ, які не існували, коли log4net востаннє оновлювався, наприклад:

• NET Framework 2.0 SP1 та вище, 3.5 та 4.0 (клієнтські та розширені профілі)
• Silverlight 2.0, 3.0, 4.0
• .NET Compact Framework 2.0, 3.5
• Моно 2.x профіль

Нещодавно маючи досвід роботи з обома рамками, я думав, що можу поділитися своїми поглядами на кожен кадр.

Мене попросили оцінити рамки ведення журналів для існуючого веб-додатку, після перегляду різних форумів в Інтернеті я звузив свій вибір до NLog (v2.0) та log4net (v1.2.11). Ось мої висновки:

1. Налаштування / запуск з NLog - мертвий легко. Ви пройдете навчальний посібник "Початок роботи" на їхньому веб-сайті, і ви закінчили. Ви отримуєте справедливе уявлення, як може бути з nlog. Файл Config настільки інтуїтивний, що кожен може зрозуміти конфігурацію. Наприклад: якщо ви хочете встановити внутрішній вхід у систему, ви встановите прапор у вузлі заголовка файлу конфігураційного файлу Nlog, саме там ви б очікували його. У log4net ви встановлюєте різні прапори в розділі Налаштування web.config.

2. У log4net внутрішній журнал не виводить часові позначки часу, що дратує. У Nlog ви отримуєте приємний журнал із мітками часу. Я вважав це дуже корисним у своїх оцінках.

3. Фільтри в log4net - Ви краще перевірте моє запитання - фільтр log4net - як писати І фільтрувати, щоб ігнорувати повідомлення журналу, і якщо ви знайдете відповідь / рішення на це, будь ласка, повідомте мене. Я розумію, для цього питання є вирішення, оскільки ви можете написати власний спеціальний фільтр. Але те, що не так легко доступно в log4net.

4. Продуктивність - я зареєстрував близько 3000 журнальних повідомлень у базі даних за допомогою збереженої процедури. Я використовував простий цикл (int i = 0; i <3000; i ++ ..., щоб записати одне і те ж повідомлення 3000 разів. Для write: log4net AdoAppender зайняв майже вдвічі більше часу, ніж NLog.

5. Log4net не підтримує асинхронний додаток.

Для мене було достатньо порівняння, щоб обрати NLog як рамку ведення журналу. :)

Для всіх, хто запізниться на цю тему пізно, ви можете заглянути в бібліотеку базових класів .Net (BCL). Багато людей пропустили зміни між .Net 1.1 та .Net 2.0, коли був представлений клас TraceSource (близько 2005 р.).

Використання TraceSource є аналогічним іншим структурам реєстрації журналів, із детальним контролем ведення журналів, конфігурацією в app.config / web.config та програмним доступом - без накладних витрат блоку додатків підприємства.

• .Net Блог команди BCL: Вступ до відстеження - частина I (подивіться також частину II a, b, c)

Також існує ряд порівнянь: "log4net проти TraceSource"

Для нас ключова відмінність полягає в загальному ...

Погляньте на Logger.IsDebugEnabledNLog порівняно з Log4Net, з наших тестів, NLog має менші накладні витрати, і це те, що ми шукаємо (з низькою затримкою).

Ура, Флоріан

Спочатку подивіться на решту вашої стеки.

Якщо ви використовуєте NHibernate, він використовує Log4Net безпосередньо. Інші рамки можуть мати інші необхідні реєстратори.

Крім цього: обидва працюють добре.

Я влаштувався на Log4Net сам. Конфігурувати це може боляче, і якщо він не налаштований правильно, це зрозуміти, що пішло не так. Але ви можете змусити його робити майже все, що завгодно від лісоруба.

Якщо у вас немає постійної проблеми з Log4Net, ось статтю, яку я написав про те, як розпочати роботу, написав: http://elegantcode.com/2007/12/07/getting-started-with-log4net/

Ну .. Я використовував бібліотеку Enterprise для завдань з реєстрації баз даних і тепер перейшов на NLog через вузьке місце продуктивності.

деяка інформація порівняння:

http://pauliusraila.blogspot.com/2010/10/solving-database-logging-bottlenecks.html

Я повторюю вищезгадане і віддаю перевагу nLog. Ентліб непотрібно роздутий.

Re: Log4net Одне, що ВИНАГО отримує мене з log4net, це забути додати наступне до global.asax, щоб запустити компонент:

log4net.Config.XmlConfigurator.Configure();

Якщо ви зайшли сюди, ви можете знайти вичерпну матрицю, яка включає в себе як вкладки NLog і Log4Net, так і Enterprise Lib та інші продукти.

Хтось може заперечити, що матриця зроблена таким чином, щоб підкреслити особливості єдиної комерційної вкладки, присутньої в матриці. Я думаю, що це правда, але все одно було корисно керувати моїм вибором проти NLog.

З повагою

Як я помітив, log4net блокує свої вихідні файли весь час запуску програми, тому ви не можете їх видалити. Інакше вони схожі.

Тому я віддаю перевагу NLog.

Безсоромний модуль для проекту з відкритим кодом, який я запускаю, але, з огляду на жваву дискусію про те, яка система .NET журналу є більш активною, я подумав, що опублікую обов'язкове посилання на Serilog .

Для використання в програмі Serilog схожий на (і сильно залучається) log4net. Однак, на відміну від інших параметрів журналу .NET, Serilog полягає в збереженні структури подій журналу для офлайн-аналізу. Коли ви пишете:

Log.Information("The answer is {Answer}", 42);

Більшість бібліотек реєстрації негайно передають повідомлення в рядок. Serilog також може це зробити, але він зберігає { Answer: 42 }властивість, щоб згодом, використовуючи один із ряду сховищ даних NoSQL, можна правильно запитувати події на основі значення Answer.

Ми близькі до 1,0 та підтримуємо всі сучасні (.NET 4.5, Windows Store та Windows Phone 8) платформи.

Я також другий NLog, тому що він працює і з некерованим кодом. Я припускаю, що можливо використовувати разом log4net та log4cxx, але NLog обробляє як керований, так і некерований код поза коробкою.

Я також подивився на Common.Logging , фасад, який робить абстракцію журналу api, він підтримує log4net, NLog та Entreprise Library. Я не думаю, що я його використовуватиму, але мені подобається, як вони використовують лямбдати для підвищення продуктивності, коли журнал вимкнено (функція, що ділиться з NLog та, ймовірно, іншими).

Ви також можете розглянути блок реєстрації бібліотеки Microsoft Enterprise . Він поставляється з приємним дизайнером.

Я думаю, що загальний консенсус полягає в тому, що nlog трохи простіше в налаштуванні та використанні. Обидва цілком здатні.

Виходячи з мого досвіду, SmartInspect перемагає як NLog, так і log4net.

Його надзвичайно проста у використанні, документація чудова, і ви можете переглядати та фільтрувати раніше зареєстровані повідомлення за допомогою їх інтерактивного переглядача журналів, що є величезною перевагою у реальному світі.

Одне, що мені подобається, це перегляд даних на вкладках, як вкладки браузера в Chrome. Кожна вкладка може надавати інший відфільтрований вигляд журналу.