Что-то неправильно с Log4Net?

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

Вот моя конфигурация приложения для сравнения:

<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>

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

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

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

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

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