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 files。

这里有一个关键区别要讲清楚：ulimit -n 是进程级别限制，fs.file-max 是系统全局限制。进程级限制可以先通过 ulimit 临时调，也可以改 /etc/security/limits.conf 永久调；系统级限制则通过 sysctl -w fs.file-max=xxx 调整。当初排查过一个 Java 应用启动失败的问题，ulimit -n 显示 65535 没问题，但 /proc/sys/fs/file-nr 显示全局句柄已经用到上限了，导致新进程无法建立连接，整个集群都跟着雪崩。

进程数和线程数也有同样的坑。老版本 Linux 的内核参数 threads-max 默认值偏保守，如果跑的是大量线程的 Java 服务或容器，很容易触顶。建议把这几项都纳入监控体系：

bash复制# 查看当前全局打开的文件句柄数/上限
cat /proc/sys/fs/file-nr

# 查看当前进程数/系统 pid 上限
cat /proc/sys/kernel/pid_max

# 查看最大线程数
cat /proc/sys/kernel/threads-max

2.3 内存水位的隐藏危机：swap 抖动与 min_free_kbytes

看内存监控别只看一个"used 百分比"，还要看 swap 的换入换出情况和内核保留内存水位。我踩过的坑是：内存明明还有 20% 空闲，但系统响应十分迟缓，vmstat 里 si 和 so 两列疯狂跳动。原因就是 vm.swappiness 设置得太高，导致内核在内存没有真正吃紧的情况下就频繁把冷页换到 swap，IO 一下被打满，服务延迟暴涨。

另一个容易被忽视的风险是 vm.min_free_kbytes。这个参数是内核为"紧急内存分配"保留的物理内存，它太低会导致系统在内存紧张时无法完成关键分配，触发 RCU stall、进程 D 状态卡死等诡异现象。排查思路是：内存不高的场景下，如果突然出现「进程 D 状态但磁盘 IO 很低」的诡异现象，可以顺手查一下这个值。

监控指标方面，node_memory_swap_in_bytes_total、node_memory_swap_out_bytes_total 的增长速率是很好的预警信号，幂等操作是不错的手段，比如 rate(node_memory_swap_out_bytes_total[5m]) 超过 100MB/s 就值得告警了。

3. 内核与调度层面的隐蔽陷阱

3.1 OOM Killer 的静默"谋杀"

我见过很多团队被 OOM Killer 坑过，却很少有人在第一次就想到去查它。故障现象是：某个进程突然被杀了，但监控显示内存还有余量，CPU 也正常，完全没有明显的"警报触发点"。实际上 OOM Killer 在选"牺牲品"的时候，看的并不是整体内存使用率，而是内存压力、cgroup 限额、进程的 oom_score 综合打分。如果某个进程跑在 cgroup 限制之下，即使整机内存还有剩余，也可能触发 cgroup 级别的 OOM Kill。

排查 OOM 要养成第一时间看内核日志的习惯：

bash复制# 查看最近的内核 OOM 记录
dmesg -T | grep -i -E "out of memory|oom-kill"

# Ubuntu/CentOS 也可以看这个文件
grep -i "killed process" /var/log/messages /var/log/syslog 2>/dev/null

OOM 的监控不能只靠 dmesg 捞历史，最好做成实时告警。Prometheus 下可以借助 node_processes_oom_kill 这个 Node Exporter 指标（如果没有，也可以直接做日志关键词采集，把内核日志里出现 Out of memory 的次数暴露成指标再加阈值告警）。

3.2 熵池耗尽：随机数不够，服务悄悄阻塞

熵池大概是 Linux 监控体系里最冷门的指标之一，但它真的能把一个高并发服务打到"卡吐"。现代应用大量依赖随机数——SSL/TLS 握手、UUID 生成、密码哈希，全部需要 /dev/urandom 或 /dev/random 提供随机性。系统熵池的来源是硬件中断、鼠标键盘输入等噪声，一旦熵池被消耗完，应用取随机数时就会阻塞等待。

熵池耗尽的典型表现是：SSL 握手明显变慢、Java 应用启动卡死、Python 的 os.urandom() 阻塞。排查命令：

