Compress Log4j files

2019-01-06 14:20发布

问题:

Is it possible to compress log files (I doing it via RollingFileAppender )?

回答1:

log4j extras has support for that:

just add the following to your RollingFileAppender configuration and having the filename end in .gz will automagically compress your logfiles:

<appender...>
    <rollingPolicy class="org.apache.log4j.rolling.TimeBasedRollingPolicy">
      <param name="FileNamePattern" value="/wombat/foo.%d{yyyy-MM}.gz"/>
    </rollingPolicy>
</appender>

check here for some details in the javadoc:

http://logging.apache.org/log4j/companions/extras/apidocs/org/apache/log4j/rolling/TimeBasedRollingPolicy.html

hope that helped



回答2:

I came upon this great answer, but then kept investigating a bit and log4j 2 is out!

Now you can have compression with the basic library and much, much more... it's just awesome!

RollingFileAppender - I was looking for something that had both timeBased and sizeBased rolling, and with compression... it has both! and I can drop my syslog4j library since this one has it also!

Please don't use log4j 1.2 + extras unless you really have to.



回答3:

I know this does not exactly answer your question, but it does propose an alternate solution.

The way we handle that is by having a batch process run at the end of the day that compresses any prior log files to today's date, get's rid of any prior to a week old and then copies them off to another file server. This way the application does not need to consume any CPU cycles doing this and on the server we have logs that are no older than a week and on another file server we have older log files.



回答4:

The only other thing I see is upgrade log4j to more than 1.3.15/1.4 and use TimeBasedRollingPolicy roller to have automatic compression enabled, but that would require an upgrade of log4j essentially (and compatibility of the app as well)

Hmmm..may be another better thing to have is let have log4j execute a command once the file is rolled. So instead of gzip, I can use some other compression logic like bzip, or lzop etc.. that would be another approach if I have this facility in log4j today.