25.4.3 Defining and Setting Service Logging Options

You can define the message store and administration service logging
configurations that best serve your administration needs. This section discusses
issues that may help you decide on the best configurations and policies, and
it explains how to implement them.

25.4.3.1 Flexible Logging Architecture

The naming scheme for log files (service.sequenceNum.timeStamp) helps you to design a flexible log-rotation and backup policy.
The fact that events for different services are written to different files
makes it easier for you to isolate problems quickly. Also, because the sequence
number in a filename is ever-increasing and the timestamp is always unique,
later log files do not simply overwrite earlier ones after a limited set of
sequence numbers is exhausted. Instead, older log files are overwritten or
deleted only when the more flexible limits of age, number of files, or total
storage are reached.

Messaging Server supports automatic rotation of log files, which simplifies
administration and facilitates backups. You are not required to manually retire
the current log file and create a new one to hold subsequent logged events.
You can back up all but the current log file in a directory at any time, without
stopping the server or manually notifying the server to start a new log file.

In setting up your logging policies, you can set options (for each service)
that control limits on total log storage, maximum number of log files, individual
file size, maximum file age, and rate of log-file rotation.

25.4.3.2 Planning the Options You Want

Keep in mind that you must set several limits, more than one of which
might cause the rotation or deletion of a log file. Whichever limit is reached
first is the controlling one. For example, if your maximum log-file size is
3.5 MB, and you specify that a new log be created every day, you may actually
get log files created faster than one per day if log data builds up faster
than 3.5 MB every 24 hours. Then, if your maximum number of log files is 10
and your maximum age is 8 days, you may never reach the age limit on log files
because the faster log rotation may mean that 10 files will have been created
in less than 8 days.

The following default values, provided for Messaging Server administration
logs, may be a reasonable starting point for planning:

Maximum number of log files in a directory: 10

Maximum log-file size: 2 MB

Total maximum size permitted for all log files: 20 MB

Minimum free disk space permitted: 5 MB

Log rollover time: 1 day

Maximum age before expiration: 7 days

Level of logging: Notice

You can see that this configuration assumes that server-administration
log data is predicted to accumulate at about 2 MB per day, backups are weekly,
and the total space allotted for storage of admin logs is at least 25 MB.
(These settings may be insufficient if the logging level is more verbose.)

For POP, IMAP or HTTP logs, the same values might be a reasonable start.
If all services have approximately the same log-storage requirements as the
defaults shown here, you might expect to initially plan for about 150 MB of
total log-storage capacity. (Note that this is meant only as a general indication
of storage requirements; your actual requirements may be significantly different.)

25.4.3.3 Understanding Logging Options

You can set options that control the message store logging configuration
by the command line.

The optimal settings for these options depend on the rate at which log
data accumulates. It may take between 4,000 and 10,000 log entries to occupy
1 MB of storage. At the more verbose levels of logging (such as Notice), a
moderately busy server may generate hundreds of megabytes of log data per
week. Here is one approach you can follow:

Set a level of logging that is consistent with your storage
limits—that is, a level that you estimate will cause log-data accumulation
at approximately the rate you used to estimate the storage limit.

Define the log file size so that searching performance is
not impacted. Also, coordinate it with your rotation schedule and your total
storage limit. Given the rate at which log entries accumulate, you might set
a maximum that is slightly larger than what you expect to accumulate by the
time a rotation automatically occurs. And your maximum file size times your
maximum number of files might be roughly equivalent to your total storage
limit.

For example, if your IMAP log rotation is daily, your expected
accumulation of IMAP log data is 3 MB per day, and your total storage limit
for IMAP logs is 25 MB, you might set a maximum IMAP log-file size of 3.5
MB. (In this example, you could still lose some log data if it accumulated
so rapidly that all log files hit maximum size and the maximum number of log
files were reached.)

If server backups are weekly and you rotate IMAP log files
daily, you might specify a maximum number of IMAP log files of about 10 (to
account for faster rotation if the individual log-size limit is exceeded),
and a maximum age of 7 or 8 days.

Pick a total storage limit that is within your hardware capacity
and that coordinates with the backup schedule you have planned for the server.
Estimate the rate at which you anticipate that log data will accumulate, add
a factor of safety, and define your total storage limit so that it is not
exceeded over the period between server backups.

For example,
if you expect to accumulate an average of 3 MB of IMAP log-file data per day,
and server backups are weekly, you might specify on the order of 25 - 30 MB
as the storage limit for IMAP logs (assuming that your disk storage capacity
is sufficient).

For safety, pick a minimum amount of free disk space that
you will permit on the volume that holds the log files. That way, if factors
other than log-file size cause the volume to fill up, old log files will be
deleted before a failure occurs from attempting to write log data to a full
disk.