linux定时删除日志脚本

凌晨两点十七分，时删我的除日手机突然响了——不是闹钟，是志脚服务器磁盘告警。登录一看，时删日志目录占了整整42G，除日全是志脚半年前的nginx访问记录。这场景太熟悉了，时删每个运维都经历过：日志文件像雪崩一样堆积，除日直到某天把磁盘塞满，志脚服务彻底卡死。时删

写个定时清理脚本其实不难，除日难的志脚是想清楚到底删什么、留什么、时删什么时候删。除日我见过有人图省事，志脚直接`rm -rf /var/log/*`，结果把系统日志也清了，出问题连排查线索都没有。还有人用find加-mtime参数，但没考虑文件大小和增长速率，结果大文件没删掉，小文件反而被误伤。

我自己的做法是分三步。第一步，用crontab定好执行时间，凌晨三点跑，避开业务高峰。第二步，写个shell脚本，先找到目标日志目录，再用find命令按天数和大小双重过滤。比如：保留7天内的，超过7天但小于100M的也留着，只有既超期又超体积的才删。这样既防止日志无限膨胀，又不会误删正在写入的文件。

具体脚本长这样：

#!/bin/bash LOG_DIR="/var/log/myapp" DAYS=7 SIZE="+100M" find $LOG_DIR -name "*.log" -mtime +$DAYS -size $SIZE -exec rm -f { } \; 

别小看这个`-size`参数，我踩过坑。之前只按时间删，结果有个程序每天生成2G的debug日志，7天就是14G，删完第二天又涨回来。加上大小限制后，那些疯狂写日志的进程反而暴露出来了——你会发现某个日志文件三天就长到5G，这时候该做的是去查代码，而不是光靠脚本擦屁股。

还有个细节容易被忽略：删除操作要加`-exec`而不是`| xargs`，因为日志文件名可能带空格或特殊字符。另外，脚本里最好加个判断，如果磁盘使用率低于80%就跳过清理，避免无谓的IO开销。我见过有人把清理任务设成每分钟跑一次，那纯粹是给自己找麻烦。

定时任务本身也有讲究。有人喜欢用`cron.d`目录放脚本，但系统升级时可能被覆盖。我习惯直接写在root的crontab里，加上注释说明用途。执行日志要单独重定向到文件，别让cron把输出发到邮箱——现在谁还天天看邮箱啊。

最后说个实在的：脚本写完先手动跑一遍，用`-exec echo`代替`-exec rm`，看看它到底会删哪些文件。确认无误再切到正式删除模式。别问我为什么强调这个，去年我就在生产环境上干过蠢事，把备份目录的日志全删了，客户投诉电话打爆了手机。

日志清理不是一劳永逸的事。业务量涨了，日志增长速率变了，脚本的参数就得跟着调。我每季度会检查一次脚本的执行记录，看看实际删除了多少文件，磁盘空间变化趋势如何。这东西跟打扫房间一样，定期做不觉得累，攒半年再收拾，工程量能让人崩溃。