监控全绿，系统却慢

这是运维最头疼的场景：用户反馈接口超时，你打开 Grafana，CPU 30%、内存充足、数据库 QPS 正常、GC 没有异常——一切看起来都好。

但系统就是慢。

根本原因：大多数看板回答的是「系统状态如何」，而不是「请求卡在哪里」。

为什么指标正常但系统慢？

线程在等待，不在计算

CPU 低，只能说明系统没在「算」，不代表系统没在「等」。

当线程池里的线程都在等待 I/O、等待数据库连接、等待下游响应时，CPU 自然不高——但新请求进来，没有线程处理，只能排队。

连接池耗尽

数据库 CPU 40%，看起来正常。但如果连接池已经满了（50/50），应用拿不到连接，请求就会阻塞。这个指标在传统 Grafana 看板里往往看不到。

慢接口拖垮整体

一个接口从 50ms 变成 300ms，对整体 QPS 影响不大，但线程池开始积压，P95/P99 延迟飙升，用户体验已经崩了。

真正有用的排查方向

1. 线程状态分析

# 查看 JVM 线程状态
jstack [PID] | grep -E "WAITING|BLOCKED|TIMED_WAITING" | wc -l

大量 WAITING/TIMED_WAITING 线程 = 系统在等待，不是在计算。

2. 线程池饱和度

检查 executor.getActiveCount() vs executor.getMaximumPoolSize()，而不只是看 CPU。

3. 数据库连接池

监控 HikariCP 的 active 和 pending 连接数，而不只是数据库的 CPU 和 QPS。

4. P95/P99 延迟

平均响应时间会掩盖问题。P95 开始上升，往往是系统开始出问题的早期信号。

如何设计真正有用的看板

一个好的故障看板，应该能在 5 分钟内定位问题，而不需要深度分析。

设计原则：按请求链路组织，而不是按资源类型组织。

接口延迟 → 应用线程池 → JVM 线程/GC → 数据库连接 → 下游服务

每一层都能回答「这里是不是瓶颈」，而不只是「这里的资源用了多少」。

总结

Grafana 看板多不等于监控好。真正有价值的监控，是能在故障发生时快速回答「请求卡在哪里」——这需要从资源视角转向链路视角。