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.

The plain text contents can be restored using the gunzip utility.

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.

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.

The following examples for the management server.

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:

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:

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.