做站点运营，不少事故的起点并不在内容层面，而在服务器被慢慢填满的过程里。磁盘占用上涨通常没有明显征兆，直到某个访问高峰，日志写入失败、缓存无法落盘、数据库连接报错，页面才开始大面积变慢甚至返回 5xx。这类问题排查起来并不复杂，难的是平时没人盯着。
为什么磁盘问题容易被忽视
空间不足不像进程崩溃那样立刻报警。多数系统在剩余空间不多时仍能正常读写，只是速度略有下降，监控上的曲线也很平缓。真正出问题时，往往已经叠加了其他因素：一次流量高峰、一批新增备份、一个忘记关闭的调试日志，几件事撞在一起，空间就见底了。
对站点运营者来说，不需要成为运维专家，但至少要清楚几件事：空间被谁占用、增长速度快不快、清理动作有没有真正执行。
常见的空间占用来源
- 访问日志与错误日志：单日访问量大的站点，访问日志几天就能到几个 GB，错误日志在异常期间也会快速膨胀。
- 应用与调试日志：排查问题时临时打开的 debug 输出，事后常常忘记关掉，按请求级别写入极易失控。
- 缓存与临时文件：页面缓存、模板编译缓存、上传中转文件，正常时会自动回收，异常时可能越堆越多。
- 备份文件：本地保留多份数据库和站点备份，是最常见也最容易被忽略的大头。
- 系统包与旧内核：长期不清理的系统更新残留，单个体积不大，累计起来同样可观。
- 孤儿文件与回收站：内容删除后附件没有同步清理，或者媒体库里的文件已经没有页面引用。
日志轮转该怎么配
日志是增长最快、也最容易治理的部分。与其等到写满再手工删除，不如在产生环节就设定规则。
- 先估算日增量：连续观察几天，算出访问日志和错误日志的日均体积与峰值体积。
- 确定保留周期：安全审计需要的周期通常比排查问题长，据此决定保留多少天，而不是凭感觉设成 7 天。
- 切分与压缩：按天或按体积切分，历史文件及时压缩，压缩后体积往往能降到原文件的十分之一左右。
- 同时设置时间和体积上限：只设时间，遇到突发流量仍可能单日写爆磁盘；加上体积阈值更稳妥。
- 切分后重载服务：部分服务不会自动切换到新文件，需要发送重载信号，否则日志仍写在被删除的句柄上，空间不会释放。
一个可以起步的配置思路
按天切分、保留 14 天、历史文件压缩、单个文件超过 100MB 提前切分、保留最近 7 份压缩包。这套参数对中小型站点通常够用，后续根据实际磁盘容量和排查需求再调整。
把巡检变成固定动作
- 每天：看一眼磁盘使用率，重点看系统盘而非数据盘，系统盘写满会连带影响服务启动。
- 每周：看一次增长最快的目录，确认加的是预期内的内容，比如备份或日志，而不是异常文件。
- 每月：核对清理任务是否真的执行过，定时任务失败常常是静默的，配置里写了不等于跑起来了。
容量告警的价值在于提前量。等到使用率 95% 才处理，剩下的往往只有救火的时间，没有验证和回滚的余地。
和抓取之间的关系
空间问题属于基础设施，却会间接影响抓取表现。磁盘写满后，静态缓存无法更新，页面可能长期返回旧内容；写入失败还可能让部分请求直接报错。对搜索引擎蜘蛛来说，同一个地址反复失败，抓取频率会逐步下调，恢复后也需要一段时间才能回到原有节奏。
另外，日志本身也是判断抓取状况的依据。如果日志被过早清理或写坏，回溯问题时就会缺少证据。保留合理周期的访问日志，既是为了排查故障，也是为了让抓取分析有据可依。
小结
磁盘治理不需要复杂的工具，关键是把它纳入日常运营的检查项：知道增长来源，设好日志轮转，定期核对清理任务。花几分钟看一眼使用率，往往比事后重建服务便宜得多。