[.net] log4net против TraceSource


Answers

В самом начале (.NET 1.0) трассировка в .NET Framework была довольно ограниченной.

Например, разбиение на TraceSource произошло не до .NET 2.0, и у вас было только четыре уровня (ошибка, предупреждение, информация, подробный), хотя вы могли бы использовать полдюжины булевых переключателей для разбиения на разделы, если хотите.

log4j популярен в Java и поэтому получил большую поддержку для .NET-порта, и как только он стал популярен, он остался таким, хотя люди даже не используют его должным образом (например, обертывая его в однотонный регистратор и теряя это главная особенность).

Тем не менее, я думаю, что log4net и другие фреймворки (например, NLog, Common.Logging и даже EntLib) пошли не так, реализовав свою собственную систему ведения журнала с нуля, то есть изменив даже то, как вы пишете записи журнала в первую очередь.

Я бы предпочел увидеть усилие, особенно с .NET 2.0, чтобы расширить прочную основу того, что уже есть в .NET. Для проекта, который расширяет то, что уже существует, посмотрите проект Essential Diagnostics на CodePlex ( http://essentialdiagnostics.codeplex.com/ ).

Некоторые преимущества log4net:

  • Он похож на log4j, если вы запускаете смешанную среду и хотите согласовать протоколирование.

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

  • log4net уже имеет около 28 добавлений (что эквивалентно прослушивателям трассировки), тогда как System.Diagnostics имеет только 10 (но больше для проекта Essential.Diagnostics), поэтому, если вы действительно думаете, что вам может понадобиться RemoteSyslogAppender, NetSendAppender, AnsiColorTerminalAppender или TelnetAppender, тогда вам повезло.

Недостатки (по сравнению с System.Diagnostics):

  • Вам нужно использовать другой синтаксис ведения журнала, поэтому, если вы уже используете source.TraceEvent (), вам нужно пройти и заменить все.

  • Это также распространяется на различный синтаксис для корреляции, поэтому вам нужно перейти из контекста CorrelationManager в log4net.

  • Не легко интегрируется с трассировкой Framework (например, WCF).

  • Плохая поддержка идентификатора события (необходимо использовать отдельный проект расширения IEventLog).

  • Пока не поддерживает трассировку событий для Windows (Vista) или XML-формат Service Trace Viewer.

Question

В этой теме многие люди указали, что они используют log4net. Я поклонник TraceSources и хотел бы знать, почему используется log4net.

Вот почему мне нравятся источники трассировки:

  • Подключаемые слушатели - XML, TextFile, Консоль, EventLog, сворачивают ваши собственные
  • Настраиваемые переключатели трассировки (ошибка, предупреждение, информация, подробный, начальный, конечный, пользовательский)
  • Настраиваемая конфигурация
  • Блок приложений регистрации - это просто большой набор TraceListeners
  • Корреляция действий / областей (например, связывать все журналы в запросе ASP.NET с данным клиентом
  • Служба Trace Viewer позволяет визуализировать события в отношении этих действий индивидуально
  • Все это настраивается в app.config / web.config.

Поскольку среда .NET внутренне использует TraceSources, она также дает мне последовательный способ настройки трассировки - с log4net, мне нужно настроить log4net, а также TraceSources.

Что делает log4net для меня, что TraceSources не делают (или это невозможно сделать, написав пару пользовательских TraceListeners)?




Причина, по которой я предпочитаю Log4Net использовать Trace для одного из таргетинга - с Log4Net, я могу независимо управлять различными слоями моего приложения (Data Access, Services, Business Logic и т. Д.) И различными подсистемами (аутентификация, обработка и т. Д.) И включать / независимо от регистрации каждой подсистемы.

Этот flexibilty позволяет мне настроить подробное ведение журнала для одной подсистемы без включения пожарной машины для всей системы.

Статические методы, предоставляемые в классе Trace [такие как TraceInformation ()], не дают возможности указать, из какой подсистемы происходит ведение журнала, поэтому это нелегко предоставить, написав собственный TraceListener.

Другая причина - производительность - есть часть моего приложения, которое может регистрировать несколько тысяч сообщений в секунду. Log4Net накладывает небольшие накладные расходы. В отличие от этого, в прошлый раз, когда я посмотрел на него, блок приложения Logging Application перефразировал его конфигурацию XML для каждого зарегистрированного сообщения, что сделало блок очень тяжелым и медленным.