Подтвердить что ты не робот

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

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

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

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

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

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

4b9b3361

ОТВЕТЫ

Ответ 1

  • Да, он имеет тенденцию использовать слишком много CPU. У меня было приложение, в котором я регистрировал ~ 15 ГБ/день, а загрузка процессора была высокой. Я сокращаю регистрацию до ~ 4 ГБ/день, теперь использование ЦП вообще не заметно.
  • Я никогда не видел такого поведения (и я использую log4net с 1.1.1 (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

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

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

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

Ответ 3

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

Ответ 4

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

Ответ 5

Для проблемы с производительностью большая вещь в 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

Ответ 6

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

Для сравнения альтернативных фреймворков регистрации, которые вы можете рассмотреть, см. http://essentialdiagnostics.codeplex.com/wikipage?title=Comparison

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

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

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

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

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

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