系统守护进程、内核和各种工具都会产生一些数据，这些数据被记录下来，最终保存在容量有限的硬盘上。其中大部分数据有用的寿命都是有限的，因此需要对其它们进行汇总、压缩、存档并且最终扔掉。

10.1  日志记录的策略

日志记录的策略随站点不同而不同。常见的方案包括以下几种：

—  立刻扔掉所有数据；

—  定期重新设置日志文件；

—  轮换日志文件，把该数据保留一定的时间；

—  将日志压缩并保存到磁带或其他永久性介质上。

对于您的站点来说，正确的选择取决于磁盘空间有多大，您的安全意识有多强。即使具有充足的磁盘空间，还是不要让日志文件过快增长。

无论选择何种方案，都必须用cron自动维护日志文件。有关该守护进程的详细内容，请参考第8章。

10.1.1  扔掉日志文件

我们并不建议扔掉所有的日志信息。遭受到安全问题的站点常常会发现，日志文件提供了非法入侵的重要的证据。日志文件还有助于提醒您有关硬件和软件方面的问题。总而言之，如果磁盘空间足够的话，建议至少保存数据一个月，然后才可以丢弃。在实际生活中，您可能需要很长一段时间才会意识到站点已经被黑客攻破，这时就需要查看以前的日志。如果有必要回顾更远的过去所发生的事件，那么可以从备份磁带上恢复较早的日志文件。

有些管理员听任日志文件任意增长，直到它们变成麻烦后才将其清除并从零开始。这种方案比一点儿数据都不保存要好，但这样做无法保证日志记录项能够存留任何特定的时间长度。磁盘的平均利用率也要比使用其他管理方案的利用率高。

在很个别的情况下，一个站点决定保留某些日志文件，可能不是为了任何有益的目的，而更多是为了应付传票。处于这种境地的一个站点可能会留着几周的日志数据，但是它或许要保证这些文件一定不能被存到永久性的介质上。有一个这样的案例：微软已经不止一次受到指控，其管理日志文件和电子邮件的政策破坏性过强。原告称，微软的数据保留政策无异于毁掉证据，尽管删除行动（或者至少是删除策略）是在法律诉讼之前就已经有了。遗憾的是，目前断定法庭将最终如何回应这些诉讼还为时过早^[1]。在美国，Sarbanes-Oxley法案最近规定了保留记录的新要求，参考30.12.8节。

10.1.2  轮换日志文件

把每周或者每月的日志信息保存在一个单独的文件里，这是一种通常（但不是通行）的做法。这些周期性的文件都会保留特定一段时间，然后被删除。我们专门在一台中央日志主机上划了一个硬盘分区（/var/log）给日志文件。

在每个轮换周期结束的时候，有一个脚本或者工具程序更改每个文件的名字，然后把较早的数据向文件链的结尾推。例如，假设某个日志文件的名字叫做logfile，则它的备份文件可能叫做logfile.1、logfile.2，依此类推。如果每周轮换一次，并且保存8周的数据，那么就会有一个logfile.8文件但没有logfile.9文件。每周随着logfile.7文件覆盖logfile.8文件，logfile.8中原来的数据就没了。

稍微麻烦一点，压缩一下数据就能延长保存的时间。您可以运行zgrep，不必解压压缩文件，就能搜索压缩文件。

下面的脚本就可以实现一个适当的轮换策略：

呃

对于某些日志文件来说，权属信息很重要。您可能需要以日志文件属主的身份，而不是以root的身份从cron运行自己的轮换脚本，或者要在这些命令中加上chown命令。

大多数Linux发行版本（包括我们全部的示例版本，SuSE除外）都支持一种叫做logrotate的很不错的日志轮换工具，我们将从1110.3节开始介绍它。比起编写您自己的脚本来说，它要容易得多（也可靠得多），如果您的发行版本没有包含它，那么还是值得找到并安装它的。

对于某些日志文件而言归属信息是很重要的。您可能需要以日志文件属主的身份在cron中运行该轮换脚本，而不是以超级用户身份，否则就可能要在这些命令的后面加上一条chown命令。

某些站点用日期而不是序列号来标识日志文件；，例如logfile.tues或logfile.aug262005.04.01。这种系统实现起来稍微困难一点儿，但如果需要频繁查看旧的日志文件但如果需要频繁用到旧的日志文件，那么还是值得这么做的。在Perl里设置用日期给文件起名字要比在sh中容易得多。一种不需要任何编程技巧的习惯用法是：

mv  logfile  logfile.`date  +%Y.%m.%d`

这种方法便于用这种方法也有能让ls命令对日志文件按时间顺序进行排序这一优点。（ls的-t选项让它把任何目录下的文件按修改时间排序，但是如果这些文件没有要求就这样自行安排也挺不错。）

有些守护进程的日志文件自始至终都处于打开状态。由于文件系统工作方式的缘故，我们举例的脚本不能用于这样的守护进程。日志记录数据不会保存到再次创建的logfile中，而是继续保存到logfile.1里；即使在将文件重新命名之后，对原来文件的活动引用仍然存在。若想安装一个新的日志文件，则必须向守护进程发信号或者杀死并重启它。参考本书的相关章节（或者您的手册）确定在每种情况必须采取什么样的步骤。

下面的例子在上述例子的基础上进行了修改，它同时使用了压缩和发送信号：

其中的signal代表向程序发出的写日志文件的适当信号；，pid是它的进程ID。该信号可以直接写入脚本，但必须动态判断守护进程的PID，这可以通过读取该守护进程留下的文件（比如/var/ run/syslogd.pid，这将在下面给予介绍）或是使用kill的变体killall来实现，killall能够在进程表中查找PID。例如，下面的命令

killall -e -HUP syslogd

等价于

kill -HUP ‘cat /var/run/syslogd.pid‘

1110.1.3  存档日志文件

有些站点作为政策，必须把所有的记账数据和日志文件存档，这可能是为将来可能的审计提供数据。在这种情况下，首先应该在磁盘上对日志文件进行轮换，然后再将其写到磁带或其他永久性的介质上。这种方案可以降低磁带备份的频率，并使您能够快速获取近期数据。除非您就是希望避免留下书面记录，否则应该在常规的系列备份中包含有日志文件。因为它们包含的信息对于调查安全事故来说至关重要，所以在您的转储频度允许的情况下，要以最高频度备份它们。日志文件变化很频繁，所以它们能够代表要保存在增量备份上的系统信息的重要部分。在设计您的日志政策和您的备份策略时要记得它们两者之间的相互作用关系。有关备份的更多信息，可参见第9章。

常规的备份工作应该包括日志文件。因为它们包含的信息对于调查安全事故来说至关重要，所以在您的转储频度允许的情况下，要以最高频度备份它们。日志文件变化很频繁，所以它们能够代表要保存在增量备份上的系统信息的重要部分。在设计您的日志政策和您的备份策略时要记得它们两者之间的相互作用关系。有关备份的更多信息，可参见第10章。

除了作为例行备份的一部分之外，日志也可以存档到另一套单独的磁带上。相比之下，单独的一套磁带使用起来不方便，但它们带来的建档负担要轻，同时又不影响您循环使用转储磁带的能力。在使用单独的磁带时，我们建议您采用tar格式，并编写一个脚本来自动执行备份方案。