压测监控体系

一、为什么压测一定要配监控

很多人做压测时只看两类结果：

• JMeter 里的响应时间
• JMeter 里的吞吐量

这还不够。

因为压测工具只能告诉你“结果变差了”，却不能直接告诉你“为什么变差”。

例如：

QPS 上不去
RT 变高
错误率升高

真正的原因可能是：

• CPU 打满
• Full GC 频繁
• 数据库慢 SQL
• Redis 连接池耗尽
• 下游服务超时

所以：

压测不是只看接口结果，而是要配套一整套监控体系，才能真正定位瓶颈。

二、压测监控要看哪些层

企业里常见的压测监控，一般分成 5 层：

1. 压测工具层
2. 应用层
3. JVM 层
4. 系统层
5. 依赖层

这样做的好处是：

• 能从外到内看问题
• 能快速判断瓶颈在哪一层
• 能把“现象”和“根因”对应起来

三、压测工具层指标

这一层是最先看到的结果。

常见指标：

• QPS / TPS
• 平均响应时间
• P95 / P99
• 错误率
• 并发数

这些指标告诉你：

• 系统当前表现是否达标
• 性能在加压过程中是上升还是下降
• 在什么流量点开始出现抖动

但这层只能说明“症状”，不能单独说明“原因”。

四、应用层指标

应用层关注的是 Java 服务本身。

建议重点看：

• 每秒请求数
• 接口耗时分布
• 接口失败数
• 线程池活跃线程数
• 线程池队列积压
• 连接池使用情况

例如：

订单接口 RT 高
线程池队列长度持续增长

这通常说明服务处理能力跟不上流量。

如果你用 Spring Boot，常见做法是：

• 暴露 Actuator 指标
• 通过 Micrometer 接入 Prometheus

五、JVM 层指标

对 Java 后端来说，JVM 监控非常关键。

建议重点关注：

• Heap 使用率
• Old 区使用率
• Young GC 次数和耗时
• Full GC 次数和耗时
• 线程数
• 类加载数

典型问题：

QPS 没有继续提升
CPU 也不高
但 Full GC 很频繁

这时瓶颈可能不在业务代码，而在内存分配和 GC。

六、系统层指标

系统层主要看机器资源是否吃满。

常见指标：

• CPU 使用率
• Load Average
• 内存使用率
• 磁盘 IO
• 网络 IO
• TCP 连接状态

需要特别注意几种情况：

1. CPU 很高

可能原因：

• 业务计算太重
• 锁竞争严重
• GC 开销高

2. 磁盘 IO 很高

可能原因：

• 日志写入太多
• 数据库磁盘压力大

3. 网络带宽接近上限

可能原因：

• 返回体太大
• 服务间调用太频繁

七、依赖层指标

很多系统的瓶颈，不在应用本身，而在依赖组件。

常见依赖包括：

• MySQL
• Redis
• Kafka
• Elasticsearch
• 第三方接口

这一层建议监控：

• 数据库连接数
• 慢 SQL 数量
• Redis 命中率
• Redis 慢命令
• MQ 堆积量
• 外部服务响应时间

如果应用 RT 变高，而数据库慢查询也同步升高，基本就能判断根因在数据库侧。

八、一个实用的监控面板结构

压测时可以把大盘分成几块：

1. 压测总览

看：

• QPS
• RT
• P95 / P99
• 错误率

2. 应用服务

看：

• 接口 RT
• 错误数
• 线程池
• 连接池

3. JVM

看：

• Heap
• GC
• 线程数

4. 主机资源

看：

• CPU
• 内存
• IO
• 网络

5. 数据库和中间件

看：

• MySQL 慢查询
• Redis QPS / 慢命令
• MQ 堆积

这样排查时会更快，不需要临时切很多页面。

九、Prometheus + Grafana 怎么落地

这是 Java 项目里非常常见的一套组合。

Prometheus 做什么

负责：

• 采集指标
• 定时抓取数据
• 存储时间序列

Grafana 做什么

负责：

• 展示图表
• 做监控大盘
• 联合查看多种指标

一个常见落地方式

Spring Boot
  ↓
Micrometer
  ↓
/actuator/prometheus
  ↓
Prometheus 抓取
  ↓
Grafana 展示

对于零基础读者来说，先理解这条链路就够了，不必一开始就追求复杂告警规则。

十、压测时如何结合监控看问题

一个实用顺序是：

1. 先看压测结果有没有异常
2. 再看应用 RT 和错误数
3. 再看 JVM 和系统资源
4. 最后看数据库、Redis、MQ 等依赖

例如：

QPS 上不去
P99 很高

继续看发现：

数据库慢 SQL 明显增加
CPU 反而不高

这时就不要再盯着应用线程池，而应该优先去查数据库执行计划和索引。

十一、压测监控常见误区

1. 只看平均值

平均值很容易掩盖长尾问题。

要同时看：

• P95
• P99

2. 只看应用，不看依赖

很多业务接口慢，根因不在 Java 服务本身。

3. 压测结束后才去翻日志

这太晚了。

正确做法是：

• 压测时同步看大盘
• 异常出现时立刻截取时间点

4. 没有统一时间基准

压测工具、应用日志、监控平台时间不一致时，很难对齐问题。

十二、总结

压测监控体系至少要覆盖：

• 压测工具层
• 应用层
• JVM 层
• 系统层
• 依赖层

对 Java 后端工程师来说，最实用的做法是：

• 用 JMeter 看结果
• 用 Prometheus 采集指标
• 用 Grafana 看趋势
• 把接口、JVM、系统、数据库放到同一个视角里分析

这样你才能把“接口变慢”进一步定位到“到底是线程池、GC、MySQL 还是 Redis 出了问题”。