服务稳定运行一段时间后根分区满，日志可能来自 journal、容器或应用目录。直接删除全部日志会丢失故障证据，应先确认增长源与保留要求。
日志文件大小、目录占用和被进程打开但已删除的文件，是三个不同对象。轮转、压缩与保留周期控制累积量，进程持续写入已删除文件时磁盘空间未必立即回收。
一、问题的范围与前提
单台 Linux 主机上的进程、文件、网络和服务管理有各自边界。排查时先确认当前命令所处的用户、网络命名空间与工作目录，再把进程状态和实际业务请求对应起来。交互终端、系统服务和容器可能同时使用不同环境，即使执行文件名称一样，也不代表访问同一组资源。
二、技术分析与方案取舍
删除仍被进程打开的文件后，目录里看不到它，但空间可能要等进程关闭文件才释放。因此目录统计与文件系统使用量出现差异时，应检查打开文件状态。轮转也需要确认程序是否重新打开目标，不能认为重命名以后它就自动写新文件。处理磁盘满时保留故障窗口、确认业务数据库还有写入空间，再按来源制定保留策略，避免一次清空损失关键证据。
变更应围绕已经定位的条件进行。先保存当前有效配置与一段故障日志，再修改一个变量，使用同一入口复测。服务重启只重新执行当前单元，单元文本改变后还需按管理器规则重新加载；网络配置改变也可能影响已有连接。每一步都应能说明它解决的是地址、权限、环境还是进程生命周期。
三、实现与排查的顺序
- 按目录观察空间增长。
- 区分系统容器与应用日志。
- 为不同来源设置轮转。
- 保留错误窗口后验证回收。
按这个顺序保留中间结果，可以区分输入条件、处理过程和最终输出。前一阶段的条件不成立时，先解释对应错误，再继续后面的试验；单次返回成功不足以覆盖整条链路。
最小示例
1
2
3
4
df -h
df -i
journalctl --disk-usage
docker system df
空间、inode、journal 和 Docker 各有统计口径。根分区满既可能是大文件，也可能是海量小文件耗尽 inode。这里仅查询，不自动清理；先确定增长来源与业务保留条件，再选择对应轮转或清理策略。
四、验证和结果解释
进程 PID、监听地址、错误发生时间与退出状态适合形成一组关联证据。单次截图通常不足以解释间歇故障，持续观察可以发现状态转换和重复失败间隔。公开记录只保留必要错误类型与通用路径，认证信息、真实主机名和内部地址不进入文章。
| 需要验证的结果 | 保留的对照 | 不能由此推出的结论 |
|---|---|---|
| 轮转后服务持续写入新文件 | 固定输入与配置、对应输出 | 一次成功代表所有条件成功 |
| 历史证据仍能定位时间 | 中断前后状态与错误阶段 | 没有报错代表结果正确 |
| 磁盘告警先于业务写入失败 | 恢复后的同条件复测 | 临时恢复代表根因已经消失 |
故障复现时要区分稳定错误和偶发错误。稳定错误优先检查固定配置，偶发错误再看资源峰值、连接状态和时间变化。修复后既测正常路径，也验证启动失败、依赖不可达与重启条件，避免只在已有运行环境中成功。
五、适用边界与结论
保留策略应与存储容量和排查周期配套。只限制容器 json-file 不会限制应用自建文件；不能在没有证据时清空整个业务数据目录。
这条路径把“按目录观察空间增长”与“保留错误窗口后验证回收”连在一起，中间保留可复查的条件。实施时优先确认“轮转后服务持续写入新文件”，再检查“磁盘告警先于业务写入失败”；两者都满足，才能在当前样本与配置范围内评价方案。设备、数据或软件版本改变以后，相关假设需要重新验证。
