那些你不知道自己需要监控的 Linux 暗坑

做 Linux 运维这些年，最让我头皮发麻的不是服务挂了，而是服务看起来好好的，数据已经在悄悄丢、性能已经在悄悄崩。很多刚接触服务器的朋友满脑子都是 CPU、内存、磁盘这三个指标，等线上出问题了才发现，真正搞死你的往往是你根本没监控过的东西。这篇博文就把我踩过的、以及帮别人排查时遇到的 Linux 暗坑梳理一遍，每一个都是真实场景里碰出来的，希望能帮你省下几个通宵。

这篇文章适合刚入门 Linux 运维的朋友，也适合已经用上 Prometheus 这类监控系统但还在纠结“到底该盯哪些指标”的同学。我会从系统隐藏状态、进程与容器、文件系统、网络连接、监控落地这五个角度去拆，讲到具体命令、具体参数，以及为什么有些默认行为会坑你。

1. 看似没问题，其实早就出事的系统盲区

1.1 负载不高不代表没事，你还要看 runqueue 和上下文切换

很多人习惯用 uptime 或 top 看 load average，觉得负载不高就万事大吉。但这个数字很容易骗人。Linux 的负载计算里包含了处于不可中断睡眠状态的进程，也就是 D 状态进程。比如某次一台数据库服务器 CPU 明明只有 20%，但业务方反馈接口大面积超时，我上去一看 load average 已经飙到 80 多了，原因是有大量进程卡在磁盘 IO 上，全睡在 D 状态里。这种情况你用 top 看 CPU 使用率是完全看不出来的，必须看一眼 load 和进程状态。

更隐蔽的是 runqueue 深度。如果 CPU 一直很忙，但每次调度队列里都堆积了几十个线程在等待执行，说明 CPU 已经过载了，只是平均使用率看起来还有波动空间。我自己习惯长期盯 /proc/loadavg 的同时，也会用 vmstat 1 看 r 列。r 列表示正在运行和等待 CPU 的进程数。如果 r 长期大于 CPU 核数，说明 CPU 资源已经吃紧。还有一个指标是上下文切换，vmstat 里的 cs 列，或者用 pidstat -w 看每个进程的上下文切换次数。上下文切换过多通常是线程数量爆炸或者锁竞争严重，这时候 CPU 看着没满，但大量时间都花在切换上了，响应自然慢。

如果你用监控系统，建议把 node_exporter 的 node_load1、node_procs_running、node_context_switches_total 这三类指标都收进来。只收 CPU 使用率真的是给自己埋雷。

1.2 时间同步漂移：监控里最常见的“灵异事件”

时间不同步这个坑，我见得太多了。有一次线上排查了半天，日志里发现两条记录相差了好几个小时，怎么都对不上，最后一查是其中一台机器时钟漂了。微服务架构里如果各节点时间不一致，链路追踪的日志顺序是乱的，定时任务可能重复执行或者不执行，更重要的是很多认证协议对时间偏移非常敏感，偏差超过几分钟就直接拒绝服务。

现在很多云服务器默认配了 chrony 或者 systemd-timesyncd，但物理机、内网虚拟机、容器环境里常常没人管。我见过不少服务器时间误差已经达到几十分钟甚至几小时，系统里居然没有任何告警。解决方案也不复杂，在监控系统里加一项：比较节点本地时间和 NTP 服务器时间的偏差。用 chrony 的话，chronyc tracking 能看到系统时间与参考时间的误差。手动排查时也可以用 timedatectl 一眼看到 System clock synchronized: yes/no，如果显示 no 就要小心了。此外 /var/log/messages 里偶尔会出现 kernel: Clock: inserting leap second 或者 adjtimex 相关的日志，这也是时间调整留下的痕迹，别忽略。

从监控层面，建议把 node_timex_offset_seconds（node_exporter 提供）或者 systemd_timesync_current_server 这类指标收进来，设置超过 100ms 就预警。别等到业务因为时间戳错乱被用户投诉了才去补。