bash复制# 当前可用熵值
cat /proc/sys/kernel/random/entropy_avail

低于 100 基本就是危险状态了。在没有硬件随机数生成器的虚拟机上，一般建议安装 haveged 或 rng-tools 软件熵源，但这个不能只装不管，还得监控。Node Exporter 已经暴露了 node_entropy_available_bytes 指标，低于某个阈值就告警，同时去检查熵源服务是否正常工作。

3.3 上下文切换与运行队列：CPU 空闲但服务变慢

CPU 长时间跑在 30%，服务却高频超时，这种问题是最让人头疼的排查场景之一。排查到后面往往会发现问题出在两类指标上：上下文切换频率和运行队列长度。

上下文切换过高，意味着 CPU 大量时间花在"切换线程"而不是"执行任务"上。用 vmstat 1 看 cs 列，如果持续在几万以上就要警惕了。另一种情况是 CPU 让出但任务排队等锁，此时 vmstat 的 r 列可能不高，但 sar -q 里的 runq-sz 却很高，进程都在等锁、等 IO、等 CPU 时间片。

这类问题的根子往往要往应用层找：线程池过大、锁竞争严重、忙轮询。但作为运维侧，你应该把这个信号监控起来，尽早发现。node_schedstat_waiting_seconds_total、node_schedstat_timeslices 这类指标可以帮助定位，也可以直接用 node_procs_blocked 观察不可中断睡眠的进程数。D 状态进程长期存在，就得注意是不是磁盘、内核模块或文件系统在拖后腿。

4. 网络层暗坑：连接状态与收包丢包

4.1 TIME_WAIT 与本地端口范围：连接数暴增的连锁反应

高并发服务最梦想不到的网络暗坑，是本地端口耗尽。每次主动发起外部连接，系统都会占用一个本地端口，连接关闭后端口还要在 TIME_WAIT 状态停留一段时间。如果服务单位时间发起的连接过多，而 ip_local_port_range 留给本地端口的范围有限，就会出现"端口不够用"的报错：Cannot assign requested address。

排查ss -s 能概览连接状态分布，ss -tan state time-wait | wc -l 可以精确统计 TIME_WAIT 数量。优化方案通常有三个思路：调整 ip_local_port_range 扩大可用端口范围；开启 tcp_tw_reuse（在内核 4.12+ 中已经默认开启）；改应用从短连接为长连接。这三个里最推荐第三个，治本，但前两个是运维侧最直接的手段。

监控方面，Node Exporter 的 node_sockstat_TCP_TW 就是 TIME_WAIT 数量，node_netstat_Tcp_ActiveOpens 和 node_netstat_Tcp_PassiveOpens 能反映连接速率。如果 TIME_WAIT 数量逼近端口范围总量，就该触发告警了。

4.2 网卡丢包与软中断分布：带宽跑满之前，网卡已经在"内伤"

ethtool -S eth0 | grep -i drop 这套命令，很多运维从没跑过。网卡有大量丢包，并不会直接体现在带宽使用率上，它表现出来的是访问缓慢、偶发超时、TCP 重传率上升。丢包的根源可能是网卡环形缓冲区满了，也可能是中断没有均匀分配到多个 CPU 上。

中断和软中断分布问题在多队列网卡上尤其常见。mpstat -I CPU 1 可以看到每个 CPU 的软中断占比，如果所有软中断都压在一个核心上，超过 100% 就会导致收包停滞。查网卡队列映射情况可以用 cat /proc/interrupts | grep eth0，确认中断是否均匀分布。

监控上，node_network_receive_drop_total 和 node_network_transmit_drop_total 是基础指标，速率版可以通过 rate() 函数计算。建议长期以 1分钟丢包率 > 0 为阈值建一条轻量告警，丢包率的任何持续变化都值得查一下，因为说明系统已经出现瓶颈了。

5. 实践一：用 Prometheus + Node Exporter 补齐监控盲区

5.1 关键指标配置与告警规则

