Что-то не так с Log4Net? - PullRequest
Новая
       29

Что-то не так с Log4Net?

12 голосов
/ 11 июня 2009

Я уже несколько лет пользуюсь Log4Net на нескольких сайтах с большим трафиком и не могу сказать, что я счастливый клиент. Итак, хотел бы узнать, есть ли у кого-то еще такие же проблемы:

  1. Загрузка ЦП с RollingFileAppendor огромна. Некоторые из моих сайтов должны отслеживать 5-10 ГБ в день, и когда я включаю ведение журнала, загрузка ЦП более чем удваивается. Я хотел бы избежать обсуждения того, почему так много трассировки необходимо. Некоторые критически важные приложения должны отслеживать каждый шаг каждой транзакции.

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

  3. И последнее, но не менее важное: я не видел новых выпусков на веб-сайте Apache за последние три года. Итак, это начинает выглядеть как заброшенный проект с открытым исходным кодом, и это обычно означает, что пришло время перейти к некоторой альтернативной среде.

Итак, я рассматриваю возможность отказаться от Log4Net в пользу Microsoft Enterprise Library или чего-то еще. У кого-нибудь есть такие же проблемы, как у меня?

Ответы [ 6 ]

3 голосов
/ 11 июня 2009
  1. Да, он имеет тенденцию использовать слишком много ЦП. У меня было приложение, где я регистрировал ~ 15 ГБ / день, и загрузка процессора была довольно высокой. Я сократил логирование до ~ 4 ГБ / день, теперь загрузка ЦП совсем не заметна.
  2. Я никогда не видел такого поведения (и я использую log4net с 1.1.1 (3 года) на сайтах с большим трафиком)
  3. Да, это довольно тихо, но, возможно, это потому, что это стабильный, зрелый проект. И разработка не полностью остановилась, вы можете увидеть в svn repo , что в последнее время было совершено несколько коммитов. Если вас это беспокоит, взгляните на NLog , это более молодой, более активный проект.

Вот мой конфиг appender для сравнения: 

<appender name="LogFileAppender" type="log4net.Appender.RollingFileAppender, log4net" >
    <param name="File" value="log" />
    <param name="AppendToFile" value="true" />
    <rollingStyle value="Date" />
    <datePattern value="yyyyMMdd" />
    <maxSizeRollBackups value="7" />
    <layout type="log4net.Layout.PatternLayout, log4net">
        <param name="ConversionPattern" value="%d [%t] %-5p %c [%x] - %m%n" />
    </layout>
</appender>
2 голосов
/ 11 июня 2009

Может быть, это не ваш случай, но я думаю, что при таких объемах данных журнала вы должны использовать систему управления журналами, которая практически не влияет на ваше реальное приложение во время выполнения. Свертывание и управление гигабайтами журнала довольно неудобно, если только ваше приложение не создает журнал. Еще один момент - я слышал много жалоб от пользователей ведения журналов entlib, особенно в отношении производительности. Я бы проверил, как это будет с вашими объемами данных, прежде чем переключаться на него. Но даже если вы найдете его лучше, чем log4net, я думаю, вы все равно будете сами управлять огромными лог-файлами.

2 голосов
/ 11 июня 2009

Вы можете посмотреть, используя Мониторинг состояния ASP.NET 2.0 и Как: использовать мониторинг работоспособности в ASP.NET 2.0

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

«Некоторые критически важные приложения должны отслеживать каждый шаг каждой транзакции». - Это информация, которую я буду регистрировать в базе данных как часть транзакции. Как вы можете гарантировать, что информация верна, если она выходит за пределы транзакции?

1 голос
/ 15 июня 2009

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

0 голосов
/ 21 апреля 2013

Итак, я собираюсь отказаться от Log4Net в пользу Microsoft Enterprise Library или чего-то еще.

Сравнение альтернативных каркасов журналов, которые вы, возможно, захотите рассмотреть, см. http://essentialdiagnostics.codeplex.com/wikipage?title=Comparison

Сравнивает .NET Framework System.Diagnostics (встроенные возможности), log4net, NLog и Enterprise Library, включая сравнение производительности.

У каждого есть свои сильные и слабые стороны, но EntLib особенно плохо работает при сравнении производительности и, с точки зрения возможностей, иногда имеет меньше, чем встроенная .NET Framework System.Diagnostics.

Если вас особенно беспокоит производительность, то log4net немного выигрывает с аналогичной .NET Framework System.Diagnostics.

NLog имеет очень небольшие накладные расходы, когда не ведет журнал (то есть просто оставляет его в коде), быстрее, чем log4net или System.Diagnostics, но с увеличением объема журналирования начинает отставать.

Для высокопроизводительного ведения журнала с использованием System.Diagnostics с ротацией журналов (включая круговую), взгляните на EventSchemaTraceListener, о котором я недавно писал в блоге о , но инструментальная поддержка для просмотра журналов (которые в формате XML) не очень хорошо.

Я бы посоветовал вам настроить тестирование производительности, если вас это беспокоит. Для сравнения, указанного выше, исходный код сравнения производительности доступен в проекте Essential Diagnostics , так что вы можете запустить его самостоятельно, но, возможно, захотите приспособиться к вашей ситуации.

0 голосов
/ 23 марта 2011

Что касается производительности, то отличительной особенностью log4net является то, что вы всегда можете профилировать ее, чтобы увидеть, где использование log4net вашим приложением является узким местом, а также: 1) Решите решение самостоятельно или 2) Найдите каркас логирования, в котором нет этого узкого места.

Я не могу помочь слишком много, не зная вашего приложения, но беглым взглядом на источник log4net я заметил, что функция NextCheckDate() вызывается на КАЖДОМ void Append(LoggingEvent loggingEvent). Я включил часть исходного кода для NextCheckDate ниже, и я определенно мог представить, что это вызывает проблемы с производительностью в сценариях с большим объемом журналирования. 

protected DateTime NextCheckDate(DateTime currentDateTime, RollPoint rollPoint){
// Local variable to work on (this does not look very efficient)
DateTime current = currentDateTime;

// Do different things depending on what the type of roll point we are going for is
switch(rollPoint) 
{
    case RollPoint.TopOfMinute:
        current = current.AddMilliseconds(-current.Millisecond);
        current = current.AddSeconds(-current.Second);
        current = current.AddMinutes(1);
        break;

    case RollPoint.TopOfDay:
        current = current.AddMilliseconds(-current.Millisecond);
        current = current.AddSeconds(-current.Second);
        current = current.AddMinutes(-current.Minute);
        current = current.AddHours(-current.Hour);
        current = current.AddDays(1);
        break;

    case RollPoint.TopOfMonth:
        current = current.AddMilliseconds(-current.Millisecond);
        current = current.AddSeconds(-current.Second);
        current = current.AddMinutes(-current.Minute);
        current = current.AddHours(-current.Hour);
        current = current.AddMonths(1);
        break;
}     
return current;}

Оптимизированная версия для вашего приложения, вероятно, будет кешировать в следующий раз при опрокидывании и выполнять только одно сравнение для каждого Append

...