1.3 文件描述符和进程数上限：你以为的内存泄漏，其实是句柄泄漏

这个坑非常经典：服务跑着跑着突然报 “Too many open files”，但服务本身代码看起来没有任何问题。大多数时候是文件描述符被耗尽了。Linux 对单个进程能打开的 fd 数量是有限制的，默认软限制 1024，硬限制 4096，很多高并发服务根本不够用。先检查全局 fs.file-max 和用户/进程的 ulimit -n，这些用 sysctl fs.file-nr 可以查看当前已分配、未使用、最大文件句柄数。当已分配数接近上限，意味着系统级的 fd 资源快用完了。

我曾经排查过 Java 应用频繁报错的问题，一开始怀疑是内存泄漏，GC 日志翻了几轮无果。最后用 lsof -p PID | wc -l 一看，fd 数量已经爬到上万级，再对比进程占用发现是 HTTP 客户端连接不释放导致的。后来定位到一个全局静态 OkHttp 实例使用姿势不对，每次请求都新建了连接但底层没有正确关闭。如果早点监控 fd 数量的增长曲线，可能几分钟就找到方向了。

监控建议：node_exporter 本身就暴露 process_open_fds（通过 process collector 拿到单个进程的 fd），但需要你开启 --collector.processes 之类的参数才能看到每个进程的。按照我的经验，至少要对关键服务设置进程级 FD 阈值告警，比如超过进程限制的 80% 就预警，同时观察 fd 数量是否存在持续上涨趋势，这是判断“句柄泄漏”最直接的信号。

1.4 内核日志和 dmesg：你不看并不代表它没发生过

很多暗坑是内核帮你扛下来了，但它会在后台做“降级处理”。比如内存压力大的时候，内核会启动 OOM killer 干掉进程；网络邻居表满了会丢 ARP 包；TCP 接受队列溢出会丢 SYN 包。这些事件通常都会写进内核环形缓冲区，也就是 dmesg 能看到的内容。

我自己一般会常驻一个 dmesg -T 的检查脚本，把包含 Out of memory、hung_task、blocked for more than、nf_conntrack: table full、TCP: time wait bucket table overflow 这些关键词的行都抓出来。一旦出现这些关键词，说明系统已经处于某种异常状态，必须马上处理。比如 nf_conntrack: table full 意味着连接跟踪表满了，新连接会被直接丢弃，这种情况在高并发 NAT 或者 Kubernetes 集群节点上非常常见。解决方案是调大 net.netfilter.nf_conntrack_max，或者排查是否有连接没有正常关闭导致表项堆积。

监控工具方面，Prometheus 里的 node_boot_time、node_filefd_maximum 这些是通用指标；要盯内核日志，我一般用 promtail/journalbeat 采集 /var/log/messages 或 journald 里的 kernel 信息，规则匹配上直接告警。很多监控系统都有现成的日志告警插件，但没有日志监控的赶紧补上，因为内核出现异常时，用户态指标往往还没体现出来。

2. 进程与容器里面的隐藏雷区

2.1 前台进程和后台进程：明明在前台跑得好好的，SSH 一断就没了

这个问题看起来很初级，但实际出现在生产环境的频率远超我的想象。有人直接 SSH 到服务器上跑一个编译任务或者数据迁移脚本，前台进程跑了一整天，中途网络闪断，终端一断进程就收到 SIGHUP 死了，所有工作白费。所有说自己“下次注意”的人，大概率都经历过至少一次这种惨案。

这里的关键是理解 Linux 信号机制。终端断开时，控制进程会发送 SIGHUP 给前台进程组，默认动作是终止进程。想避免有两种方案：一是用 nohup 启动命令，它会忽略 SIGHUP；二是配合 & 把进程放到后台，再用 disown 把任务从 shell 的任务表中移除。保守派还会建议结合 setsid，让进程完全脱离当前会话，成为独立的会话领导者。

