log4net против Nlog

У кого-нибудь есть опыт для обоих? Как они складываются друг против друга?

Мы планируем использовать один из них для входа в корпоративное приложение.

Рекомендации:

log4net

Nlog

EDIT: у нас нет существующих зависимостей ни nlog, ни log4net.

    Недавно мне было поручено «прототип некоторого loggin» для предстоящего проекта. У меня не было никакого опыта работы с журналами. Я исследовал, прошел через учебные пособия, сделал игрушечные приложения и т. Д. В Log4Net, NLog и корпоративной библиотеке в течение нескольких дней. Вернулись 3-4 недели спустя и объединили их в сплоченную демонстрацию. Надеюсь, некоторые из них вам полезны.

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

    1. Используйте faq logging (например, Common.Logging , SimpleLoggingFacade ), чтобы избежать прямых зависимостей.
    2. Если мы закончим использование Enterprise Library для других объектов, то также используйте его для ведения журнала.
    3. Если мы закончим использование чего-то с зависимостью от Log4Net, используйте Log4Net.
    4. Если ничего из вышеперечисленного, используйте NLog. Который я бы предпочел.

    Это основано на этих выводах (мнения!):

    • Все 3 фреймворка способны и могут выполнять некоторые сложные вещи. Мы хотим получить качественное решение, но, откровенно говоря, не нужны ультравысокая производительность или 60 типов приемников событий.
    • Все 3 имеют очень похожие базовые понятия.
    • Каждый из них имеет свои собственные интересные трюки, такие как действительно расширенная маршрутизация, или динамические имена файлов журналов, усечение файлов и т. Д.
    • Все 3 довольно хорошо документированы по-своему.
    • Для полного newb как я, они были все немного неудобно изначально. Здесь нет существенных различий по основам. Я справился с этим.
    • Когда несколько недель спустя пересматривали вещи, NLog, безусловно, легче всего возобновить. Мне нужно было немного почистить его. С Log4Net мне пришлось пересмотреть несколько онлайн-примеров, чтобы начать работу. С EntLib я сдался и делал уроки снова и снова с нуля – я был полностью потерян.
    • Я не мог понять, как заставить EntLib делать такие вещи, как журнал в базе данных. Это может быть легко, но это было за пределами моего срока.
    • Log4Net и NLog имеют небольшой внутренний код. EntLib спам, но я бы использовал фасад над ним.
    • Я случайно неправильно сконфигурировал EntLib, и он сказал мне во время работы. Log4Net этого не сделал. У меня не было случайной неправильной конфигурации с NLog.
    • EntLib поставляется с красивым редактором app.config, который вам нужен на 100%. NLog имеет схему файла конфигурации, поэтому вы получаете «intellisense». 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
    • Профиль пользователя Mono 2.x

    Имея опыт работы с обоими структурами в последнее время, я думал, что могу поделиться своими взглядами на каждую структуру.

    Мне было предложено оценить frameworks ведения журнала для существующего веб-приложения, я сузил свой выбор до 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 раз. Для записей: log4net AdoAppender занял почти вдвое больше времени, чем NLog.

    5. Log4net не поддерживает asynchronous appender.

    Для меня было достаточно сравнения, чтобы выбрать NLog в качестве frameworks ведения журнала. 🙂

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

    Использование TraceSource аналогично другим фреймворкам регистрации, с гранулированным управлением протоколированием, настройкой в ​​app.config / web.config и программным доступом – без накладных расходов на блок корпоративного приложения.

    • .Net BCL Team Blog: введение в отслеживание – часть I (см. Также часть II а, b, c)

    Также существует ряд сравнений: «log4net vs TraceSource»,

    Для нас ключевое различие заключается в общем …

    Посмотрите на Logger.IsDebugEnabled в NLog по сравнению с Log4Net, из наших тестов NLog имеет меньше накладных расходов, и это то, что мы делаем (материал с низкой задержкой).

    Приветствия, Флориан

    Сначала посмотрите на остальную часть вашего стека.

    Если вы используете NHibernate, он использует Log4Net напрямую. Другие структуры могут иметь другие специфические регистраторы, в которых они нуждаются.

    Кроме этого: обе работают нормально.

    Я сам сам поступил на Log4Net. Это может быть болью для настройки, и если она не настроена правильно, это боль, чтобы понять, что пошло не так. Но вы можете заставить его делать почти все, что вы захотите от регистратора.

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

    Ну .. Я использовал Enterprise library для задач регистрации базы данных, и теперь я переключился на NLog из-за узкого места производительности.

    некоторые данные сравнения:

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

    Я повторяю выше и предпочитаю nLog. Entlib бесполезно раздувается.

    Re: Log4net Одна вещь, которая ВСЕГДА получает меня с log4net, забывает добавить следующее в global.asax для инициализации компонента:

     log4net.Config.XmlConfigurator.Configure(); 

    Если вы перейдете сюда, вы найдете исчерпывающую матрицу, содержащую как библиотеки NLog, так и Log4Net, а также Enterprise Lib и другие продукты.

    Кто-то может утверждать, что matrix выполнена таким образом, чтобы подчеркнуть особенности единственной коммерческой библиотеки, присутствующей в матрице. Я думаю, что это правда, но было полезно в любом случае управлять моим выбором против 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. Я не думаю, что буду использовать его, но мне нравится, как они используют lambdas для повышения производительности при отключении журнала (функция, совместно используемая NLog и, возможно, другие).

    Вы также можете рассмотреть блок регистрации Microsoft Enterprise Library . Он поставляется с хорошим дизайнером.

    Я считаю, что общий консенсус в том, что nlog немного проще настроить и использовать. Оба они вполне способны.

    Основываясь на моем опыте, SmartInspect превосходит как NLog, так и log4net.

    Его чрезвычайно простая в использовании документация отличная, и вы можете просматривать и фильтровать ранее записанные сообщения с помощью своего интерактивного просмотра журналов, что является огромным преимуществом в реальном мире.

    Одна вещь, которая мне нравится, – это вкладки с данными в виде вкладок, например вкладки браузера в Chrome. Каждая вкладка может предоставить различный отфильтрованный вид журнала.

    Давайте будем гением компьютера.