之前线上遇到过一次很奇怪的故障至今印象很深。服务间歇性报错日志提示文件写入失败、创建临时文件超时。第一时间去查看服务器磁盘剩余空间很多完全不是爆满的状态。当时排查陷入僵局空间够、权限正常、磁盘IO负载不高没有任何明显异常但服务就是时不时写文件失败随机触发影响导出、日志落地、临时缓存生成等功能。最后排查下来才发现问题根本不在磁盘总大小而是很多人容易忽略的 inode 耗尽问题。平时排查磁盘问题绝大多数人只看磁盘使用率很少有人会主动检查inode占用情况。服务器日常运行会产生大量小文件临时文件、碎片缓存、日志切片残留、失败请求遗留的空文件单个文件极小不占磁盘容量但是每一个都会占用一个inode节点。inode数量是分区固定的和磁盘空间大小无关。哪怕磁盘剩余几十G只要inode被海量小文件占满系统就无法新建任何文件。这就解释了当时诡异的现象空间充足、写入报错。这类问题积累周期很长不会刚上线就暴露。服务器运行几个月甚至半年小文件不断堆积没人清理inode使用率慢慢跑满。最坑的是常规监控大多只监控磁盘容量不监控inode使用率。机器早就临界告警了运维和开发完全不知情直到业务开始报错才发现问题。当时深入查了一下目录发现问题主要集中在几个位置。程序崩溃、请求异常遗留的大量空临时文件长期未清理日志切割工具配置异常旧日志归档残留大量碎片文件定时脚本执行失败产生无数零字节报错文件。这些文件肉眼看不出危害体积几乎可以忽略日积月累直接耗光inode资源。更麻烦的是普通删除文件的操作解决不了根本问题。很多服务正在运行进程持有大量已删除但未释放的文件句柄文件删了inode依旧不释放必须重启对应服务才能彻底恢复。那次故障之后我才意识到磁盘问题真的不止爆满这一种情况。日常运维巡检大家习惯性只看容量、负载、CPU内存忽略inode、句柄数、碎片残留这些隐性指标。这些参数不会瞬间崩服务只会慢慢蚕食系统资源等到问题爆发已经影响业务很久了。后面我在所有服务器都加了inode使用率监控同时优化了临时文件生成逻辑所有临时文件使用后立刻销毁定时清理目录碎片禁止程序遗留无效小文件。线上很多疑难故障看着玄乎本质都是基础资源认知不全导致的。看似正常的服务器内部早就千疮百孔了。