真正生产环境里我不建议裸跑 nohup，因为 nohup 起的进程没有守护逻辑，挂了不会自动拉起，日志管理也很粗糙。更好的做法是使用 systemd service。写一个 service 单元文件，配合 Restart=on-failure 和 RestartSec=5，系统会自动拉起崩溃的进程。如果有简单的进程管理需求，supervisor 也是不错的选择，它有网页界面，可以手动启停一组进程。监控角度上，前台进程往往是最容易被忽略的，因为它不在 systemd 的管理范围内，你甚至不知道它是不是还活着。手工跑进程后，至少用 ps -ef 记录基线，再用 pgrep -f 关键字 做探活，配合监控脚本定期检查。不然哪天进程崩了，你可能过了一周才发现。

2.2 容器里的 PID 1 和信号处理：docker kill 杀不掉的那个进程

容器环境下的进程监控有一个巨坑：容器里的 1 号进程不是普通的进程。如果用 docker 启动一个 Java 进程，但没有使用 tini 或者 s6 这类 init 系统，那么 Java 进程本身就是容器内 PID 1。PID 1 在内核中有特殊地位，它不会收到普通信号触发的默认处理，除非进程自己实现了信号处理逻辑。这就是为什么有时候 docker stop 或者 docker kill 发 SIGTERM 给容器，Java 进程根本不理会，最后只能超时强杀，导致应用没有优雅下线，数据损坏风险直接拉高。

更麻烦的是孤儿进程的回收问题。如果容器里 PID 1 没有实现子进程回收逻辑，子进程退出后就会变成僵尸进程，没人去 wait 它们。长时间运行的容器里僵尸进程越积越多，最终拖垮 PID namespace。我见过一个容器内僵尸进程堆积到几百个的情况，ps 输出全部变成 <defunct>，应用性能肉眼可见地下降。

监控建议：容器里一定要监控 container_processes，或者直接在宿主机上通过 cgroup 查看某个 container 的进程数和线程数。Kubernetes 环境里，配置合适的 livenessProbe 就非常关键了，一定要探测到实际应用层，比如 HTTP 端口或者健康检查端点，而不是只看进程存在。另外，任何容器基础镜像都建议加 tini 作为入口（或使用 Kubernetes 的进程命名空间共享），这样 PID 1 会负责转发信号和回收孤儿进程。你可能会想“现在都用 K8s 了，单机 docker 没这么复杂”，但 K8s 节点本身也可能遇到 kubelet 没设置 --system-reserved 导致节点资源被吃满的问题。这些都是我在国内大集群里见到过的真事。

2.3 僵尸进程：知道为什么会存在，也要知道怎么清理和预防

僵尸进程这个问题，很多新手会非常恐慌，以为系统没救了。其实僵尸进程是进程生命周期里的正常状态：子进程结束、父进程还没调用 wait() 回收它之前，进程就会进入僵尸状态。它的 PID、退出状态等信息都保留着，但已经不再占用 CPU 和内存。少量僵尸进程不致命，但如果父进程长期不回收，僵尸进程就会堆积，每个僵尸都会占用一个 PID。Linux 的 PID 数量上限默认通常 32768 或更高，听起来很多，但在高频率短生命周期进程的场景（比如大量 cgi、Java 频繁 fork 子进程）里，PID 耗尽不是没可能。

清理僵尸的标准办法是杀掉父进程，让 init/systemd 接管并回收孤儿进程。杀之前要确认这个父进程没有更重要的职责，否则你跟“解决了僵尸进程但把服务搞挂了”就只有一步之遥。预防措施要看具体业务，如果是脚本里 fork 了后台任务，记得 wait 一下；如果是 Java 使用 ProcessBuilder 调外部命令，要注意 process.waitFor()，避免子进程结束但流没人读导致阻塞。

