日志文件自动清理脚本：别让日志塞爆硬盘：老站长自救指南

干外贸独立站这行，最怕的不是没流量，而是正当流量暴涨的时候，服务器突然因为磁盘满了直接宕机。这种事儿我见多了，很多新手站长刚开始跑站，nginx、PHP、MySQL 猛猛装，业务跑起来了，结果不到三个月，网站报错 500，一查原因：磁盘占用 100%，全是几百个 G 的访问日志。为了彻底解决这个问题，一个靠谱的日志文件自动清理脚本就成了咱运维工具箱里的“保命符”。今天不整那些虚头巴脑的理论，老站长手把手教你写脚本，顺便聊聊这里面避不开的 SEO 逻辑和文案坑。

一、 为什么你必须重视日志清理？（不仅仅是空间问题）

很多 SEO 同学觉得，日志清理是运维的事儿，跟我排关键词有什么关系？关系大了去了。

1. 直接关乎收录： 如果磁盘满了，数据库写不进数据，网站直接挂掉。这时候 Googlebot 过来抓取，抓一个 5xx 错误，抓两次不通，你的索引量就开始“跳水”。
2. SEO 审计的数据源： 我们做日志分析，是为了看 Google 蜘蛛的抓取频率、抓取了哪些 404 页面。如果日志太大打不开，或者为了省空间直接关掉日志，那你就像盲人摸象，根本不知道网站哪里出了问题。
3. 服务器性能： 几万行甚至几百万行的日志文件，读写开销极大。磁盘 IO 一旦被日志占满，用户打开网页的速度就会变慢，加载速度可是核心排名因素（Core Web Vitals）。

避坑点： 永远不要直接删除正在运行的 access.log！如果你直接 rm -f，虽然文件没了，但进程还占用着文件句柄，空间不仅不会释放，还会导致 nginx 写入失败。正确的姿势是清空内容或者通过脚本信号重新加载。

二、 核心实操：两款拿来即用的自动清理脚本

作为老站长，我推荐两种方案：一种是针对小白的“粗暴清理法”，另一种是针对专业选手的“标准轮询法”。

1. 初级版：简单直接的 Shell 脚本（适用于小站）

这个脚本逻辑很简单：找到 N 天前的文件，直接干掉。

#!/bin/bash
# 脚本名称：clean_log.sh
# 适用场景：简单直接，清理指定目录下超过7天的.log文件

LOG_DIR="/www/wwwlogs" # 替换成你自己的日志路径
DAYS=7

# 核心命令：find 找文件，-mtime 找天数，-exec 执行删除
find $LOG_DIR -mtime +$DAYS -name "*.log" -exec rm -rf {} \;

# 如果是清理 nginx 这种持续写入的文件，建议清空而不是删除
# find $LOG_DIR -mtime +$DAYS -name "*.log" -exec cp /dev/null {} \;

echo "日志清理完成，日期：$(date "+%Y-%m-%d %H:%M:%S")"

用法拆解：

• -mtime +7：表示查找 7 天前修改过的文件。
• -name "*.log"：只匹配以 .log 结尾的文件，别把你的网站源码给删了。
• crontab -e：把脚本加入定时任务。比如每天凌晨 3 点跑一次：0 3 * * * /bin/bash /root/scripts/clean_log.sh > /dev/null 2>&1。

2. 进阶版：利用系统自带的 Logrotate（专业运维推荐）

其实 Linux 系统自带了一个神器叫 logrotate，它能自动切割、压缩、保留日志。

实战配置案例（/etc/logrotate.d/nginx）：

/www/wwwlogs/*.log {
    daily              # 每天切割一次
    missingok          # 如果文件不存在也别报错
    rotate 7           # 保留最近7份日志
    compress           # 压缩旧日志，省空间神器
    delaycompress      # 延迟一天压缩
    notifempty         # 如果日志是空的就别切了
    create 0640 www www # 切割后创建新文件的权限
    sharedscripts      # 运行完所有脚本再执行 postrotate
    postrotate         # 切割后让 nginx 重新加载，这步最关键
        [ -f /var/run/nginx.pid ] && kill -USR1 `cat /var/run/nginx.pid`
    endscript
}

老站长点评： 这种方案最稳。它不仅清理了空间，还把旧日志压缩成了 .gz。SEO 人员想分析上周的蜘蛛抓取数据？直接解压就行，既保证了服务器不爆，又留了后路。

三、 SEO 视角：如何写一篇关于“脚本”的技术博客？

既然我是老站长，少不了要分享怎么写这类技术文案。如果你要把这个脚本写成文章发到自己的博客上，千万别只贴代码。

1. 标题要“痛”，不要“平”

• 避坑标题： Linux日志清理脚本分享 (太普通，没点击欲)
• 推荐标题 A： 解决 500 错误：一招搞定 Linux 磁盘满载的日志清理 (直击痛点)
• 推荐标题 B： 站长必看！那个让服务器宕机的 access.log，我用这 5 行代码治好了 (场景感)
• 推荐标题 C： 2024 实测：全自动 Nginx 日志切分脚本，SEO 必备运维技巧 (权威性+年份)

2. 内容要加“佐料”

在介绍日志文件自动清理脚本时，可以插入一些真实的站长段子。比如：“前两天有个哥们儿，为了省事直接把日志功能关了，结果网站被 CC 攻击了，想封 IP 连个日志都找不到，只能对着白屏发呆。所以，日志要留，但要聪明地留。”

这种口语化的表达，能瞬间拉近与读者的距离，最重要的是，AI 很难模拟这种“踩坑后的调侃”。

四、 避坑指南：脚本执行中的那些“坑”

我在 6 年的运维中，因为脚本写得不严谨，出过不少汗流浃背的瞬间：

1. 路径写错： 曾经有个实习生，把 find 命令里的路径写成了根目录 /，结果系统日志、关键库文件全被删了，整台服务器当场暴毙。

   • 对策： 脚本开头加个判断 if [ -d "$LOG_DIR" ]，确保目录存在再动手。

2. 权限溢出： 脚本用 root 运行，创建出的新日志文件权限也是 root，结果 nginx（www 用户）写不进去了。

   • 对策： 在脚本或 logrotate 配置里明确 chown 权限。

3. 磁盘 IO 瞬时飙升： 如果日志文件非常大（比如 50G），直接 rm 会导致磁盘 IO 瞬间拉满，网站变慢。

   • 对策： 尽量在凌晨流量最低时执行，或者先用 truncate 命令缩小文件。

五、 给站长们的总结建议

搞独立站，运维和 SEO 是一体两面。一个好的日志文件自动清理脚本，表面上是省磁盘空间，实际上是给你的 SEO 效果买保险。

• 小站（流量 < 1000/天）： 用简单的 find 命令脚本就行，保留 15 天日志。
• 中大型站（流量 > 1万/天）： 必须上 Logrotate，配合压缩，保留 30 天，且定期下载到本地做日志分析（看蜘蛛抓取频率）。
• 写作建议： 记录这些过程时，多写点“因为没做某事导致的惨烈后果”，这种反面教材才是站长们最爱看的，也是 SEO 排名最喜欢的“差异化内容”。

最后多唠叨一句，代码写完一定要先在测试机跑一遍！别在生产环境直接梭哈。老站长不看你的代码写得多优雅，看的是你的系统稳不稳。

做站长就是个磨心性的活儿，脚本能帮我们省下重复劳动的时间，去钻研更深层的运营策略。希望这篇文章能帮你告别“磁盘爆满”的焦虑，让网站跑得更溜！