磁盘满：服务器隐形的停机杀手

在IDC运维中，服务器磁盘空间被日志与临时文件占满，是导致业务宕机的常见原因之一。日志持续写入、临时文件未及时回收、缓存目录异常增长，都可能让根分区或数据分区在数分钟内耗尽空间。当磁盘写满时，数据库事务可能中断、应用进程可能崩溃，甚至操作系统核心服务也会因无法写入必要文件而异常，最终造成业务长时间不可用。

自动清理为何是“保命”而非“治本”

需要明确的是，自动清理日志与临时文件是一种止损与缓解手段，而不是替代容量规划的根本方案。其目标是在磁盘达到危险水位前，主动删除或压缩可再生的数据，给运维人员争取定位和处理时间。因此，合理的自动清理策略应聚焦于明确可删文件：轮转后的历史日志、会话临时文件、缓存目录下的过期数据，以及应用运行产生的临时转储文件。

三层清理体系：工具、脚本与系统服务

1. logrotate：日志轮转的核心工具

绝大多数Linux发行版内置logrotate，通过配置文件管理日志文件的分割、压缩与删除。建议针对不同业务日志设置合理的轮转周期与保留份数。例如：

• 按天轮转，保留30份以内，避免单日异常输出撑爆分区；
• 开启压缩，以gzip或zstd降低存量占用；
• 配置copytruncate，适合无法重启的进程，避免因日志文件被移动而丢失写入位置；
• 设置maxsize，当日志单日增长超限时提前触发轮转。

同时建议为logrotate添加独立的state文件，并在cron.daily中确保其执行成功。日志量大的服务可增加单独的hourly配置，缩短异常发现窗口。

2. systemd-tmpfiles与tmpwatch清理临时文件

系统目录如/tmp和/var/tmp是临时文件的重灾区。systemd-tmpfiles提供基于时间的清理规则，可在不引入新依赖的情况下进行治理。例如对/tmp目录执行超过1天未访问文件清理，对Java应用生成的hsperfdata目录设置更短存活时间。对于未使用systemd的发行版，tmpwatch/Tmpreaper可提供类似能力，但需注意其默认可能不清理符号链接与挂载点，避免误删。

3. 脚本清理应用专属缓存与转储文件

对于日志与操作系统层面之外的临时文件，建议以受控脚本兜底。脚本需满足以下原则：

• 明确限定路径，不记录/根递归、不包含仅拥有者可读的敏感目录判断；
• 使用find时组合-mtime、-size与-type f条件，并排除仍被进程占用且未拆分的活动文件；
• 删除前输出待清理文件清单与总量，执行后将结果写入独立操作日志；
• 禁止直接将所有tmp目录打包删除，应先考虑应用白名单路径再处理。

磁盘监控与阈值联动

自动清理机制必须有监控与告警联动。建议分三级：

1. 水位下降触发：磁盘使用率超过80%时，运行执行权限受限的清理任务，仅删除超过保留期限的文件；
2. 临界告警：超过90%时，强制轮转并压缩日志，同时通知运维排查增长源；
3. 紧急保护：接近95%时，暂停非核心写入服务、停止收集新日志并保留应急SSH链路，防止系统写保护挂载或进程OOM。

监控项应当包括分区使用率、inode使用率以及最近一次清理任务的执行状态，避免目录中“已满但du输出正常”的inode耗尽场景。

并非万能：清理策略必须留有“活口”

自动清理不是银弹。若业务本身产生的数据均不可重建，例如数据库WAL、未落盘的事务文件或正处于关键写入阶段的缓存，则不应被普通清理脚本触碰。运维团队应通过配置管理工具统一维护清理规则，并在上线前进行演练，确认脚本不会删除正在使用的文件。同时保留一份应急手动清理工具，用于自动流程失灵时人工介入。

结语

对于以日志与临时文件为主的可再生数据，沉淀一套自动轮转与清理机制，是服务器面对磁盘压力时稳住业务不中断的重要防线。它不是替代容量扩容的理由，却是从“磁盘已满导致宕机”向“磁盘高水位自动处理”迈进的关键工程实践。在部署任何自动清理规则前，请务必结合自身应用行为，明确可重建文件的边界，才能让自动化真正成为业务的保护伞。