监控手段很直接：ps -eo stat,pid,ppid,cmd | grep ^Z 或者使用 node_exporter 的 node_processes_state 指标，能看到当前处于各种状态的进程数，其中 state 是 Z 的会标记为 node_processes_state{state="Z"}。建议设置持续出现 Z 状态超过 5 分钟才告警，因为瞬时僵尸很常见，没必要大张旗鼓。

3. 磁盘没满却写不进文件，这种存储暗坑怎么排查

3.1 inode 耗尽：df -h 还有几十 G，但 touch test 都报 No space left on device

一个 100G 的数据分区，用 df -h 看还剩 50G，但往里面写文件就报 No space left on device。这种“灵异事件”我遇到过不止一次，尤其是跑消息队列、大量小文件缓存、容器镜像层、邮件队列之类的应用。原因十有八九是 inode 用光了。inode 是文件系统存储文件元数据（权限、属主、大小、数据块指针等）的结构，每个文件或者目录都要消耗一个 inode。如果分区里小文件特别多，即使数据块还有剩余，inode 也会先被耗尽。

检查命令是 df -i，看到 IUse% 如果是 100%，那基本就实锤了。接下来要找出哪些目录占用了最多的 inode，可以用一个 for 循环脚本去统计每个子目录的文件数量。写这类脚本时注意避免递归统计整个目录树导致超时，建议先找一层目录，再逐级缩小范围。

处理方式根据业务不同有几个方向：如果本来就是临时目录，找出来删掉；如果是监控指标、日志、消息队列的持久化数据目录，需要评估扩容或清理策略。长期来看，可以考虑用 inode 数量更大的文件系统（ext4 小文件很多时格式化时指定更高的 inode 比率，或者换 XFS），也可以把海量小文件迁移到对象存储/数据库。

监控上千万别只盯磁盘空间，一定要把 node_filesystem_files_free（空闲 inode）收下来，文件系统文件数使用率超过 90% 就告警，别等 100% 再处理，那时很多服务已经没法写日志了。

3.2 IO 延迟和 iowait 虚高：是磁盘真慢，还是系统在“假装慢”

拓扑工具 top 里有一项 %wa（iowait），代表 CPU 等待 IO 完成的时间占比。很多朋友看到 iowait 高，第一反应是“磁盘坏了”。其实 iowait 高只能说明有进程在等 IO，不能说明磁盘真的很慢。比如某个程序疯狂读写一个已经被淘汰的慢速磁盘，或者在网络文件系统（NFS/CephFS）上做大量元数据操作，本地磁盘可能很闲，CPU 却一直处于等待状态。

排查 IO 问题我更推荐直接用 iostat -x 1，重点看 await（平均 IO 请求处理时间）、svctm（不一定所有版本都有）、util（设备忙碌程度）、以及 %util 是否接近 100%。需要注意的是，%util 100% 在现代 SSD/裸设备上并不代表“饱和”，因为 NVMe 设备支持并行处理 IO，util 计算方式会导致数值虚高。更准确的方法是看 IOPS 是否达到设备极限，以及读写延迟是否超出业务容忍范围。

还有一类坑是 log 文件导致的写放大。比如某应用每秒钟产生很小的日志，但存储底层块设备最小写入单位是 4K，日志每写一次都触发大量元数据更新，长时间下来系统 IO 会非常差。这种情况光扩容没用，得从日志策略上改。

监控体系里，除了 iostat 指标，建议关注 node_exporter 的 node_disk_read_time_seconds_total、node_disk_write_time_seconds_total 等，用 rate 计算一段时间内的平均 IO 延迟。不要只盯着空间使用率，磁盘健康状态同样重要，有条件就加上 SMART 指标监控，很多磁盘是慢慢坏掉的，等你在数据层发现就已经晚了。

3.3 大页缓存和内存回收：为什么 free 显示的内存所剩无几，但其实一切正常

