Linux监控暗坑排查：inode、文件句柄与OOM告警实践

从一次凌晨三点的故障说起。某次客户报障说应用写库超时，我登上机器看了一眼：CPU 不到 30%，内存用了 60%，磁盘还有 200G 空闲，网络带宽也没跑满。监控大屏上全是绿灯，可服务就是一直报错。排查到凌晨四点半，才发现根因是磁盘 inode 耗尽——空闲容量看着充裕，但文件系统的目录项索引已经全部用光，新文件根本创建不出来。从那之后我就意识到：常规的 Linux 监控体系，覆盖的是 CPU、内存、磁盘、网络、IO 这五类"明面资源"，而真正让系统"突然死亡"的，往往是那些平时没人盯的"配额、状态、内核参数"类暗坑。这篇文章就把我踩过的这些坑整理出来，顺便给出可以直接抄作业的监控方案，适合正在搭 Prometheus、Zabbix、夜莺这类监控体系的运维朋友参考。

1. 为什么常规监控会漏掉这些"暗坑"

1.1 监控统计的是"结果"，不是"能力边界"

大多数监控系统展示的指标，都是资源的使用量：CPU 用了百分之多少、内存还剩多少、磁盘占用多少。这类指标有一个共同特点——它们描述的是"当前状态"是否健康，而不是"系统还剩下多少余量去应对突发"。但 Linux 下面真正的灾难，往往不是资源用满，而是"配额耗尽"。

inode 就是最典型的例子。df -h 显示的磁盘空间完全正常，但 df -i 可能已经 100% 了。数据库在跑、日志在写、临时文件在创建，每一个文件都需要消耗一个 inode。你把监控全配齐了，唯独漏掉了 inode 的告警，那"磁盘写满"这个事故就会以另一种形式出现：进程报No space left on device，你查磁盘却发现还有几十 GB 空闲。

这类"能力边界"指标还有不少：/proc/sys/fs/file-nr 对应的文件句柄上限、pid_max 对应的进程数上限、ip_local_port_range 对应的本地端口范围、kernel.threads-max 对应的线程数上限。它们平时都极其稳定，稳定到让人完全忽略它们的存在，一旦打满，系统就像被按下了暂停键，而且报错信息往往还极具迷惑性。

1.2 三类最容易形成监控盲区的 Linux 指标

基于我的实战经验，被忽略的监控点可以归纳成三类。

第一类是限额类。这类指标平时变化缓慢，不会像 CPU 那样出现明显的尖刺，所以没有人给它们配告警。但它们的耗尽是不可逆的、瞬间的、静默的。inode、文件句柄、pid、内存锁页都属于这一类。我的建议是：所有限额类指标都要配"百分比用量"告警，阈值设在 80% 就要开始注意。

第二类是内核状态类。OOM Killer 触发了没有、系统时间悄悄漂移了多少、熵池还剩多少随机数、dmesg 里是不是被某种报错刷屏了。这类问题不会直接显示成"红色的高水位"，但它们的影响往往是大范围的。OOM Killer 静默杀掉进程的时候，监控大屏上看不到任何异常，只有 be 日志和内核日志里有记录。

第三类是软性性能类。上下文切换频率、软中断分布、D 状态进程数、运行队列长度。这些指标不会直接导致宕机，但它们是"系统在亚健康状态"的早期信号。CPU 空闲但服务变慢的场景，十次里有八次是这一类指标出了问题。

2. 系统级暗坑：这些 Linux 指标应该真正盯住

2.1 inode 耗尽：磁盘有空间，服务却写不进去

inode 这个问题我见过的场景太多了，从小型服务器到大规模集群都发生过。它的根因通常是两类：一类是小文件数量爆炸，比如某个服务把临时文件写到某个目录后没有清理，每个会话产生几个 4KB 的小文件，几百万个会话就能把 inode 吃光；另一类是日志文件管理策略有问题，日志切割老化了，但旧日志没有被删除，而是累积出了海量的归档文件。

排查命令其实很简单，df -i /data 一看使用率就明白，find /data -xdev -type f | wc -l 可以粗算文件总数，for i in /data/*; do echo $i; find $i -xdev -type f | wc -l; done 可以定位到具体目录。真正麻烦的是恢复过程：因为 inode 耗尽时，你连 touch 一个空文件都做不到，清理起来往往要借助 rsync --delete 同步空目录的方式去批量删文件。

监控方面，Node Exporter 的 node_filesystem_files_free 就是给这个用的。Prometheus 告警规则建议这样配置：

yaml复制- alert: InodeUsageHigh
  expr: (1 - node_filesystem_files_free / node_filesystem_files) * 100 > 80
  for: 10m
  labels:
    severity: warning
  annotations:
    summary: "{{ $labels.mountpoint }} inode 使用率超过 80%"

2.2 文件句柄与进程、线程上限：连接风暴的隐形杀手

文件句柄耗尽经常和高并发服务绑定出现。客户端数量暴增、连接没有正常关闭、代码里打开了文件没有释放，都会让句柄数一路狂奔直到打满 ulimit -n 或系统级的 fs.file-max。它造成的故障现象很统一：`Too many open