余淏干 Linux 运维这些年，我逐渐发现一件反直觉的事：真正让人凌晨爬起来处理的故障，往往不是 CPU 打满、内存耗尽这种“看面板就知道严重”的问题，而是监控面板上一片绿色时，业务已经悄悄开始报错。聊到 Linux 监控，大多数人的第一反应都是 CPU、内存、磁盘“老三样”，可线上环境最容易埋雷的恰恰是那些默认模板不会重点盯着的地方。比如某个分区明明还剩几十 GB，程序却告诉你 no space left on device；又比如关键服务进程还活着，端口也还监听，但它背后的线程早就卡在一处网络文件系统上动不了。
这类问题我不会再用“隐藏太深”来解释，因为它们本质上就是你没监控到对应的指标。这篇文章我想写一份 Linux 暗坑监控梳理，前半部分带你认识那些容易被忽略的系统层、进程层和依赖项，后半部分给一套可以直接放到服务器上跑的巡检逻辑，顺便讲清楚怎么接进 Prometheus 或 Zabbix。内容偏运维实战，适合已经在跑业务的 Linux 使用者、开发自运维的小团队，以及刚从“看面板”走向“管可用性”的工程师。
1. 别只盯 CPU 内存磁盘，Linux 暗坑往往藏在默认指标之外
1.1 监控面板显示“一切正常”，系统为什么会挂
一旦你开始负责真正的服务器，就会发现一个很尴尬的事实：监控模板上那条 CPU 使用率曲线再漂亮，也解答不了“业务为什么不可用”。因为 CPU、内存、磁盘空间这些指标回答的是资源够不够，而不是操作能不能完成。
举个例子。程序在写临时文件时突然报磁盘满，你跑 df -h 一看，磁盘明明还剩 20 GB；再看看 df -i，分区 inode 使用率已经 100%。每个文件都需要一个 inode 来存放元数据，inode 耗尽后，即使磁盘还有容量，内核也无法再创建任何新文件。这种故障出现时，你的 CPU 曲线正常，内存正常，磁盘空间也正常，唯一在报警的是业务的日志文件。而默认监控面板，根本不会因为你没监控 inode 而主动告诉你。
我见过不少团队，Zabbix 装好了，Prometheus 也接了 node_exporter，但告警规则只套用了默认模板。这不是工具的问题，而是监控思维没转换过来：你想发现“暗坑”，就必须从故障的表现倒推需要什么指标，而不是监控系统给你什么模板就用什么模板。