很多新手一跑 free -h，看到 used 内存占了 90% 以上，以为服务器内存不够了，赶紧加内存或杀进程。但实际上这大概率是“大页缓存（page cache）”在起作用。Linux 会尽量把空闲内存用作文件缓存，加速磁盘读写，当应用程序需要内存时，内核会主动回收缓存。free 命令里第二行的 available 才是真正可供分配的内存估算值，而不是第一行的 free 列。

但这里也有个暗坑：在某些高负载情况下，内核回收 page cache 的速度可能跟不上应用内存申请的速度，导致短暂的卡顿甚至触发 OOM。尤其是当你用了 vm.drop_caches 脚本去“手动释放缓存”，生产环境里这绝对是禁忌。清理缓存会导致后续所有读写直接落到磁盘，性能瞬间崩溃。我看到一些监控脚本把 drop_caches 当成常规优化手段在跑，真的非常危险。

真实需要关注的是内存回收行为，比如 sar -B 里的 pgscank/pgsteal 数值，表示每秒扫描和回收的页数。如果扫描数很高，说明内存压力大，页面回收一直在运转，应用延迟会受影响。另一个指标是 swap 的使用。虽然 swap 在大部分场景下是“最后防线”，但如果系统开始大量换入换出，说明内存确实紧张了。使用 vmstat 1 观察 si/so 两列，如果持续不为 0，建议尽快考虑扩容或者调整应用的 JVM 堆等参数。

4. 网络与连接层面那些会被忽略的问题

4.1 TIME_WAIT 堆积：高并发短连接服务时常被忽略的隐形杀手

Linux 在处理 TCP 连接关闭时，主动关闭方会进入 TIME_WAIT 状态，要等待 2MSL（默认 60 秒左右）才能完全释放。短连接高并发场景下，大量 socket 会堆积在 TIME_WAIT 状态，占用内存和端口资源。如果你在 ss -s 里看到 TIME_WAIT 有几万个连接，不一定就是故障，但如果新的连接无法建立，端口被耗尽，那就是问题了。

最典型的案例是早期的新浪微博架构大量使用短连接访问 Memcached/Redis，遭遇 TIME_WAIT 瓶颈。解决方案现在很成熟了，要么让客户端复用长连接（连接池），要么开启 net.ipv4.tcp_tw_reuse（配合 tcp_timestamps）来安全复用 TIME_WAIT 连接。注意不要轻易开启 tcp_tw_recycle，这个选项在 NAT 环境下会导致 TCP 时间戳问题，丢弃别人的 SYN 包，非常坑，好在较新内核已经移除了它。

监控方面，node_sockstat_TCP_TW 这类指标值得盯一下。我通常的做法是观察 TIME_WAIT 长时间超过某个阈值（比如 30000）且仍在上涨时告警，然后重点检查两端是否启用了连接池、代理层连接是否合理复用。

4.2 网卡丢包、软中断和单核打满：吞吐量看着正常，延迟为什么不稳定

单看带宽使用率是发现不了网络隐疾的。有一种情况是网卡中断全部落在同一个 CPU 核上，导致那个核使用率 100%，其它核闲得要命。数据包处理不过来时，网卡环形队列会开始丢包，此时业务表现是延迟抖动，但吞吐量并没有掉太多。用 top 看一会儿，你会发现某个 CPU 的 si（软中断）占用特别高。

处理和排查思路是这样：先用 ethtool -S eth0 看 rx_dropped、tx_dropped 是否有增长；再看中断分布，cat /proc/interrupts 找到网卡中断号，观察它落在哪些 CPU 上。如果集中在一个核，就需要打开 RSS（Receive Side Scaling），调整 ethtool -L 的队列数，或者配置 RPS（Receive Packet Steering）把软中断分散到多个核。物理机上还会遇到网卡队列数不够的问题，这时候可以考虑开启多队列网卡的特性。

