15年运维团队告诉你：Grafana 看板越多，为什么事故反而更难查了？
发布日期：2026-02-12 阅读数：19
这事儿我见过太多次。
系统一慢，第一反应就是开 Grafana。
浏览器一排标签页，全是 Dashboard。
CPU、内存、GC、QPS、RT、错误率……
指标看起来都没问题，但系统就是慢。
然后就是最熟悉的一句话：
“再观察一会儿。”
十分钟过去了，
问题还在，
人已经开始慌了。
01 真相：指标不足以定位问题
不是 Grafana 不行，
是看板在事故里根本没帮你缩小范围。
大多数看板，只回答一个问题：
现在各个系统状态怎么样？
但是事故真正需要的是另一个问题：
请求现在卡在哪一层？
这两个问题，差得非常远。
02 一个很典型的事故现场
用户反馈接口慢。
我们打开面板进行排查：
- CPU：30%
- 内存：还有富余
- JVM：没 Full GC
- 数据库：QPS 正常
每个dashboard都看了一圈，
可是每个系统都不像“罪魁祸首”。
于是事故就进入了一个很危险的阶段：
大家开始凭感觉排查。
03 CPU不高、系统慢，别怀疑人生
这种情况，十有八九不是算力问题，
而是线程在等。
最直接的办法不是多看图，
而是上服务器看线程状态。
jstack <pid> | grep -E "WAITING|BLOCKED" | wc -l
如果你看到 WAITING / BLOCKED 线程一堆，
而 CPU 依然不高，
那基本可以判断：
请求不是在算，而是在等。
04 接口满，别再只看平均耗时了
事故里，平均值没什么用。
真正有用的是：
- P95（95%）
- P99（99%）
如果你用的是 Spring Boot + Micrometer，
Grafana 里至少要有这种查询：
histogram_quantile( 0.95, sum(rate(http_server_requests_seconds_bucket[5m])) by (le))
很多事故会出现：
- 平均 RT 变化不大
- P95、P99 已经飞了
这意味着：
少量请求已经开始严重阻塞。
05 线程池满没满，很多人从没看过
系统慢的时候，
你有没有看过线程池的真实状态呢？
executor.getActiveCount();executor.getQueue().size();executor.getCompletedTaskCount();
如果你看到：
- active 接近 max
- queue 开始堆积
那接口慢几乎是必然的，
这和 CPU 高不高关系并不大。
06 数据库“没问题”，只因看错了地方
很多人排数据库，只会看：
- CPU
- QPS
- 慢 SQL
但事故里，更致命的是连接池耗尽。
如果你用 HikariCP，
这两个指标比 SQL 本身更重要：
- active connections
- pending threads
一旦 pending 开始出现，
应用已经在排队等连接了。
07 什么是真正有用的事故看板
不是十几个 Dashboard，
而是一个顺着请求路径走的看板：
- 核心接口 P95 延迟
- 应用线程池 active / queue
- JVM 线程状态、GC 次数
- 数据库连接池 & 下游接口 RT
你要做到的是：
值班的人不用思考，就能顺着往下看。
08 一个判断标准，很简单
凌晨三点，人还是懵的。
如果这个看板不能让我们在 5 分钟内判断出：
- 是线程问题
- 还是数据库的问题
- 还是下游接口的问题
那这个看板，
在事故里就是个摆设。
09 写在最后
看板多这件事，本身没错。
但它不等于你真的“看得懂系统”。
真正出事故的时候，
值钱的不是你有多少指标，
而是你能不能第一时间判断问题大概在哪一层。
很多人都经历过这种场景：
- 看板开了一堆，却越看越乱
- 最后还是靠经验、靠猜，硬把事故扛过去
- 复盘时才发现，其实早就有指标在“提醒你了”
这不是能力问题。
而是这些看板，从一开始就不是为事故而设计的。
新闻搜索
相关新闻
云安全风险发现，从现在开始
