站点运营中，磁盘空间常常是最容易被忽略的一项。平时页面能打开、后台能登录，大家就不太关注服务器还剩多少空间。直到某天日志写满分区，数据库无法写入，缓存服务异常，甚至图片上传失败，才发现问题不是出在代码，而是出在容量。
日志是磁盘增长的主要来源之一。访问日志、错误日志、抓取日志、应用调试日志、任务队列日志，都会随着时间累积。蜘蛛抓取频繁、接口调用多、异常反复出现时，日志增长速度会明显加快。如果只开不关，只写不清，再大的磁盘也会被慢慢吃掉。
先看几个容易出问题的位置
- 系统盘或数据盘的使用率，是否长期高于 80%。
- 日志目录总大小，以及单个日志文件是否已经超过预期。
- 是否存在大量小文件，导致 inode 被占满。
- 临时目录、上传临时文件、备份文件是否长期未清理。
- 数据库慢查询日志、二进制日志是否设置了保留周期。
这些问题不一定会立刻让站点下线，但会降低余量。一旦遇到流量波动、批量任务或异常刷量，磁盘很快就会被写满。对站点运营来说，稳定性比事后救火更重要。
日志轮转要落到配置上
日志轮转不是手动删文件，而是按规则切割、压缩、归档和删除。常见做法是用系统自带的 logrotate，或者应用自己的日志组件。关键是规则要明确：多久切一次、保留多少份、压缩不压缩、什么时候删除。
- 按天或按大小切割，避免单个文件过大。
- 切割后压缩旧日志，节省空间。
- 设置保留天数或保留份数，不要无限保留。
- 轮转后通知应用重新打开日志文件，避免继续写入已删除的文件句柄。
- 定期验证轮转是否真的生效，而不是只看配置文件。
磁盘告警不是等满了才看，而是要在使用率持续上升时就开始处理。留出余量，才有时间排查和调整。
清理时注意别误删
清理日志和临时文件时，先确认文件是否还在被进程写入。直接删除正在写入的日志，可能导致磁盘空间没有立即释放。更稳妥的做法是清空内容或使用轮转工具处理。对于数据库二进制日志、备份文件，要确认保留策略和恢复需求，不能为了省空间把恢复能力也删掉。
如果站点有多个环境，测试环境和预发布环境也容易堆积日志。它们不直接服务用户，但同样占用磁盘。建议把清理规则统一纳入维护计划，而不是只盯着生产环境。
容量趋势比单点数字更有用
只看今天用了多少不够。记录一周或一个月的磁盘使用趋势，可以判断增长是平稳还是突然加速。如果某段时间日志量明显上升，可以结合抓取记录、错误日志和访问来源排查原因。是蜘蛛抓取变多，还是接口异常反复重试，还是某个任务输出了大量调试信息。
- 为磁盘使用率设置分级告警，比如 70%、85%、95%。
- 记录日志目录大小变化，观察增长斜率。
- 对异常增长设置单独的监控项，避免被整体平均掩盖。
- 定期检查备份目录和临时目录，确认没有遗留大文件。
把检查写进日常运维
站点运营不需要每天手动翻日志，但需要有一套可执行的检查项。可以每周看一次磁盘使用率、inode 使用率、日志目录大小和轮转记录。每月检查一次保留策略是否合理，是否有该清理没清理的归档。遇到站点变慢、上传失败、写入报错时，也先把磁盘空间作为排查项之一。
磁盘空间和日志轮转看起来是服务器维护的细节，但它直接影响站点能否稳定运行。提前设置规则、保留余量、定期核对，比等到服务异常再处理要省事得多。