这个坑值得记一笔。日志按天切割并 gzip 归档，AWStats 报告里蜘蛛访问数从第 8 天开始直接归零，而 access.log 本身明明有几十万行记录。
刚开始盯着「统计任务只读当前文件，历史 gzip 没有被解压读取」，折腾了半个多小时，排掉了。
这类报错背后常见的原因有几处，逐个排除就行。切割后的文件名不符合 AWStats 的匹配规则，被直接跳过；logrotate 用了 copytruncate，切割瞬间 Nginx 还在写旧文件；时区配置不一致，数据被算到了错误的日期上。
先确认归档文件命名和统计配置
ls -l /var/log/nginx/access.log*; grep -n 'LogFile' /etc/awstats/awstats.conf随后抽查归档文件里的蜘蛛记录
zgrep -c 'Googlebot' /var/log/nginx/access.log.1.gz手工跑一次全量更新看是否报错
perl /usr/share/awstats/wwwroot/cgi-bin/awstats.pl -config=example -update剩下的就是统一时区后再核对日期分布
awk '{print $4}' access.log | cut -c2-9 | sort | uniq -c | head改完先别撤，确认这几项。修正日志路径规则并解压历史归档重跑后，报告里 8 天的数据补齐，蜘蛛统计曲线恢复连续。
补一句。统计工具的日志路径是正则匹配，改名之前先看配置，否则数据断了还找不到告警。报错文案容易误导，真正的原因往往在相邻那一层的日志里。