比较简便不影响服务的方法是：先复制，后清空
cp /path/to/apache/log/access_log /path/to/apache/log/access_log_yesterday
echo >/path/to/apache/log/access_log
严肃的分析员会这样做发现一个问题：
但cp不可能严格保证严格的0点截断。加入复制过程用了6秒，截断的access_log_yesterday日志中会出现复制过程到00:00:06期间的日志。对于单个日志统计这些每天多出来几百行日志是没有问题的。但对于多个日志在跨月的1天会有一个合并的排序问题：
[31/Mar/2002:59:59:59 +0800]
[31/Mar/2002:23:59:59 +0800]
[01/Apr/2002:00:00:00 +0800]
[01/Apr/2002:00:00:00 +0800]
要知道[01/Apr/2002:00:00:00 这个字段是不可以进行"跨天排序"的。因为日期中使用了dd/mm/yyyy，月份还是英文名，如果按照字母排序，很有可能是这样的结果：排序导致了日志的错误
[01/Apr/2002:00:00:00 +0800]
[01/Apr/2002:00:00:00 +0800]
[01/Apr/2002:00:00:00 +0800]
[01/Apr/2002:00:00:00 +0800]
[01/Apr/2002:00:00:00 +0800]
[01/Apr/2002:00:00:00 +0800]
[01/Apr/2002:00:00:00 +0800]
[31/Mar/2002:59:59:59 +0800]
[31/Mar/2002:59:59:59 +0800]
[31/Mar/2002:23:59:59 +0800]
[31/Mar/2002:59:59:59 +0800]
[31/Mar/2002:23:59:59 +0800]
这些跨天过程中的非正常数据对于webalizer等分析工具来说简直就好像是吃了一个臭虫一样，运行的结果是：它可能会把前一个月所有的数据都丢失！因此这样的数据会有很多风险出现在处理上月最后一天的数据的过程中。
问题的解决有几个思路：
1) 事后处理
所以一个事后的处理的方法是：用grep命令在每月第1天将日志跨月的日志去掉，比如：
grep -v "01/Apr" access_log_04_01 > access_log_new
修改SORT后的日志:所有跨天的数据去掉。也许对日志的事后处理是一个途径，虽然sort命令中有对日期排序的特殊选项 -M（注意是：大写M），可以让指定字段按照英文月份排序而非字母顺序，但对于apache日志来说，用SORT命令切分出月份字段很麻烦。（我尝试过用 "/"做分割符，并且使用"月份" "年:时间"这两个字段排序）。虽然用一些PERL的脚本肯定可以实现，但最终我还是放弃了。这不符合系统管理员的设计原则：通用性。 并且你需要一直问自己：有没有更简单的方法呢？还有就是将日志格式改成用TIMESTAMP（象SQUID的日志就没有这个问题，它的日志本身就是使用TIMESTAMP做时间戳的），但我无法保证所有的日志工具都能识别你在日期这个字段使用了特别的格式。
2) 优化数据源
最好的办法还是优化数据源。将数据源保证按天轮循，同一天的日志中的数据都在同一天内。这样以后你无论使用什么工具（商业的，免费的）来分析日志，都不会因为日志复杂的预处理机制受到影响。
首先可能会想到的是控制截取日志的时间：比如严格从0点开始截取日志，但在子夜前1分钟还是后一分钟开始截取是没有区别的，你仍然无法控制一个日志中有跨2天记录的问题，而且你也无法预测日志归档过程使用的时间。
因此必须要好好考虑一下使用日志轮循工具的问题，这些日志轮循工具要符合：
1) 不中断WEB服务：不能停apache=>移动日志=>重启apache；
2) 保证同一天日志能够按天轮循：每天一个日志00:00:00-23:59:59；
3) 不受apache重启的影响：如果apache每次重启都会生成一个新的日志是不符合要求的；
4) 安装配置简单。
首先考虑了apache/bin目录下自带的一个轮循工具：rotatelogs 这个工具基本是用来按时间或按大小控制日志的，无法控制何时截断和如何按天归档。
然后考虑logrotate后台服务：logrotate是一个专门对各种系统日志（syslogd，mail）进行轮循的后台服务，比如SYSTEM LOG，但其配置比较复杂，放弃，实际上它也是对相应服务进程发出一个-HUP重启命令来实现日志的截断归档的。