监控上，网卡丢包率是个关键指标。node_exporter 里有 node_network_receive_drop_total、node_network_transmit_drop_total，可以按网卡维度观察。不要只看总带宽，那些每秒几十万 pps 的小包对 CPU 的压力远大于几个 Gbps 的大包吞吐，带宽很低的时候也可能把 CPU 中断打满。

4.3 ARP、conntrack、连接表满：内网通信那些“半开半断”的怪问题

内网环境里有一些怪问题，神出鬼没：某台机器偶尔 ping 不通，等一下又恢复了；Kubernetes 集群里 Service 访问间歇性失败。这种问题可能出在 ARP 表或 conntrack 表上。ARP 缓存条目有限，当节点规模大、容器 IP 频繁创建销毁时，ARP 表可能频繁失效。conntrack 的问题更常见，前面提过 nf_conntrack: table full 时内核会丢弃新建连接，这在 Docker/K8s 的 NAT 场景下非常容易被触发。docker 默认创建的 iptables 规则和 NAT 操作，每条新建连接都会写入 conntrack 表，如果节点上有大量短连接，表项会飞速耗尽。

检查命令是 sysctl net.netfilter.nf_conntrack_count 和 net.netfilter.nf_conntrack_max。如果你的连接数确实经常到达上限，除了调大 conntrack_max 之外，还要排查是不是有服务在疯狂创建短连接，或者上游 LB 健康检查频率过高导致连接表被无效探测占满。conntrack 表项占据的内存比较大，盲目调大可能导致内存压力，要结合内存余量评估。

系统日志里出现 conntrack 表满相关的记录，是绝对需要立刻告警的事件。另外 ARP 的 drop 可以在 /proc/net/stat/arp_cache 看到，但多数监控系统没有现成指标，所以我个人的做法是在关键节点上用脚本周期性记录 ip neigh show 的条目数，结合 ping 探测做辅助判断。

5. 监控体系落地：从命令行巡检到一套能用的告警

5.1 先学会“裸眼排查”，再用工具偷懒

有些新人上来就让我推荐监控平台，我对这个问题的回答永远是先学会最基础的那几条命令，不然就算把 Grafana 大屏做得再华丽，你也不知道数据背后的含义。裸眼排查，至少要把这几组熟练掌握：

• uptime / top：负载、CPU 状态、进程资源
• free -h / vmstat：内存、swap、上下文切换
• df -h / df -i：磁盘空间和 inode 使用
• iostat -x 1：磁盘 IO 延迟与吞吐
• ss -s / ss -ant：连接状态统计和具体连接
• dmesg -T：内核日志、OOM、硬件异常
• sar 系列：历史性能数据回溯

我个人的习惯是，在新接手一批服务器时，先写一个巡检脚本把这些信息全部拉一遍，输出到一个时间点快照，这样排查问题时可以对照“正常基线”。所谓暗坑，最可怕的就是你不了解这机器平时的“正常值”长什么样。

5.2 轻量级方案：node_exporter 加 Prometheus，再配一个告警

在一台机器上装 node_exporter，用 Prometheus 抓取指标，再用 Grafana 展示，这是目前最主流的开源监控组合。node_exporter 默认暴露的 collector 基本涵盖前面提到的所有关键指标。不过很多部署默认没有开启所有 collector，比如 --collector.processes 需要手动打开才能获取进程状态、僵尸进程数。同理，--collector.systemd 可以看到系统服务的运行状态，这样 systemd 管理的服务崩溃了能立刻显示异常。

在我自己搭监控的经验里，Prometheus 的告警规则需要花心思调，不能什么指标异常都报，否则你会在告警疲劳里麻木，最后无视所有告警。比如僵尸进程偶尔出现很正常，阈值可以设在 20 以上持续 10 分钟；但 inode 使用率超过 85% 就可以预警，因为它增长往往非常快，内存不足导致 OOM 这类事件则应该 immediate 告警。不同指标的预警策略差别很大，这需要你对业务的敏感程度、监控对象的类型有理性的判断。

