Как выбрать стандартную трассировку, Logger.NET, Enterprise Library, log4net или Ukadc.Diagnostics?
Есть ли ситуация, когда один из них более уместен, чем другой?... что бы это было? (ASP.NET, консольное приложение, Azure Cloud, SOHO, Enterprise...)
Каковы преимущества или недостатки?
Я пропустил какие-либо другие основные рамки ведения журнала?
Есть много похожих вопросов здесь на SO:
Вы пропустили несколько обычно используемых каркасов журналов. Вот список часто используемых фреймворков, некоторые из которых вы перечислили:
Регистрация абстракций:
System.Diagnostics дополнения:
Другой
Несколько других каркасов журналирования из 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 хорошо работают вместе. Трафик сообщений WCF может регистрироваться с помощью System.Diagnostics, и WCF также будет распространять информацию о действиях System.Diagnostics(System.Diagnostics.CorrelationManager.ActivityId) через пограничные вызовы службы WCF.
Я не уверен, что log4net должен продолжать сохранять свой наиболее предпочтительный статус. Как уже было отмечено здесь, в SO, log4net, похоже, в последнее время не подвергается большой разработке (обратите внимание, что я думаю, что "log4net мертв" - это преувеличение), в то время как NLog 2.0 в настоящее время находится в бета-версии, а окончательный выпуск ожидается в Q1. 2011 (обновление: NLog 2.0 был выпущен 17 июля 2011 года). Делает ли это NLog явно лучшим выбором, чем log4net? Я не знаю, но я думаю, что, условно говоря, NLog должен получать как минимум одинаковое внимание при выборе между этими двумя и, вероятно, должен быть предполагаемым фаворитом для новой разработки, по крайней мере, до тех пор, пока разработка log4net не покажет больше признаков жизни.
log4net и NLog предлагают очень гибкие параметры конфигурации. Они позволяют вам иметь очень тонкую гранулярность в определении ваших операторов регистрации (по "стандартной" схеме определения регистратора для каждого типа). Они также позволяют легко расширять библиотеки, позволяя вам создавать свои собственные объекты "назначения журналирования" (log4net Appenders и NLog Targets) и объекты "форматирования" (конвертеры шаблонов log4net и NLog LayoutRenderers).
Помимо выбора структуры ведения журнала, некоторые (многие?) Выступают за изоляцию кода вашего приложения от жесткой зависимости от конкретной среды ведения журнала с помощью уровня абстракции. Это может принять форму вашего собственного интерфейса ILogger, который вы реализуете, возможно, поверх существующего фреймворка. В будущем вы могли бы изменить каркас, внедрив свой ILogger в другом каркасе. Или вы можете использовать DI/IoC для добавления "ILogger" в ваш код. Многие инфраструктуры DI/IoC предоставляют встроенную абстракцию ILogger, которую можно настроить на использование log4net, NLog или Enterprise Library или вы можете написать собственную реализацию ILogger и внедрить ее). Кому какое дело до реализации? Другой способ изолировать ваш код от жесткой зависимости от конкретной среды ведения журналов - это использовать существующую структуру абстракции ведения журнала, такую как Common.Logging или SLF. Преимущество заключается в том, что, опять же, ваше приложение не зависит от конкретной структуры ведения журналов. Однако некоторые скажут, что вы только что обменяли одну зависимость (на каркасе логирования) на другую (каркас абстракции логирования).
Еще две заметки о регистрации абстракции:
Хорошая абстракция журналирования должна позволять вам захватывать выходные данные из разных каркасов журналирования в одном выходном файле. Common.Logging называет это "мостом". Допустим, вы написали приложение с использованием Common.Logging, поддержанное NLog. Теперь скажите, что вы используете стороннюю библиотеку классов, которая написана с использованием log4net напрямую. С помощью системы мостов вы можете захватить выходные данные log4net (через настраиваемое приложение) и перенаправить их через Common.Logging, чтобы выходные данные журналов библиотеки сторонних классов можно было просматривать в контексте выходных данных журналов вашего приложения.
Использование абстракции журналирования также позволяет вам тестировать каркасы журналов во время разработки. Вы могли бы начать думать, что log4net - это тот путь, но вы хотите оставить себя открытым для попытки NLog. Используя абстракцию логирования, относительно легко переключаться между ними. В конечном счете, вы можете выбрать, какой каркас журналирования, но в то же время вы смогли написать множество кода, который никак не зависит от конкретной каркаса журналирования.
Другая причина, по которой вы можете выбрать один фреймворк вместо другого, - это среда, в которой вы работаете. Если вы уже используете часть Enterprise Library, этого может быть достаточно, чтобы подтолкнуть вас к использованию ведения журнала Enterprise Library.
Что делать, если вы разрабатываете в Silverlight? Вы можете использовать что-то вроде Clog - часть кальция. Вы также можете использовать NLog 2.0, который совместим с Silverlight и WP7.
Аддоны System.Diagnostics(Ukadc.Diagnostics, Essential.Diagnostics). Это не каркасы журналирования как таковые. Скорее, они представляют собой наборы полезных объектов и точек расширения, которые можно использовать с существующей платформой System.Diagnostics. На мой взгляд, одна из лучших вещей, которую добавляет каждый из этих дополнений, - это возможность форматировать выходные данные журналов, подобно тому, как вы можете форматировать их с помощью log4net и NLog. Я не использовал Essential.Diagnostics, но я экспериментировал с Ukadc.Diagnostics и думаю, что это действительно круто. Даже легко написать свои собственные "токены форматирования".
Я не знаю, полностью ли это ответило на ваш вопрос (который в любом случае довольно широк), но я думаю, что здесь есть много пищи для размышлений.
Я только начал использовать log4net в VS2010 и обнаружил, что он имеет зависимость от System.Web..., что делает его несовместимым с рамкой ".NET xx Client Profile"... Учитывая то, что кто-то здесь опубликовал о Windows Обновление с использованием профиля клиента в качестве распространяемого .NET варианта, это означает, что log4net больше не может быть логином выбора, если вы хотите, чтобы ваш код работал на большинстве машин...
Спасибо за информацию о других параметрах - я буду проверять их...
Просто добавьте несколько вещей, извлеченных из конференции Microsoft Build 2013:
Log4NET при большой нагрузке записывает файл в основном потому, что этот процесс является синхронным. В определенных условиях можно получить конкуренцию и тайм-ауты. Это можно проверить с помощью AppDynamics или любого другого подобного инструмента.
NLog не реализует очередность, поэтому под нагрузкой вызовы IO стекают.
Согласно Microsoft, ETW использует буферы для кольцевых буферов, которые являются высокоэффективными..NET 4.5 и структура журнала событий в сочетании с Сетчаточное приложение Bock (AKA SLAB) сделают это намного более эффективным.
Я не являюсь поклонником log4j или log4net. Мне нравится механизм ведения журнала java.util.net, и поэтому я, по большей части, воссоздал его в проекте github с именем NetLog в https://github.com/greggwon/NetLog/. Не стесняйтесь предоставлять обратную связь. Я пытаюсь сделать некоторое время, чтобы установить конфигурацию на основе ConfigurationManager в файле logging.properties. С помощью java.util.logging всегда было достаточно легко использовать параметры свойств командной строки, чтобы указать, где находился журнал. Это намного больнее с .net, если вы не используете ConfigurationManager. Предоставление поддержки CM, откроет дверь для некоторых разных отношений между регистраторами и обработчиками, которые могут улучшить некоторые вещи.
NetLog включает EventLogHandler, который будет регистрироваться в системном журнале событий. Он также имеет уровень Level.EventLog, установленный чуть ниже "предупреждения", который позволит вам иметь именованный "уровень" для таргетинга на EventLog без использования "WARNING" или "SEVERE". У меня также есть TCPSocketHandler, который позволяет вам подключаться к "протоколированию", чтобы вы могли иметь "хвост" в окнах, без наличия "хвостовой" программы.
Посмотрите на пакет NetLog.Logging на GitHub, это мое творение. У этого есть приложение мониторинга, и следует парадигме API java.util.logging, потому что это то, что я люблю использовать. У него есть прямая блокировка для доступа к "записи", и держатель замка записывает все записи в очереди, вплоть до предела, перед тем как двигаться дальше. Это позволит вести журнал в меньшей степени на основе ввода-вывода на основе конкуренции и обеспечивает хороший компромисс.
По какой-то причине System.Diagnostics не поддерживает способ перенаправления всей трассировки на один прослушиватель. Если вы хотите, чтобы несколько источников были направлены на одного слушателя, вам нужно явно указать каждый источник по имени.
В большой системе со многими зависимостями вы можете не знать всех источников, и вам, вероятно, все равно. Вы просто хотите, чтобы на выходе отображалось, что происходит под обложками. Чтобы индивидуально настроить слушателей для каждого источника, использование System.Diagnostics значительно сложнее в больших системах.
log4net не только поддерживает загрузчик корневого уровня (прослушиватель), но также поддерживает иерархическое ведение журнала, которое позволяет настраивать ведение журнала для логического набора источников как группы. На мой взгляд, это делает log4net понятным выбором.