Modifying the Log-File Rollover Period
My webMethods Server maintains the settings for how to roll over the log files in the My webMethods Server database. As a result, if you are running the server in the cluster, all server instances use the same rollover settings. To update the rollover settings, you can have My webMethods Server download the settings to a local file named log4j.init.properties file, modify the rollover periods in the downloaded file, and then upload the changes back to the database.
If My webMethods Server rolls over the log file based on:
Date and time, (used for the _full_.log and _problems_.log files) The rollover configuration is controlled by the appender type org.apache.log4j.DailyRollingFileAppender. To update the rollover period, you identify a new DatePattern for the appender. The following table describes the DatePatterns you can use to configure log rollover:
Date Pattern | Rollover Time |
'.'yyyy-MM | At the beginning of each month For example, for the _full_.log if you set the DatePattern to ‘.’yyyy-MM, at midnight on January 31, 2010, My webMethods Server copies the log data to the file _full_.2010-01.log. My webMethods Server logs messages for the month of February to the _full_.log file until it is rolled over the next month. |
'.'yyyy-ww | At the first day of each week. The first day of the week depends on the locale. For example, assume the first day of the week is Sunday and that for the _problems_.log you set the DatePattern to '.'yyyy-ww. On Saturday midnight, May 15, 2010, My webMethods Server copies the log data for the 19th week of the year to the file _problems_2010-19. My webMethods Server logs messages for the 20th week of 2010 to the _problems_.log file until it is also rolled over the next week. |
'.'yyyy-MM-dd | At midnight each day. For example, for the _full_.log if you set the DatePattern to '.'yyyy-MM-dd, at midnight on February 22, 2010, My webMethods Server copies the log data to the file _full_2010-02-22. My webMethods Server logs messages for February 23, 2010 to the _full_.log file until it is also rolled over the next day. |
'.'yyyy-MM-dd-a | Twice each day, at noon and midnight. For example, for the _problems_.log if you set the DatePattern to '.'yyyy-MM-dd-a, at noon on February 22, 2010, My webMethods Server copies the log data to the file _problems_2010-02-22-A.M. My webMethods Server logs messages for the afternoon of February 22, 2010 to the _problems_.log file until it is rolled over at midnight into the file _problems_2010-02-22-P.M. Then, My webMethods Server logs messages for February 23, 2010 to the _problems_.log file. |
'.'yyyy-MM-dd-HH | Every hour of each day. For example, for the _full_.log if you set the DatePattern to '.'yyyy-MM-dd-HH, at approximately 11:00 A.M. on February 22, 2010, My webMethods Server copies the log data for the 10 o’clock hour to the file _full_2010-02-22-10. My webMethods Server logs messages for the 11 o’clock hour to the _full_.log file until it is rolled over at the beginning of the next hour. |
'.'yyyy-MM-dd-HH-mm | Every minute of each day. For example, for the _full_.log if you set the DatePattern to '.'yyyy-MM-dd-HH-mm, at approximately 11:46 A.M. on February 22, 2010, My webMethods Server copies the log data to the file _full_2010-02-22-11-45. My webMethods Server logs messages for the next minute to the _full_.log file until it is rolled over a minute later. |
File size, (used for the install.log file) The rollover configuration is controlled by the org.apache.log4j.RollingFileAppender. You can update the log level of the messages collected in the install.log file, the maximum size of the log file before it is rolled over, and the number of backup log files that My webMethods Server maintains.
Note:
The following procedure describes how to modify the roll over periods by updating parameters for the default appenders (org.apache.log4j.DailyRollingFileAppender and org.apache.log4j.RollingFileAppender) that are defined out-of-the-box. However, if you want, you can update the settings to use an alternative appender to meet your needs. For example, you can change the _problems_.log to use the RollingFileAppender if you want it to roll over based on size or FileAppender if you do not want the log to roll over. You can use any appender that log4j library supports. For more information, see
http://logging.apache.org/log4j/1.2/index.html.
To modify the log-file rollover period
1. Download the log4j.init.properties file from the My webMethods Server database:
a. At a command line prompt, change directories to move to the server’s bin directory:
Software AG_directory \MWS\bin
b. To retrieve the log4j.init.properties file from the database, type this command:
mws -s serverName getconfig log4j.init.properties
2. Edit the log4j.init.properties file.
a. Navigate to the following directory, where the getconfig command placed the log4j.init.properties file:
Software AG_directory \MWS\server\serverName\config
b. Open the log4j.init.properties file in a text editor.
3. To modify the rollover settings for the _full_.log file:
a. Locate the following portion of the file:
log4j.appender.rootFile=org.apache.log4j.DailyRollingFileAppender
log4j.appender.rootFile.DatePattern='.'yyyy-MM-dd
log4j.appender.rootFile.File=${log4j.logging.dir}/_full_.log
b. Update the date pattern to define when you want the _full_.log file to rollover.
4. To modify the rollover settings for the _problems_.log file:
a. Locate the following portion of the file:
log4j.appender.rootErrorsFile=org.apache.log4j.
DailyRollingFileAppender
log4j.appender.rootErrorsFile.DatePattern='.'yyyy-MM-dd
log4j.appender.rootErrorsFile.File=${log4j.logging.dir}/
_problems_.log
b. Update the date pattern to define when you want the _problems_.log file to rollover.
5. To modify the rollover settings for the install.log file:
a. Locate the following portion of the file:
log4j.appender.installFile=org.apache.log4j.RollingFileAppender
log4j.appender.installFile.threshold=DEBUG
log4j.appender.installFile.MaxFileSize=100MB
log4j.appender.installFile.MaxBackupIndex=3
log4j.appender.installFile.File=${log4j.logging.dir}/install.log
b. To change the size limit of the file, update the value on the log4j.appender.installFile.MaxFileSize line to specify an alternative maximum file size.
c. To change the number of backups that you want My webMethods Server to maintain, update the value on the log4j.appender.installFile.MaxBackupIndex line.
It is recommended that you do not update the log4j.appender.installFile.threshold line to change the threshold level for the install.log. Because the installation process issues INFO messages, if you raise the threshold, no messages will be logged.
6. To modify the rollover settings for the schema.log file:
a. Locate the following portion of the file:
log4j.appender.DDLSchemaFileAppender=org.apache.log4j.
RollingFileAppender
log4j.appender.DDLSchemaFileAppender.threshold=INFO
log4j.appender.DDLSchemaFileAppender.MaxFileSize=5MB
log4j.appender.DDLSchemaFileAppender.MaxBackupIndex=10
log4j.appender.DDLSchemaFileAppender.File=${log4j.logging.dir}
/schema.log
log4j.appender.DDLSchemaFileAppender.layout=org.apache.log4j.
PatternLayout
log4j.appender.DDLSchemaFileAppender.layout.ConversionPattern=
${log4j.mes
sage.pattern}
b. To change the size limit of the file, update the value on the log4j.appender.DDLSchemaFileAppender.MaxFileSize line to specify an alternative maximum file size.
c. To change the number of backups that you want My webMethods Server to maintain, update the value on the log4j.appender.DDLSchemaFileAppender.MaxBackupIndex line.
7. Save the log4j.init.properties file.
8. Deploy the revised file to the My webMethods Server database:
a. At a command line prompt, change directories to move to the server’s bin directory:
Software AG_directory \MWS\bin
b. To write the log4j.init.properties file back to the database, type this command:
mws -s serverName putconfig log4j.init.properties
c. Delete the local copy of the log4j.init.properties file.
If you do not delete the file, the server instance will continue to use the local version of the file.
9. Restart the cluster.
Changes do not take effect until the cluster is restarted.