为什么日志会成为“隐形占用”
站点跑起来之后，访问日志、错误日志、抓取日志每天都在增长。一个流量不大的站点，access.log 一年也可能攒到几个 GB；如果再加上调试日志、慢查询日志和缓存文件，占用会更快。磁盘写满时，最先出问题的往往不是页面本身，而是日志写不进去、会话无法保存、临时文件创建失败、数据库无法写入。表现可能是间歇性 500、登录状态丢失，严重时整站打不开。
一次完整的自查清单
1. 先看还剩多少空间
- 用 df -h 查看各分区使用率，重点关注 / 和 /var 这类系统分区，使用率超过 80% 就该处理；
- 用 df -i 查看 inode 使用率。小文件特别多时，空间没满但 inode 先耗尽，同样会写入失败；
- 把当前数值记下来，作为后续对比的基线。
2. 找到占用大头
- 用 du -sh 逐层定位到具体目录，通常集中在日志目录、缓存目录、上传目录和备份目录；
- 注意被删除但进程仍持有的文件，du 看不到占用，重启对应服务或释放句柄后空间才会回来；
- 分清哪些文件可以压缩归档，哪些必须原样保留。
3. 日志轮转是否真的在工作
- 检查轮转配置（如 logrotate）的周期、保留份数、是否压缩；
- 确认轮转后服务是否需要 reload 或重开文件句柄，否则会继续写旧文件；
- 留意轮转静默失效的情况：权限不足、配置语法错误、磁盘已满都可能让轮转不执行。
日志不是越少越好。做 URL 发现和抓取分析时，经常需要回看一段时间的蜘蛛访问记录，保留周期建议按分析需求设定，而不是一律只留三天。
4. 设定清理与告警规则
- 按类型设定保留期：访问日志保留 30 到 90 天，调试日志保留数天，归档后压缩；
- 配置阈值告警，例如使用率达到 75% 提醒、85% 告警，别等到写满才收到消息；
- 清理脚本先在测试环境验证匹配范围，避免误删上传目录或数据库文件；
- 把“查看磁盘与日志状态”写进例行巡检，每周固定看一眼。
顺手能发现的几件事
整理日志时，顺便翻一下 error.log。如果 5xx 集中出现在某些路径，多半是程序或数据库层面的问题；如果日志里出现大量重复的异常 UA 或异常高频请求，也可以作为后续限流与防护的参考。这些信息平时不翻日志是看不到的。
小结
磁盘和日志属于“平时没感觉、出问题很致命”的那类事项。建议先做一次基线记录：各分区使用率、日志目录大小、轮转配置现状，然后补上告警和清理规则，把巡检变成固定动作。留足空间，站点才有余量应对流量的正常波动。