Node Exporter 默认暴露的指标已经覆盖了上面提到的大部分内容，但也有些需要额外开启的采集器。比如 --collector.entropy 在部分版本中是默认开启的，--collector.schedstat 也是，但最好在启动参数里显式声明一次，免得升级后被默认集变化坑了。建议启动命令这样写：

bash复制./node_exporter \
  --collector.cpu \
  --collector.diskstats \
  --collector.filesystem \
  --collector.meminfo \
  --collector.netdev \
  --collector.netstat \
  --collector.sockstat \
  --collector.entropy \
  --collector.schedstat \
  --collector.filefd \
  --collector.loadavg \
  --collector.udp \
  --collector.tcpstat \
  --collector.systemd \
  --collector.processes

Prometheus 告警规则可以合并成一套"暗坑告警集"：

yaml复制- name: linux-hidden-pitfalls
  rules:
    - alert: FileDescriptorHigh
      expr: node_filefd_allocated / node_filefd_maximum * 100 > 80
      for: 5m
      labels:
        severity: warning
      annotations:
        summary: "文件句柄使用率超过 80%"

    - alert: EntropyLow
      expr: node_entropy_available_bytes < 1000
      for: 5m
      labels:
        severity: critical
      annotations:
        summary: "系统熵池值低于 1000，服务可能阻塞"

    - alert: NetworkDrop
      expr: rate(node_network_receive_drop_total{device!="lo"}[5m]) > 0
      for: 5m
      labels:
        severity: warning
      annotations:
        summary: "网卡存在持续丢包"

    - alert: PidHigh
      expr: node_processes_pids / node_processes_max_processes * 100 > 80
      for: 5m
      labels:
        severity: warning
      annotations:
        summary: "进程数使用率超过 80%"

5.2 部署细节和踩坑记录

部署这块有一个新手容易踩的坑：Node Exporter 的 systemd 服务里最好不要用 ProtectSystem=strict，否则部分 collector 没有权限访问 /proc 和 /sys 下的深层节点，指标会缺失一部分，而且没有任何报错，只有 Prometheus 查询时才发现某些指标一直是空的。

另外一个坑是版本差异。不同版本的 Node Exporter 指标命名有过变化，比如 node_filefd_allocated 在早期版本里叫 node_filefd_allocated（没有变），但 node_sockstat_TCP_TW 在部分旧版本里不存在。升级完 exporter 后一定要用 promtool check rules 校验告警规则，别让查询表达式直接失效。

6. 实践二：Zabbix 与轻量脚本方案

6.1 用 Zabbix UserParameter 采集自定义指标

如果你用的是 Zabbix，内置模板里一般不会有这些"暗坑指标"，需要借助 UserParameter 定义自定义键值。方法是在 Zabbix Agent 的配置文件里添加：

ini复制UserParameter=inode.usage[*],df -i $1 | awk 'NR==2 {print $$5}' | tr -d '%'
UserParameter=entropy.available,cat /proc/sys/kernel/random/entropy_avail
UserParameter=filefd.usage,awk '{print $$1/$$2*100}' /proc/sys/fs/file-nr
UserParameter=tcp.timewait,ss -s | grep -o 'timewait [0-9]*' | awk '{print $$2}'

记得在 Agent 配置里把 UnsafeUserParameters=1 打开（老版本还需要设置），否则带 $1 的参数键无法正常工作。添加完键值后重启 Agent，再去前端界面"配置-主机-监控项"里手动添加这几个键，类型选"Zabbix 客户端"，更新时间设为 60 秒。

6.2 不依赖监控平台的快速方案

有些场景你根本来不及上一套完整监控体系，或者手上只有一堆老掉牙的机器，那就直接用脚本 + 定时任务 + 企业微信或钉钉机器人告警。下面这个脚本我用了很久，核心逻辑就是检查几个关键阈值，超了就发告警：

bash复制#!/bin/bash
# 轻量暗坑巡检脚本
HOST=$(hostname)
TOKEN="企业微信机器人 token 或者其他 webhook"

inode_usage=$(df -i / | awk 'NR==2 {print $5}' | tr -d '%')
entropy=$(cat /proc/sys/kernel/random/entropy_avail)
fd_usage=$(awk '{print $1/$2*100}' /proc/sys/fs/file-nr)
timewait=$(ss -s | grep -o 'timewait [0-9]*' | awk '{print $2}')

