Was this helpful?
Log File Rotation
Management server log files are rotated to prevent a single log file from growing too large.
Using environment variables, logging can be configured in these ways:
By rotation time interval—a date stamp, specified by a file name template, can be added to the log file name
By log file size limit—when exceeded, a new file is created with an incrementing integer value appended to the file name
By a combination of the previous methods, which could create many backup files each day with the same date stamp but with the incrementing integer value added
Director logging is explained in director.log. Because Director for the Web operates in a different environment from the management server or desktop version, its logging cannot be controlled these ways. Instead, all logging is redirected to the Java console, which can be displayed using settings in the Java Control Panel.
More information:
Environment Variables: DIRECTOR_LOG_ROTATE and II_MGMTSVR_LOG_ROTATE
Log File Compression
Any log file rotation method can implement compression on the backup log files (the log file currently in use is not compressed). After a log file is rotated into backup status, it can be compressed automatically using the gzip method. Compressed files are appended with the .gz extension.
The plain text contents can be restored using the gunzip utility.
More information:
Environment Variables: DIRECTOR_LOG_COMPRESS and II_MGMTSVR_LOG_COMPRESS
Log File Limiting
Any log file rotation method can be combined with limiting the number of backup log files that are retained. Once the desired number of backup log files have been archived, the next time rotation is invoked, the oldest file of the set will be deleted to make room for the newly renamed file.
More information:
Environment Variables: DIRECTOR_LOG_KEEP and II_MGMTSVR_LOG_KEEP
How Log File Rotation Works
Every time Director makes a logging request, it checks whether rotation is enabled. If the flag is set, the logging interval is checked for difference from the previous logging request. If the day, week, or month plus year is different from the last logging request, or if the file size limit is set, then if the current log file size is greater than or equal to the limit, the current log file is closed and renamed according to rules established. A new log file is then opened for current logging.
Old log files are successively renamed to make room for the new file. The latest log file is compressed if compression is enabled, and log files beyond the number specified in the “keep” value are deleted.
If little logging is being done (based on the logging level specified), the rotation may not occur on the time interval specified and could be much later.
If any errors are encountered during the rotation process, which involves renaming files in reverse succession, the process halts and a file with a “.0” suffix is created. In this case, none of the most recent files will be deleted, preserving recent log information.
Log File Rotation Examples
There are many possible configurations for log file rotation, but here are some examples of common strategies and how to enable them.
The following examples for the management server.
More information:
Implementing Daily Rolling Log Files
If you want to start a new log file every day, there are two ways to achieve this.
Set the log file name to include the “{DATE}” token:
ingsetenv II_MGMTSVR_LOG_FILE iimgmtsvr_{DATE}.log
Enable log file rotation:
iisetres ii.hostname.mgmtsvr.log_rotate TRUE
Reducing Logging Noise
Suppose there is port scanning going on in your network which causes the management server to log errors more or less continually, which are really just noise. You could archive log files with daily rolling files (see Implementing Daily Rolling Log Files), or you could simply reduce the logging level so that almost nothing gets logged.
To do this you could set the logging level to FATAL (instead of the default value of ERROR), like this:
ingsetenv II_MGMTSVR_LOGGING_LEVEL FATAL
Enabling DEBUG-Level Logging with Archiving
In this scenario, you suspect a problem in the management server, but it only happens intermittently, so you need DEBUG-level logging to investigate the errors, yet you need to be able to throw away logs that are of no interest.
The easiest way to do this is to enable size-based log file rotation at a medium size so the log files of interest can be investigated easily. Assuming a Linux environment:
$ iimgmtsvr stop
$ export II_MGMTSVR_LOG_ROTATE=TRUE
$ export II_MGMTSVR_LOG_MAX_SIZE=1M
$ export II_MGMTSVR_LOGGING_LEVEL=DEBUG
$ iimgmtsvr start
Implementing Log File Rotation at Infrequent Intervals
If the management server runs continually (which should be the case) and over time the log file grows, one easy solution is to simply enable log file rotation on a weekly or monthly basis so that old files can be removed easily.
Compression is also a good strategy since these files would simply be for archival purposes.
$ iimgmtsvr stop
$ ingsetenv II_MGMTSVR_LOG_ROTATE TRUE
$ ingsetenv II_MGMTSVR_LOG_INTERVAL WEEKLY
$ ingsetenv II_MGMTSVR_LOG_COMPRESS YES
$ iimgmtsvr start
Last modified date: 04/24/2023