Log4net против TraceSource

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

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

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

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

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

Ответ 1

Я думаю, что log4net делает все, что вы указали для меня.

Подключаемые слушатели звучат как приставки - их много, и на самом деле я даже взломал скользящий файл журнала, который всегда заканчивался на .log(для ассоциаций файлов), добавил поле cc к приложению электронной почты и, наконец, настроил мой любимые значения для цветного консольного приложения. Если я могу быть таким смелым - мое цветное счастье консоли:

<appender name="ColoredConsoleAppender" type="log4net.Appender.ColoredConsoleAppender">
<!-- Can Use:
        Blue
        Green
        Red
        White
        Yellow
        Purple
        Cyan
        HighIntensity
        -->
<mapping>
  <level value="FATAL" />
  <foreColor value="Yellow, HighIntensity" />
  <backColor value="Red" />
</mapping>
<mapping>
  <level value="ERROR" />
  <foreColor value="White" />
  <backColor value="Purple, HighIntensity" />
</mapping>
<mapping>
  <level value="WARN" />
  <backColor value="Blue" />
  <foreColor value="White" />
</mapping>
<mapping>
  <level value="INFO" />
  <backColor value="Green" />
  <foreColor value="White" />
</mapping>
<mapping>
  <level value="DEBUG" />
  <foreColor value="White" />
</mapping>
<layout type="log4net.Layout.PatternLayout">
  <!--<conversionPattern value="%date [%thread] %-5level %logger [%property{NDC}] - %message%newline" />-->
  <!--<conversionPattern value="%-5level %file:%line - %message%newline" />-->
  <conversionPattern value="%level %logger:%line %newline     %message%newline" />
</layout>

Настраиваемые переключатели трассировки: Log4net поставляется с FATAL ERROR WARN INFO DEBUG в порядке увеличения детализации. Единственное, что я действительно пропустил, - это AUDIT для тех, кто сделал-что записывал.

Настраиваемая конфигурация: я использую файл log4net.config, который загружаю во время выполнения (или записываю журнал в c:\whining, что я не могу найти конфигурацию.)

    Try
        ' Get log4net configuration from file
        Dim logConfigFile As FileInfo
        logConfigFile = New FileInfo(".\log4net.config")

        If logConfigFile.Exists Then
            XmlConfigurator.Configure(logConfigFile)
        Else
            CreateEmergenceLogFile(logConfigFile.FullName)
        End If

    Catch ex As Exception
        Console.Out.WriteLine("Could not load the log4net config file")
    End Try

просто большой набор TraceListeners: извините, пропустив это - я возьму ваше слово для этого.

Соотношение действий/областей: вы имеете в виду, что каждый файл (класс чтения) получает его собственный именованный журнал, который может иметь отдельные пороги уровня журнала. На самом деле вы можете сегментировать записи даже в одном классе (это, по правде говоря, может увеличиться, чтобы сделать слишком много...)

В файле класса:

    Private Shared _logger As log4net.ILog = _
log4net.LogManager.GetLogger(System.Reflection.MethodBase.GetCurrentMethod().DeclaringType)

Private Shared _loggerAttribute As log4net.ILog = _
log4net.LogManager.GetLogger(System.Reflection.MethodBase.GetCurrentMethod().DeclaringType.FullName & ".Attribute")

Private Shared _loggerCache As log4net.ILog = _
log4net.LogManager.GetLogger(System.Reflection.MethodBase.GetCurrentMethod().DeclaringType.FullName & ".Cache")

Средство просмотра трассировки служб: в файле log4net.config:

  <logger name="NipissingU.ADWrapper.EntryTools.Attribute">
    <level value="INFO" />
  </logger>
  <logger name="NipissingU.ADWrapper.EntryTools.Cache">
    <level value="WARN" />
  </logger>

Все это настраивается в app.config/web.config: хорошо, возможно, это хорошо в ASP.NET, я не знаю, но при создании богатого клиента bean подсчета приложений мне нравится отдельная конфигурация файл.

Все здесь - это всего лишь мои собственные небольшие трюки.

НТН, -Mike

Ответ 2

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

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

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

Тем не менее, я думаю, что 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.

Ответ 3

Другой причиной использования TraceSources вместо Log4Net является трассировка: Log4Net может использоваться только для ведения журналов (сообщений), но как отслеживать объект (несколько информации одновременно)? Конечно, в Log4Net есть много исполнителей Listeners, но мне нужно все это? В большинстве случаев нет. И если мне нужен специальный слушатель, это не так сложно реализовать мою собственную, не так ли? Например, мне нужен прослушиватель для отслеживания в базе данных (одновременно не только сообщений, но и разных сведений {строка, int и т.д.}).

Я прав?

Ответ 4

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

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

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

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

Ответ 5

Пока я только расскажу о том, как работает log4net, очевидным преимуществом использования этой структуры является непосредственное знакомство с теми, кто использовал log4j.

Еще одно небольшое преимущество заключается в том, что ведение журнала вождения с использованием log4net чрезвычайно просто; loggers реализуют log4net.ILog. Опять же, я не знаком с решением Microsoft, но мне интересно, как это можно сделать без предварительной записи фасада в класс System.Diagnostics.Trace.

С беглым взглядом на документацию источников трассировки я не смог найти эквивалент макетов, и было бы интересно узнать, существует ли такой эквивалент. PatternLayout довольно удобен для форматирования записей журнала с общими данными, такими как datestamps, информация о потоке, контекст журнала и т.д. Log4net PatternLayout docs: http://logging.apache.org/log4net/release/sdk/log4net.Layout.PatternLayout.html

Кроме того, учитывая, что написание расширений к структуре ведения журналов, вероятно, является классической "мета-проблемой", log4net действительно приводит к большому списку подключаемых эквивалентов слушателя к таблице.

Список добавлений: http://logging.apache.org/log4net/release/config-examples.html