if [ "$inode_usage" -gt 80 ] || [ "$entropy" -lt 1000 ] || [ "${fd_usage%.*}" -gt 80 ] || [ "$timewait" -gt 10000 ]; then
  curl -s -H 'Content-Type: application/json' -d "{
    \"msgtype\": \"text\",
    \"text\": {
      \"content\": \"[$HOST] 暗坑告警: inode=${inode_usage}% entropy=${entropy} fd=${fd_usage%.*}% timewait=${timewait}\"
    }
  }" "$TOKEN"
fi

这个方案没有图、没有历史曲线，但胜在"低门槛、快落地"。如果临时发现某台机器可疑，我通常还会配合 nmon 录制一把性能数据，nmon -f -s 5 -c 600 就是采集 50 分钟内每 5 秒一次的数据，完成后用 nmon 分析器打开看 CPU、内存、网络、磁盘的联动曲线，排查非常顺手。

7. 常见问题排查实录与速查表

这些真实场景是我自己或者朋友踩过的，整理成表格给大家参考：

7.1 时钟同步与 dmesg 日志的"哨兵"价值

除了上面表格里的几类，还有两个冷门但极其重要的监控维度必须提一下。第一个是系统时间同步。分布式环境里，时间不一致会导致日志乱序、证书校验失败、分布式事务超时、监控数据出现负数差值。建议对所有节点配置 chrony 或 ntpdate 的定时任务，并监控 node_time_seconds 与本地时间服务器的偏移量，超过几百毫秒就要有告警。这个指标 Prometheus 自带 node_timex_offset_seconds 可以直接用。

第二个是 dmesg 日志的异常增长趋势。有些内核层面的问题不会表现为用户态报错，而是不断在内核日志里刷信息。比如某个驱动出错、存储端异常、TCP 重传过多，最后都会体现在 dmesg 上。直接用 Prometheus 的 systemd_unit_state 和日志采集器（如 Promtail/Loki 或 Zabbix 内置日志监控）去采集内核日志中的关键字频率是更明智的，因为 dmesg 是环形缓冲区，出问题时不盯着看，回头再查往往已经被新的日志覆盖了。

7.2 建立"故障定位检查单"

排查多了之后，我把这些易漏点整理成了一个固定的检查顺序，推荐给大家当"黑暗三分钟"救援手册：

bash复制# 1. 容量类
df -h && df -i
cat /proc/sys/fs/file-nr

# 2. 内核状态类
dmesg -T | tail -100 | grep -i -E "oom|drop|error|hung"
cat /proc/sys/kernel/random/entropy_avail

# 3. 调度类
vmstat 1 5
mpstat -P ALL 1 3
sar -q 1 3

# 4. 网络类
ss -s
ethtool -S eth0 | grep -i drop

# 5. 进程类
ps -eo stat,pid,comm | grep '^D'
ps -eo stat,pid,ppid,comm | awk '$1 ~ /Z/'

这套命令 30 秒内能跑完，基本能覆盖 80% 的"暗坑"场景。平时每个月的健康巡检如果也能把这套命令走一遍，很多故障完全可以在用户感知之前被处理掉。

写在最后的一点个人心得

接触 Linux 监控这么多年，我最大的感受是：监控系统的上限不在工具，而在你对操作系统本身的理解深度。Prometheus、Zabbix、夜莺都是很好的工具，但它们只是"眼睛"和"耳朵"，真正能在一分钟内定位问题的，还是你对 inode、文件句柄、熵池、OOM、软中断这些底层机制的熟悉度。建议每个人都给自己维护的机器做一个"暗坑清单"，不需要多复杂，就按上面这几类盯住关键阈值，一旦养成习惯，你会发现很多以前需要加班的故障，其实在 5 分钟内就能解决。最后再分享一个很实用的小技巧：每次处理完一起由监控盲区引发的事故，顺手把这次用到的排查命令和根因整理到自己的笔记里，积累三个月之后，你会意外地发现这套笔记比任何监控平台都值钱。