5.3 给“看不见的问题”设置一次性巡检脚本或 cron 任务

即使上了完整监控系统，也建议保留下面的习惯：用 cron 周期执行一个巡检脚本，把关键输出写到日志文件或发送到统一日志平台。比如检测到 dmesg 里出现 OOM 关键词，或者磁盘 inode 超过阈值，脚本可以直接通过 webhook 发到企业微信或钉钉。这不是重复造轮子，很多暗坑只有在事件发生前后几分钟的日志里才能看到，如果监控系统没有相关指标，日志巡检就是唯一的一根救命稻草。

也有更轻量的思路，比如用 Ansible 批量分发巡检脚本，汇总结果到一台 master 上集中分析，适合没有专门监控平台的小团队。脚本本身不需要多复杂，核心是：先采样快照，再比较前后差异，最后把异常发送出去。bash 写起来完全可以，可读性最重要。

5.4 虚拟化环境里的特殊监控场景：时间、CPU 模型和嵌套虚拟化

虚拟化环境跟物理机有不少区别，比如前面提到的“此主机不支持 intel vt-x”这类提示，其实就属于虚拟化监控范围里的一种特殊情况。你在 VMware Workstation 这类桌面虚拟化软件里跑嵌套虚拟机时，如果宿主机的 CPU 没有开启 VT-x，或者嵌套虚拟化设置不正确，虚拟机里就没办法用 KVM 这类需要硬件虚拟化支持的方案。

对于生产环境的虚拟机（无论 VMware、KVM 还是公有云），时间同步问题尤其值得注意，虚拟机的时钟抖动风险高于物理机，所以必须开启 NTP/chrony。还有一个容易被忽略的 CPU 调度问题：当宿主机上多个 vCPU 抢占物理 CPU 时，VM 里观察到的 CPU 使用率正常，但实际业务就是变慢了，因为虚拟 CPU 在等待宿主机调度。这种情况在宿主机上可以用 esxtop（VMware 环境）或 virsh vcpuinfo 来确认。从 Node 级别能做的监控就是 CPU steal time，对应 node_exporter 的 node_cpu_seconds_total{mode="steal"}。如果你发现虚拟机明显变慢，但系统指标一切正常，先看看是不是宿主机超卖严重，steal 值极高。

虚拟化场景下 IO 也容易出问题，尤其是共享存储、网络存储。物理磁盘坏道可以看到 SMART，虚拟磁盘底层就不可见了。所以虚拟机里异常 IO 延迟需要用业务层、应用层指标去补，比如数据库慢查询增多、消息队列消费延迟变大，这些业务端反馈往往比系统指标更早暴露存储问题。

6. 速查表：遇到这些症状，先查哪里

这张表我每次带新人都要发一份。不是所有问题都会直接写进你监控大盘的前几个页面，但绝大多数问题都能在操作系统底层的某个计数器中留下痕迹。你缺的不是服务器权限，也不是监控平台，而是一张覆盖这些“暗坑”的检查清单。

7. 个人实战经验总结

做了这么多年 Linux 环境监控，最大的感受是：绝大部分线上故障不是突然出现的，而是早就有了苗头，只是监控没覆盖到。CPU、内存、磁盘这些指标只能告诉你“机器在忙”还是“机器快死了”，真正定位问题靠的是更细的子系统指标和内核日志。

如果你是刚入门的运维或后端开发，可以从每周手动跑一遍上面总结的命令开始，把结果保存下来，感受一下什么是“这台机器的正常状态”。等你能一眼看出 dmesg 输出里的异常关键词，能在地铁上用手机看一眼 Grafana 告警就判断出大概方向，你才算真正迈过了 Linux 监控这道坎。

给一个最实际的建议：不要一次性把几十个告警规则全加上，先挑五个最痛的指标（load、磁盘空间、inode、fd、内核错误日志），跑两周，再逐步把上面这些暗坑指标加进去。克制一点，告警才有力量。