Maximum log file size can be configured (default 10MB) using the MaxFileSize property. This means that log files can be rolled within the configured time period if the maximum file size is exceeded. Backups are indicated by a count suffix at the end of log filenames, e.g. for the time suffix specified by the default pattern "'.'yyyy-MM-dd" (which would ordinarily result in a log file named e.g. "foo.log.2007-01-01") will result in backups named "foo.log.2007-01-01.1", "foo.log.2007-01-01.2", etc.
Configuring the maximum number of allowable backup log files (default 10) using the MaxRollFileCount property helps prevent this appender from consuming disk space without limit. Excess backup log files are scavenged by a background thread. Configuring the scavenging interval (default 30 seconds) using the ScavengeInterval property specifies the duration for which the scavenger thread should sleep between operations. The log file scavenger only operates upon files that start with the path specified by the File configuration parameter. Older files will be deleted first. Setting a scavenge interval of -1 prevents the scavenger from running.
Backup log file compression may be configured using the allowed compression algorithms specified by the CompressionAlgorithm property:
Default behaviour is not to compress backup log files unless the CompressionAlgorithm property is configured. Backup files are compressed by a background thread. At roll time the name of the backup log {@link java.io.File} object is put into the compressor thread's FIFO queue. Bydefault the compressor works on a best-effort basis: if the queue fills up, then older backup filenames are discarded and will therefore not be compressed.
The appender can be configured to force compression of all backup files by setting the CompressionUseBlockingQueue property to " true" (default is "false"). Forcing compression comes at the cost of blocking the compressor's queue (and therefore the application thread that invoked the {@link org.apache.log4j.Logger}). The application will cease to block once the current compression operation has completed and the compressor has removed the next file from its queue.
The appender's CompressionMinQueueSize property (default 0) controls the minimum number of backup files that must be in the queue awaiting compression before any compression will take actually take place. For example, if this property is set to 5, then at least 5 backup file rolls must take place before the oldest file currently in the compressor's queue will be compressed. Keeping the most recent files uncompressed can be helpful at support time.
Setting the appender's DateRollEnforced property to true (default false) activates pro-active log rolling at time boundaries. Time boundaries are enforced by a background thread. The standard {@link org.apache.log4j.DailyRollingFileAppender} only rolls log filesreactively upon the dispatch of a logging event. This appender allows pro-active control over log rolling by enforcing a schedule implied by the DatePattern property. For example, <param name="DatePattern" value=".yyyy-MM-dd"/> will see the log file roll at the end of the day, even if the application is otherwise inactive. Similarly <param name="DatePattern" value=".yyyy-MM-dd-HH"/> will result in log files being rolled every hour.
A custom message of your choosing may be written into the first line of each new log file created after a file roll has completed. This is achieved by setting the FileRollEventMessage property to a message string. If this property is configured with a blank value (e.g. <param name="FileRollEventMessage"/>), the appender will ensure that a default message is written at the top of the new log file instead. If this property is not set, no message will be written to the top of new log files. Messages are appended at {@link org.apache.log4j.Level#ALL} using the rootlogger.
The appender can be configured to roll the most recent backup file, regardless of the file's last modification time or size, immediately after receiving the first logging event after the appender's options are activated.
For example, say the appender is configured to roll every hour, or for files exceeding 10MB in size, and that a 1 MB log file exists that was last written 10 minutes before the hour. The application is restarted 5 minutes before the hour and logs an event. When the RollOnStartup property is set to true, the log file described in this example scenario will be rolled into a backup, and a new log file will be created.
An example configuration snippet taken from an actual Log4J XML configuration file is given here (generate the Javadoc to see the correct formatting). This configuration provides an appender that rolls each day and creates log files no larger than 10MB. The number of backup files is checked every 30 seconds, whereupon if the number of backup files exceeds 100 the extra backups will be deleted. The appender will make best efforts to compress backup files using the GZ algorithm.
<appender name="LOG-DAILYROLL" class="org.apache.log4j.appender.TimeAndSizeRollingAppender">
<param name="File" value="/logs/app.log"/>
<param name="Threshold" value="DEBUG"/>
<param name="DatePattern" value=".yyyy-MM-dd"/>
<param name="MaxFileSize" value="10MB"/>
<param name="MaxRollFileCount" value="100"/>
<param name="ScavengeInterval" value="30000"/>
<param name="BufferedIO" value="false"/>
<param name="CompressionAlgorithm" value="GZ"/>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%-5p %-23d{ISO8601} [%t] %x: %c{1} - %m%n"/>
</layout>
</appender>
This next configuration provides an appender that rolls each day, creates log files no larger than 100MB, and limits the number of backup files to no more than 10. The number of backup files is checked every 30 seconds, whereupon if the number of backup files exceeds 10 the extra backups will be deleted. The appender will make best efforts to compress backup files using the ZIP algorithm, but it will only compress backup files after more than 5 rolls have taken place during the lifetime of the application instance. Finally, this configuration causes the appender to honour time boundaries by rolling logs pro-actively at the end of each day, rather that reactively in response to a logging event. After file roll is complete, the new log file will have the message "First line of each file following a roll" printed on the first line.
<appender name="LOG-DAILYROLL" class="org.apache.log4j.appender.TimeAndSizeRollingAppender">
<param name="File" value="/logs/app.log"/>
<param name="Threshold" value="DEBUG"/>
<param name="DatePattern" value=".yyyy-MM-dd"/>
<param name="MaxFileSize" value="100MB"/>
<param name="DateRollEnforced" value="true"/>
<param name="FileRollEventMessage" value="First line of each file following a roll"/>
<param name="BufferedIO" value="false"/>
<param name="CompressionAlgorithm" value="ZIP"/>
<param name="CompressionMinQueueSize" value="5"/>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%-5p %-23d{ISO8601} [%t] %x: %c{1} - %m%n"/>
</layout>
</appender>
A final example of the simplest configuration provides an appender that rolls each day and creates log files no larger than 10MB. The number of backup files is checked every 30 seconds, whereupon if the number of backup files exceeds 10 the extra backups will be deleted. Backup files are not compressed, log files are rolled reactively, and no roll event messages are written at the top of each new log file.
<appender name="LOG-DAILYROLL" class="org.apache.log4j.appender.TimeAndSizeRollingAppender">
<param name="File" value="/logs/app.log"/>
<param name="Threshold" value="DEBUG"/>
<param name="BufferedIO" value="false"/>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%-5p %-23d{ISO8601} [%t] %x: %c{1} - %m%n"/>
</layout>
</appender>
@author SimonPark
@version 2.7
@see org.apache.log4j.DailyRollingFileAppender
|
|
|
|