I've never been terribly fond of Linux's approach to syslog
rotation.  The typical default involves weekly renaming of
file.{N-1} => file.N, for N = SOME_MAX ... N = 1; and then
renaming of file => file.1, and the creation of a new empty
copy of "file".

There are multiple annoyances that stem from this.  First,
if one finds some useful log data in file.X and then wants
to look through that data again several days later, it may
be in that file, or it might be in some totally different
file, depending on whether (and how many times) logs have
been rotated since the previous time the data was looked
at; it might be in file.{X+1} now, or file.{X+2}.  This
certainly seems a violation of the "principle of least
surprise"; after all, if datum D is in file F now, why
oughtn't I expect to find it there the next time I look?

Even worse, if too many log rotations have taken place,
the data in question no longer exists anywhere!  Not an
optimal scenario, IMHBCO.

Better, I think, (1) to organize syslog info in a rational
date-based manner; and (2) to keep the info online as long
as practical (months, or even years).

So what I've done on the systems I look after is basically:

--  Arrange so that the syslog configuration file is set up
to include something like the following:

kern.debug	/var/log/Syslog/kern.log
user.debug	/var/log/Syslog/user.log
mail.debug	/var/log/Syslog/mail.log
daemon.debug	/var/log/Syslog/daemon.log
auth.info	/var/log/Syslog/auth.log
syslog.debug	/var/log/Syslog/syslog.log
lpr.debug	/var/log/Syslog/lpr.log
news.debug	/var/log/Syslog/news.log
uucp.debug	/var/log/Syslog/uucp.log
cron.notice	/var/log/Syslog/cron.log
authpriv.info	/var/log/Syslog/authpriv.log
ftp.debug	/var/log/Syslog/ftp.log
local0.debug	/var/log/Syslog/local0.log
local1.debug	/var/log/Syslog/local1.log
local2.debug	/var/log/Syslog/local2.log
local3.debug	/var/log/Syslog/local3.log
local4.debug	/var/log/Syslog/local4.log
local5.debug	/var/log/Syslog/local5.log
local6.debug	/var/log/Syslog/local6.log
local7.debug	/var/log/Syslog/local7.log

--  Set things up so that /var/log/Syslog is actually just
a symlink to /var/log/Syslog_YYYY-MM, where YYYY-MM == the
current year and month.

--  Have a cron job which runs at midnight on the first day
of each month, which creates a new /var/log/Syslog_YYYY-MM,
creates zero-length logfiles in it, updates /var/log/Syslog
to point to the new directory, and sends syslogd a SIGHUP.

That way, one knows exactly where to find the syslog info
for any particular day.  If /var/log is reasonably-sized,
and if older logfiles are gzipped, it's possible to keep
many years of syslog data for subsequent processing.

---------------

In addition to local logging, all systems should also send
their syslog data to our central syslog server (lager.cacr).

There, logfiles get rotated daily:  At midnight, the symlink
is changed to point to a new per-day directory, and contents
of the previous day's directory are gzipped to conserve space.