磁盘使用率突然升高时，最危险的做法是直接删除“大文件”。被删掉的可能正是正在写入的日志、业务数据或排障所需的现场信息。更稳妥的顺序是先确认耗尽的到底是块空间还是 inode，再定位增长最快的文件系统、目录和文件，最后结合近期变更判断原因与处置方式。
第一步：先区分块空间耗尽还是 inode 耗尽
磁盘告警通常有两种完全不同的含义。
块空间耗尽，指文件内容占满了可用容量。常见原因是日志持续增长、上传文件堆积、备份文件残留、临时导出文件过大，或者业务异常重复写入数据。此时重点要找的是“哪些文件占用了空间”。
inode 耗尽，则是文件数量过多，即使还剩下不少容量，也可能无法创建新文件。大量小文件、按时间切分的日志、失败任务生成的临时文件、缓存碎片或异常重试产生的文件，都可能导致这种情况。此时重点不是寻找最大的单个文件，而是定位“哪些目录里文件数量增长异常”。
这一步不能省略。只看容量百分比，可能会把 inode 问题误判成大文件问题；反过来，只统计文件数量，也可能错过一个正在快速膨胀的日志文件。值班时应同时查看文件系统的空间使用情况和 inode 使用情况，并确认告警对应的是哪个挂载点，而不是一上来扫描整台主机。
如果只有某个挂载点异常，后续排查应始终围绕这个文件系统展开。系统盘、日志盘、业务数据盘的处理边界不同，混在一起检查容易把正常数据误认为异常，也可能误删系统或业务文件。
第二步：确认增长发生在哪些目录
确认问题类型后，先从挂载点的第一层目录开始比较占用情况，不要直接对整台主机做无差别深度扫描。这样做的目的不是马上找出最终责任文件，而是快速判断增长属于日志、临时目录、应用数据，还是某个不熟悉的挂载路径。
目录扫描时要关注三个信号：
- 某个目录的当前占用明显高于同类目录；
- 某个目录在两次检查之间增长很快；
- 某个目录的文件数量异常集中，尤其是在 inode 使用率升高时。
单次大小排序只能告诉你“现在谁最大”，不能证明“谁导致了这次突增”。例如，长期积累的业务数据可能一直很大，但真正引发告警的是刚刚开始暴涨的日志目录。因此，条件允许时，应保留前后两次检查结果，比较目录大小和文件数量的变化，而不是只看一次快照。
如果主机上存在多个挂载点，还要确认扫描工具没有跨越文件系统边界。否则，某个目录下挂载的独立盘可能被重复统计，得到的结果会与告警数据对不上。
第三步：继续缩小到具体文件或文件类型
找到增长最快的目录后，再判断它是由少数大文件造成，还是由大量小文件造成。
如果是少数大文件，应重点查看文件的修改时间、所属用户、所属进程以及文件类型。一个最近修改且持续变大的文件，通常比一个数月未变化的大文件更值得优先调查。文件名也只能作为线索，不能单独作为删除依据；有些应用会把业务数据、日志和临时结果使用相似的命名方式。
如果是大量小文件，应按子目录、文件后缀、创建或修改时间继续分组。大量文件集中在最近一段时间生成，往往与任务失败重试、缓存未清理、临时目录残留或日志切分有关。若文件分散在多个日期目录中，则还要判断这是正常保留策略失效，还是业务写入量真的发生了变化。
这一步还要留意“目录占用看起来不大，但 inode 已经接近耗尽”的情况。此时不要把排查重点放在最大文件上，而应优先找出文件数量最多、增长最密集的路径。
第四步：结合近期变更判断是不是日志暴涨
日志是生产环境中最常见的突增来源，但不能因为文件位于日志目录，就直接认定它可以删除。
先检查近期是否发生过发布、配置调整、日志级别变更、异常流量、依赖服务故障或反复重启。若这些事件与日志开始增长的时间基本一致，再对照日志内容判断是否存在同一错误被高频重复记录。错误日志暴涨通常会留下明显特征，例如相同异常反复出现、单个请求被多次记录，或某个后台任务不断失败重试。
还要区分应用日志、访问日志和系统日志。访问量增加可能使访问日志变大，但如果增长速度远超流量变化，就需要继续查找异常请求、重试风暴或日志格式变化。应用日志突然变大，则更应关注错误循环、调试日志被意外开启，以及某项功能是否在异常条件下持续输出详细内容。
处理日志时，优先选择应用自身支持的轮转、压缩、保留和降级机制。正在被进程打开的日志文件，即使目录中已经看不到它，仍可能继续占用空间；因此，删除文件名不等于空间一定立即释放。发现“文件已经删除但容量没有下降”时，应检查是否仍有进程持有该文件，并结合业务影响选择安全的重载、重启或日志切换方式。
第五步：排除临时文件和失败任务残留
如果增长目录属于临时文件、任务输出或缓存区域，应先确认这些文件是否仍被任务使用，不能按文件名包含“tmp”或“cache”就批量删除。
重点看文件的生成时间、最近访问或修改情况，以及对应任务是否仍在运行。一个已经结束但残留很久的导出文件，与正在生成中的中间文件，处置方式完全不同。对于 inode 耗尽问题，还要注意失败任务可能生成大量零散文件，即使每个文件都很小，也会阻塞新的任务创建文件。
排查失败任务时，应把文件增长时间与调度任务、批处理、导入导出、构建流程或数据同步事件对照起来。如果每次任务失败都会留下中间文件，根因通常不只是“清理不及时”，还包括任务退出处理不完整、重试机制没有复用工作目录，或清理逻辑只覆盖了成功路径。
临时文件的清理应遵循明确条件：确认文件不再被使用，确认没有回滚或重试需求，确认删除不会影响正在运行的任务，并尽量先通过应用或任务系统执行清理。对无法立即确认归属的文件，宁可先转移、隔离或保留现场，也不要直接递归删除。
第六步：判断是否存在业务数据异常写入
当日志和临时文件都无法解释增长时，应把注意力转向业务数据。常见表现包括某类对象数量突然增加、上传或导入任务重复执行、消息消费失败后反复落盘，或者某个租户、接口、任务产生了远超预期的数据。
这类问题不能只从文件大小判断。应结合业务指标、任务记录、应用日志和近期发布内容，确认增长对应的是正常业务高峰，还是异常重复写入。比如，数据目录突然出现大量同类文件，可能意味着任务重复运行；单个数据文件持续增长，则可能是写入没有边界、归档机制失效，或异常数据不断进入系统。
如果数据由数据库、队列、对象同步或本地落盘程序管理，删除底层文件尤其危险。文件系统层面释放了空间，不代表业务状态已经同步，反而可能造成索引不一致、任务重放或数据丢失。处理前应先找到负责写入的应用和数据生命周期规则，明确哪些数据可以归档、重建或重新生成，哪些数据只能通过业务流程处理。
第七步：检查被删除但仍被进程占用的文件
有时磁盘占用持续很高，但目录扫描找不到对应的大文件，常见原因是文件已经从目录中删除，却仍被进程打开。进程继续写入这个文件，空间仍然被占用；只有进程关闭文件描述符后，空间才会真正释放。
遇到这种情况，重点不是重复扫描目录，而是确认占用文件的进程、文件大小、所属服务和删除时间。随后判断该进程是否可以安全重载或重启。对于无状态服务，处理空间释放通常相对直接；对于正在处理任务、持有事务或承担主流量的服务，则应先评估重启影响，并准备切流、暂停任务或其他保护措施。
这类现象也能反向说明日志处理存在缺陷：如果日志轮转后旧文件长期被进程持有，问题可能出在应用没有正确重新打开日志，而不只是磁盘清理策略不够积极。
一套适合值班场景的固定顺序
面对磁盘使用率突增，可以把排查过程固定为一条路径：
- 确认告警对应的挂载点，并同时判断块空间和 inode 是否异常。
- 比较挂载点下各级目录的空间占用和文件数量，找出增长最快的分支。
- 继续定位到具体文件、文件类型和时间范围，区分少数大文件与大量小文件。
- 对照近期发布、配置变更、流量变化和任务执行记录。
- 优先排查日志暴涨，再排查临时文件残留，最后确认业务数据是否异常写入。
- 如果目录扫描无法解释占用，检查是否存在已删除但仍被进程打开的文件。
- 在确认归属、使用状态和恢复方案后，再决定清理、压缩、转移、限流或修复写入逻辑。
这个顺序的核心，是先定位事实，再做处置。容量告警本身只说明结果，不会自动告诉你哪些文件可以删除。真正需要回答的是：空间由谁产生、从什么时候开始增长、是否仍在被使用、删除后是否会破坏业务，以及根因是否还会继续制造同样的问题。
不要把“释放空间”当成问题解决
临时删除几个大文件，可能让告警暂时恢复正常，却把下一次故障的现场一并抹掉。如果增长来自错误日志，应该修复异常循环或日志级别；如果来自临时文件，应补上失败路径的清理；如果来自业务数据，应限制异常写入并处理数据生命周期；如果来自 inode 耗尽，则要改进小文件生成和归档方式。
在生产环境中，更安全的操作通常包括先记录文件路径、大小、时间、所属服务和进程信息，再选择低风险的释放方式。对仍在写入的文件，优先使用应用支持的轮转或切换机制；对不确定归属的数据，先隔离和确认；对无法立即修复的根因，至少补充增长监控和更早的告警。
当空间恢复后，还应继续观察一段时间，确认增长速度已经回落，而不是告警数字短暂下降。只有定位到触发增长的服务、任务或配置，并让它停止重复制造文件，磁盘突增才算真正处理完成。
发布者：jacky，转转请注明出处：https://kubiyun.com/archives/4469
