很多站点出故障，原因并不是内容出了问题，而是服务器忽然写不进去。蜘蛛在某一天集中抓取，访问日志、错误日志、爬虫日志同时膨胀，磁盘水位从六七成一路冲到 100%，接着数据库无法写入、缓存无法落盘、临时文件创建失败，蜘蛛拿到的不是内容页，而是 5xx 或长时间等待。更麻烦的是，恢复正常往往要几十分钟，这段时间里抓取频率会明显下滑，恢复后也需要一段时间才回来。
先确认日志到底长了多少
排查不要凭感觉，先看几个硬指标，列出来再判断：
- 磁盘使用率：df -h 看各挂载点，注意日志目录和数据目录是否在同一块盘上。
- inode 使用率：df -i。磁盘还有空间但 inode 用尽，同样无法创建新文件，这种情况在小文件多的日志目录里很常见。
- 日志目录体积：du -sh 逐个目录看，通常访问日志占大头。
- 增长速率：连续两天同一时间记录一次体积，算出日均增长，估算还能撑几天。
- 单文件大小：有没有一个几年没切分的巨型日志文件，打开、压缩、传输都会很吃力。
日志轮转：切分、压缩、保留
主流做法是用 logrotate 或系统自带的服务管理器，把日志按天或按大小切分。配置时几个细节容易漏：
- 保留份数别照抄模板，按日均增长算。日均 2GB 的日志，留 30 份就是 60GB，很多小服务器扛不住。
- 轮转后要压缩历史文件，纯文本日志压缩率通常很高。
- 轮转完必须让服务重新打开文件句柄，例如 nginx 可以发送 USR1 信号或执行 reopen，否则进程还握着旧文件，磁盘空间不会释放。
- 确认新生成的日志文件属主和权限与原来的服务进程一致，否则会出现“能跑但写不进日志”的静默问题。
不要直接 rm 正在写入的日志文件。文件被删除后句柄仍在，磁盘空间不会立刻释放，看起来像删了但水位没降，容易误判。
归档分层，别把所有日志堆在一起
把日志分成三层来管，成本和可查性都能兼顾：
- 热数据：最近 7 到 14 天，保留在本地磁盘，方便查错和临时分析。
- 冷归档：压缩后移到大容量盘或对象存储，需要时再拉回。
- 抓取分析用：如果要用日志做蜘蛛抓取分析，单独归集一份，不要和日常排错日志混用，避免为了保分析数据而长期占用主盘。
和抓取高峰错开，减少无谓写入
日志不是越多越好，写入量本身也是可以运营的：
- 关闭生产环境的 debug 日志，调试级别日志的体量常常是访问日志的好几倍。
- 静态资源（图片、CSS、JS）的访问记录按需保留，或单独输出到另一个文件，避免主日志被刷屏。
- 慢查询日志、详细错误堆栈按需开启，排查完及时关掉。
- 对明显异常的抓取来源做频率限制，既省服务器资源，也让日志更干净。
监控和告警要放在写满之前
等到 100% 再处理已经很被动。建议至少配置这几条：
- 磁盘使用率超过 80% 告警，超过 90% 升级提醒。
- inode 使用率纳入同一套告警。
- 监控写入失败的相关错误关键字，比如磁盘满、无法创建文件。
- 记录站点 5xx 比例，和磁盘水位放在同一张图上看，便于判断因果关系。
一次可执行的检查清单
- 查磁盘与 inode 水位，确认日志目录所在挂载点。
- 统计日志日均增长，估算可支撑天数。
- 检查轮转配置的份数、压缩、句柄重开、权限四项。
- 把超过保留期的冷日志压缩归档，移出主盘。
- 确认生产环境已关闭调试日志，静态资源日志已分流。
- 配置 80% 水位与 inode 告警，验证告警能真正发出。
- 在下次预期抓取高峰前，复查一次水位余量。
这套维护动作不复杂，但需要定期做一次。日志和磁盘水位稳住了，服务器在抓取高峰才有余量把页面正常返回出去，蜘蛛也才有机会把该抓的页面抓走。