站点运营的日常工作里，磁盘空间是那种平时没人看、出事才知道的指标。它不像证书过期那样有明确提醒，也不像 5xx 那样立刻被用户投诉，而是先悄悄让写入变慢，再让响应排队，最后才演变成整站不可用。对依赖搜索蜘蛛持续访问的站点来说，这段时间差恰好是最容易丢抓取量的窗口。
磁盘写满时，最先出问题的往往不是“打不开”
磁盘接近满载时，站点通常不会马上返回错误页，而是出现一系列让人摸不着头脑的现象：
- 页面生成变慢，动态页尤其明显，因为模板缓存和会话文件写不进去；
- 搜索蜘蛛访问时偶发超时或 5xx，日志里能看到明显的响应时间波动；
- 后台发布内容失败，或者内容写入了但附件没存下来；
- 日志本身也写不进去，于是“出问题”的那段时间恰好没有日志可查。
这几种现象的共同点是：来源看似分散，根源却都指向同一个磁盘水位。所以排查抓取下降时，先看一眼磁盘用量，往往比翻十几页日志更快。
三个常见的空间占用大户
- 访问日志与错误日志：被扫描器扫、被爬虫高频抓取、被接口轮询，都会以文本形式累积在磁盘上。一个访问量中等的站点，一年不切割的原始日志就能吃掉几十 GB。
- 历史备份文件：自动备份如果只做“生成”不做“淘汰”，每天一份、每份几百 MB，很快就能堆满整个分区，而且这些文件通常还放在同一块盘上。
- 缓存与临时文件：页面缓存、缩略图缓存、会话文件、上传临时目录，平时不起眼，一旦清理任务失败或者进程异常退出，残留文件会成规模堆积。
日志切割与保留策略
按天切割，按大小兜底
优先按天切割，同时设一个体积上限。某些目录被高频扫描时，一天的日志量可能异常大，只按天切会让单文件大到难以打开。按天加按大小双重触发，既方便定位某一天的抓取情况，也避免出现打不开的巨型文件。
保留窗口与实际用途对齐
日志保留多久，取决于你真正会回看多久。只用于日常抓取观察的，保留 7 到 30 天通常够用；需要做季度对比或者事故回溯的，可以定期把聚合后的统计结果单独存下来，原始明细则不必长期保留。压缩后再归档，能显著降低占用。
一次可执行的巡检清单
- 查看各分区使用率，重点关注日志、备份、缓存所在的分区，而不是只看根分区。
- 按目录统计体积，找出排名前十的大目录，确认每一个都有明确归属。
- 检查日志切割任务是否真的在跑，最近一次切割产物是否存在、是否可读。
- 核对备份文件数量与保留策略是否一致，删除失败的任务要单独记录。
- 清理临时目录和过期会话文件，确认清理任务有日志、有成功率记录。
- 检查数据库的二进制日志、慢查询日志、临时表空间，这些也常常在同一块盘上。
- 确认磁盘水位回到安全线以下后，再去看抓取日志的响应时间是否同步恢复。
告警要设阈值，不要只设“挂了”
只监控“站点是否可访问”，等于只在结果层面报警。更实用的做法是给磁盘水位设两级阈值：超过七成时提醒，超过八成五时告警，并附带占用增长最快的目录。这样你拿到告警时，已经知道该去清理什么，而不是从头排查。
磁盘清理不是一次性任务，它更像一个需要持续微调的配置项。真正省事的做法，是让切割、归档、淘汰三件事都自动化，并把它们的执行结果纳入日常巡检。
最后提醒一句：清理前先确认哪些日志还有用。有些站点在排查抓取异常时，恰好需要最近几天的原始日志，如果清理策略把窗口压得太短，关键时刻反而没有依据。空间和可追溯性之间，留一点余量更稳妥。