Something is wrong with Log4Net?

Question

I've been using Log4Net on a few high traffic websites for a couple of years, and I cannot say that I am a happy customer. So, wanted to see if anybody else has the same concerns:

1. The CPU overhead with RollingFileAppendor is massive. Some of my websites need to trace 5-10GB per day, and when I enable logging, the CPU utilization more than doubles. I would like to avoid the discussion of why so much tracing is needed. Some mission critical apps have to trace every step of every transaction.

2. Rolling by date is often unreliable (it logs fine during the day, but then messes up the last day's log file around midnight). This behavior is inconsistent. I've seem more than a few people online that complain on this and nobody seems to have a good solution.

3. Last but not least, I have not seen any new releases on the Apache website during the last three years. So, this starts to look as an abandoned open source project, and that usually means that it's time to move on to some alternative framework.

So, I am considering giving up Log4Net in favor of the Microsoft Enterprise Library or something else. Is anybody here having the same issues as me?

Answer 1

You could look at using ASP.NET 2.0's Health Monitoring, and How To: Use Health Monitoring in ASP.NET 2.0

But I think you are going to have similiar problems. You are trying to use a logging tool as an audit tool, not exactly what it was designed for.

"Some mission critical apps have to trace every step of every transaction." - This is information that I would be logging to the database as part of a transaction. How could you guarantee the information is correct if it runs outside of a transaction?

Answer 2

1. Yes, it tends to use too much CPU. I had an app where I logged ~15GB/day and CPU usage was kind of high. I cut down logging to ~4GB/day, now the CPU usage is not noticeable at all.
2. I've never seen this behavior (and I've been using log4net since 1.1.1 (3 years) in high-traffic websites)
3. Yes, it's kind of quiet, but maybe that's because it's a stable, mature project. And development hasn't totally stopped, you can see in the svn repo that there's been some commits recently. If you're concerned about this, take a look at NLog, it's a younger, more active project.

Here's my appender config for comparison:

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

Answer 3

May be it's not your case, but I think that with such volumes of log data you should be using log management system which has zero or minimal effect on your actual application during run time. Rolling around and managing gigabytes of log is rather awkward unless all your application does is create log. Another point - I've heard many complaints from users of entlib logging particularly regarding the performance. I'd check how it would do with your volumes of data before switching to it. But even if you do find it better than log4net, I think you will still be managing huge log files yourself.

Answer 4

So far, I am inclined to blame everything on date-based rolling feature. I've tried swapping it for size-based rolling on a few servers, and I no longer see any data losses. Of course, this is not a pretty workaround because I no longer have one trace file per day. Also, the size-based rolling seems to have a bug that causes the file to roll either way too early or way too late. But this is not as painful as the original problem...