JMeter+Prometheus+Grafana：打造压测实时监控链路

我最早做压测时，最头疼的就是压完才看聚合报告。跑一次一小时的压力测试，中途完全不知道服务是不是已经打挂了，CPU是不是早就飙满，接口响应时间是不是已经涨了十倍。直到我把 JMeter、Prometheus、Grafana 三个开源工具串成一套实时监控，这个问题才彻底解决。这套组合完全是业界成熟方案，没有自己写一行业务代码，只靠配置就能把压测过程中的吞吐量、响应时间、错误率、线程运行状态全部可视化出来，还能和历史数据对比。

这篇内容不是教科书式的工具介绍，是我自己从零搭建、踩坑、调优后沉淀下来的一套可复现流程。无论你是刚接触性能测试的测试工程师，还是要做全链路压测的运维/开发，照着下面的步骤操作，两小时以内就能跑通一条“JMeter 压测 → Prometheus 采集 → Grafana 展示”的完整链路。后面还会把我遇到过的几个典型坑一并列出来，帮助你少走弯路。

1. 为什么要做这套监控：从“黑盒压测”到“实时可观测”

1.1 压测只看聚合报告，到底缺了什么

JMeter 自带的聚合报告（Aggregate Report）和结果树（View Results Tree）是大家最常用的功能，但它们都有个共同问题：信息滞后。压测过程中你只能看到一个数字慢慢涨，等跑到一半发现 TPS 掉了，想去定位是脚本问题还是服务问题，能查的线索非常有限。更麻烦的是，结果树如果开着，JMeter 自身会积累大量请求对象，导致施压机内存暴涨，压出来的数据本身就不准。

这时候我们需要的是“边压边看”的能力。压测过程中每隔几秒就能看到当前平均响应时间、错误率、请求数、网络吞吐量，最好还能把压测机和目标服务器的系统指标放在同一个时间轴上比对。JMeter 本身不提供实时仪表盘，但它提供了 BackendListener 接口，允许把压测指标周期性地发送到外部监控系统。这就是我们常说的“JMeter + 可视化监控”的组合由来。

1.2 三种工具如何分工，数据流是什么样的

这套方案里三个工具的职责非常清晰：

• JMeter负责产生压测流量，同时通过一个插件把采样器（Sampler）的统计数据暴露成一个 HTTP 接口，格式是 Prometheus 能识别的文本指标格式。
• Prometheus按照固定时间间隔去拉取这个接口，把指标存成带时间戳的时序数据，并附上 job、instance 等标签，方便后续筛选。
• Grafana负责接 Prometheus 数据源，把时序数据画成可视化的折线图、仪表盘、热力图，并且支持告警规则。

整个数据流就是：JMeter 指标 → Prometheus 抓取 → Grafana 展示。也没有中间件需要维护，三个进程看起来是独立的，但逻辑上环环相扣。我一开始也考虑过用 InfluxDB + Grafana 的方案，最后还是选了 Prometheus，理由很直接：Prometheus 生态更通用，不只是压测监控能复用，以后服务监控、数据库监控、K8s 监控都能用同一套底座，学习成本一次投入长期受益。而且 Prometheus 的拉模式（Pull）对压测场景很友好，JMeter 不需要主动推数据，数据链路少一个环节，故障定位就更简单。

2. 工具版本选择与安装准备

2.1 版本规划与端口约定

这类开源组件版本迭代特别快，不同版本间配置语法可能会有差异。我搭建时用的组合是：

端口规划提前想清楚能省很多事。JMeter 插件暴露指标的口径是 9270，Prometheus 自身 Web UI 是 9090，Grafana 是 3000。如果你用 Docker 部署，主机端口和容器端口都要放开，别把容器内部的 9090 映射到宿主机的其他端口，虽然也可以，但增加记忆成本。如果是在公司内网搭测试环境，还需要确认防火墙有没有把这三个端口放通，尤其是 JMeter 那台机器，很多时候 Prometheus 抓不到数据，问题出在 Windows 防火墙拦了 9270 端口。

2.2 JMeter 安装与插件部署

JMeter 安装本身没什么技术含量：去 Apache 官网下载二进制包，解压，配置好 JAVA_HOME，Windows 下双击 jmeter.bat，Linux/macOS 下运行 jmeter.sh。这里我只强调一个容易被坑的点：JMeter 是 Java 应用，它不用安装，但是 JDK 版本必须匹配。JMeter 5.6 官方文档写的很明确，要求 Java 8 以上，但实测下来如果你用的是 JDK 17，一些老插件可能不兼容；如果你还在用 JDK 7，那直接跑不起来。建议统一用 JDK 11，兼容性最稳。

下一步是装 prometheus 监听器插件。我用的插件是 GitHub 上开源项目 jmeter-prometheus-plugin，作者是 ldiego（实际仓库地址是 dolphyfan/jmeter-prometheus-plugin），它的原理就是利用 JMeter 的 BackendListener 扩展点，在压测过程中定时把统计数据聚合成 Prometheus metrics 格式。安装方法很简单：

1. 到项目 Releases 页面下载对应 JMeter 5.x 的 jar 包。
2. 把 jar 放到 JMeter 解压目录的lib/ext目录下。
3. 完全退出 JMeter，重新启动。

这个插件不像 JMeter Plugins Manager 里的东西，没有 UI 管理入口，所以安装完不会看到任何新菜单，很多人会怀疑装没装上。检测方法很简单：新建一个测试计划，添加一个 Backend Listener，看实现类下拉列表里有没有以io.github.ldiego.simplemetrics开头的选项，或者直接在里面输入PrometheusListener。如果列表里有，说明插件加载成功了。如果看不到，八成是 JMeter 版本和插件版本不匹配，或者 lib/ext 下同时存在了两个版本的插件 jar，出现了类加载冲突。

2.3 Prometheus 和 Grafana 的安装方式

Prometheus 安装同样很简单，官方提供了 Linux 二进制包和 Docker 镜像。我日常测试环境喜欢用二进制方式，因为配置文件改起来直观，排障时 tail 日志也方便。

# Linux 下解压并运行 wget https://github.com/prometheus/prometheus/releases/download/v2.45.0/prometheus-2.45.0.linux-amd64.tar.gz tar zxvf prometheus-2.45.0.linux-amd64.tar.gz cd prometheus-2.45.0.linux-amd64 ./prometheus --config.file=prometheus.yml

启动后浏览器访问http://localhost:9090，能看到 Prometheus 自带的简易查询页面，就说明服务起来了。Grafana 我建议直接 Docker 起，数据量不大，也不涉及复杂持久化配置：

docker run -d -p 3000:3000 --name=grafana -e "GF_SECURITY_ADMIN_PASSWORD=admin" grafana/grafana:10.4.0

第一次登录默认账号是 admin/admin，它会提示你修改密码。如果你不想每次手动起服务，可以用 systemd 或 docker-compose 固定成常驻服务。这个阶段出现问题的概率不高，如果端口被占用，调整映射端口就行，但后面配置 Grafana 数据源时 URL 要和映射端口保持一致。

3. 核心配置：打通 JMeter 到 Grafana 的数据链路

3.1 JMeter 侧：Backend Listener 配置

这是整套方案最核心的一步。打开 JMeter，在测试计划上右键 → 添加 → 监听器 → Backend Listener。实现类选择io.github.ldiego.simplemetrics.PrometheusListener，然后配置参数。

插件默认参数有几个值得单独说明：

我真的翻过很多帖子，发现不少人在这个 Listener 上选错了实现类，选了 GraphiteBackendListenerClient，然后填了一堆 Graphite 的配置，折腾半天数据还是进不了 Prometheus。要记住，如果要用 Prometheus 方案，选的就是这个以PrometheusListener结尾的实现类。它内部会启动一个轻量级 HTTP Server，访问http://localhost:9270/metrics就能看到一大串以jmeter_开头的指标，比如：

jmeter_test_requests_count 15230 jmeter_test_mean_elapsed_time 128.45 jmeter_test_errors_count 3 jmeter_test_max_elapsed_time 1024.88 jmeter_test_stddev_elapsed_time 58.32

这里有个细节：reportingIntervalSeconds设得越小，曲线越平滑，但 JMeter 和 Prometheus 的压力都会增大。设得太大，一旦中间发生故障，监控数据丢失的就越多。我压测时一般设 5 秒，既能看到实时趋势，也不会给施压机带来明显负担。需要注意，压测结束前 JMeter 不会主动推最后一批数据到 metrics 接口，所以结束压测后面板可能会缺最后几秒的曲线，这在可视化里是正常的，不要误以为是系统挂了。

3.2 Prometheus 侧：抓取任务配置

Prometheus 采用 Pull 模型，定时访问 JMeter 暴露出来的 metrics 接口。修改 Prometheus 安装目录下的prometheus.yml，在scrape_configs下新增一个 job：

global: scrape_interval: 5s evaluation_interval: 10s scrape_configs: - job_name: 'jmeter_test' metrics_path: '/metrics' static_configs: - targets: ['192.168.1.10:9270'] labels: scenario: 'demo-test'

scrape_interval我故意设成 5 秒，和 JMeter 的上报周期保持一致，这样 Prometheus 通常能抓到每条最新指标。如果 JMeter 上报周期是 10 秒，Prometheus 抓取间隔还是 5 秒，会抓到大量重复值，浪费存储但展示上问题不大。反过来如果 Prometheus 抓取间隔比上报间隔大，比如抓取间隔 15 秒、上报 5 秒，那么曲线会变得粗糙，虽然还能看出趋势，但 P95 这些瞬时值会失真。

targets里的 IP 一定要写 Prometheus 能从网络访问到的地址。如果你在 Linux 上用 Docker 跑 Prometheus，然后把 targets 写成localhost:9270，那 Prometheus 容器里的 localhost 指的是容器自己，不是宿主机，必挂。这种场景要么用--network=host跑容器，要么写宿主机局域网 IP。另外 Prometheus 的 yml 只认 UTF-8 编码，Windows 记事本编辑容易引入 BOM 头，最好用 VS Code 或 Notepad++ 改完再保存。

配置改好后，重启 Prometheus，打开http://localhost:9090/targets，如果新增的jmeter_testtarget 状态是 UP，说明链路前半段已经通了。这一步是分水岭：很多人的问题都出在这，状态不是 DOWN 就是 unknown，那后面 Grafana 怎么配都是白搭，所以建议先在这里多花两分钟确认。

3.3 Grafana 侧：数据源与仪表板导入

Prometheus 的数据进来了，Grafana 的活就轻松了。打开 Grafana，左侧菜单 → Connections → Data sources → Add data source，选择 Prometheus，URL 填http://localhost:9090，点击 Save & Test，看到绿色的返回信息就说明数据源连接成功。

接下来是有两种方式出面板。一种是手动创建 Panel，每个 Panel 写 PromQL 查询，灵活性最强；另一种是直接导入现成的 Dashboard 模板，导入后改一下数据源就行，适合快速搭建。我个人推荐先用现成模板把链路跑通，再逐步改成自己团队习惯的样式。

用模板时，我建议直接用插件仓库自带的grafana_dashboard.json。在 jmeter-prometheus-plugin 的 GitHub 仓库里有个grafana/dashboards目录，里面有官方给出的仪表板定义，里面包含吞吐量、响应时间、错误数、线程数等常用 Panel。下载后，在 Grafana 里 Dashboards → Import → Upload dashboard JSON file 上传即可。如果你不想去翻仓库，也可以在 Grafana 官网 Dashboards 市场搜索jmeter，挑一个 Star 数高的导入，比如常被用的 ID 5496 就是 JMeter 监控模板。导入时注意选择你已经配置好的 Prometheus 数据源，否则模板里的指标全显示成 No data。

手动创建的思路也顺便提一下。新建 Panel，PromQL 查询示例：

# 请求数/S（TPS） sum(rate(jmeter_test_requests_count[1m])) # 平均响应时间，单位毫秒 jmeter_test_mean_elapsed_time # 错误率 sum(rate(jmeter_test_errors_count[1m])) / sum(rate(jmeter_test_requests_count[1m]))

这里有个大坑：插件不同版本对指标名命名不一致，有的叫jmeter_test_requests_count，有的叫jmeter_test_requests_total，还有的带上了_seconds后缀。所以在你写 PromQL 前，先到 Grafana Explore 页面，输入jmeter_，看自动补全的指标列表里到底有哪些指标名，再抄到查询里去。我刚开始就是拿着老博客的指标名一路抄，结果 Panel 上永远没数据，后来一查才发现是新版插件指标命名加了_total前缀。花几分钟探一下真实指标名，省得后面一个 Panel 一个 Panel 地排错。

4. 完整实操：从零搭建一套压测监控

4.1 准备一个最小压测脚本

不要一上来就压线上业务，先用一个本地接口或者公网稳定性高的站点练手。我自己验证环境时，常打http://www.example.com，虽然国外站点延迟高，但不至于轻易打挂自己的机器。

在 JMeter 里创建如下元素：

1. 线程组：线程数 100，Ramp-Up 时间 10 秒，循环次数 10。
2. HTTP 请求：协议 http，服务器地址填入 target host，路径 /。
3. 添加断言：响应代码等于 200 或者响应内容包含某个关键字，确保请求不是全部报错还看起来很正常。
4. 添加 Backend Listener，按 3.1 节的参数配置。

这里我提供一个额外提醒：压测时一定不要勾选结果树监听器。结果树会把每个请求的响应内容存在内存里，100 并发跑 10 分钟，JMeter 内存直接爆掉，压测数据也会因为 Full GC 而抖动。看监控面板比看结果树快得多，也准得多。

4.2 启动链路与验证步骤

按顺序启动组件，顺序其实无所谓，但验证问题时最好有个标准流程：

1. 启动 JMeter，开始压测。
2. 浏览器访问http://localhost:9270/metrics，确认能看到带jmeter_前缀的指标。
3. 访问 Prometheushttp://localhost:9090/targets，确认 target 状态是 UP。
4. 在 Prometheus Graph 页面执行一句最简单的查询，比如jmeter_test_requests_count，确认有时间序列返回。
5. 打开 Grafana，看面板是否出现曲线。

我每次排障都按这个顺序来，一步不通就卡在那一步，不要跳着猜。比如远端 Prometheus 里查得到指标、Grafana 里没数据，那基本就是 Grafana 数据源配置或者 Panel 查询问题；如果 Prometheus 里也查不到，那问题一定出在 JMeter 暴露接口或 Prometheus 抓取配置上。

4.3 面板关键指标的读法

面板不是拉几张图就完事的，关键是读得懂。我常用的几个指标维度：

• TPS / 吞吐量：看rate(jmeter_test_requests_count[1m])或对应指标。它有明显的上升期、平稳期、下降期，如果曲线在压测中段出现断崖下跌，优先怀疑服务端瓶颈或网络问题，而不是脚本问题。
• 平均响应时间：配合线程数看，如果线程数线性上升但响应时间同步飙升，说明系统容量已经到达临界点。
• 错误率：JMeter 指标里以jmeter_test_errors_count为准，计算时要除以请求总数。错误率如果和响应时间同步上升，那很可能是服务端开始拒绝请求或超时。
• P90/P95：新版插件带直方图指标时，可以用 histogram_quantile 计算，比如：

histogram_quantile(0.95, sum(rate(jmeter_test_elapsed_time_bucket[1m])) by (le))

P95 比平均值更能暴露尾部延迟问题。比如平均响应时间只有 120ms，但 P95 已经到了 1 秒，那就说明有近 5% 的请求明显偏慢，这个对用户体验影响是很直接的。只看平均值做性能结论，是很常见的误区。

5. 常见问题与排查技巧实录

5.1 数据链路不通：从端口到 target 状态

先说最容易遇到的一类问题：Prometheus 的 target 状态一直是 DOWN。这种问题通常分几种原因：

• 端口不通：在 JMeter 机器上用curl http://localhost:9270/metrics看接口是否返回，如果本机通、远端不通，就是防火墙或安全组问题。Windows 上很常见，需要主动放行 Java 进程或 9270 端口的入站规则。
• targets 写错：前面说过 Docker 里的 localhost 坑，以及 IP 地址抄错的问题。
• JMeter 没真正启动监听：如果 Backend Listener 配置完成但没保存测试计划，或者 JMeter 进程挂起导致端口没监听，也会出现 DOWN。这种情况直接在 JMeter 机器上 netstat 一下 9270 端口最直接。

还有一个不常见但很隐蔽的情况：JMeter 以 GUI 模式跑时，你可能在脚本里配了 Backend Listener，但没等它完全初始化就点了开始，这时候端口监听稍慢一些，Prometheus 第一次抓取失败后不会重试。遇到这种，把抓取间隔调大一点，多等十秒再看 target 状态。

5.2 指标为空的排查逻辑：指标名对不上

Prometheus target 状态 UP，但 Grafana 面板全是空白，这个场景大家肯定都见过。我排查时第一件事就是去 Grafana Explore 里执行jmeter_开头的自动补全，看看实际有哪些指标名。

这里遇到的坑主要是插件版本升级导致的指标名变化，比如有的版本是jmeter_test_requests_count，有的版本是jmeter_test_requests_total，还有的自定义 prefix 没生效导致指标名带了额外前缀。优先以实际返回的指标名为准，别盲目照抄网上旧配置。其次，Grafana 面板的时间范围如果选的是 last 1 hour，而压测只跑了 5 分钟，曲线显示不出来也很正常，可以切到 last 15 minutes 或 last 5 minutes 再看。

5.3 面板报错与数据源 UID 问题

Grafana 从 9 升到 10 或 11 之后，打开旧面板偶尔会看到类似failed to upgrade legacy queries datasource im7_otuvz was not found的报错。这个报错并不是数据源丢了，而是面板 JSON 里写死的 datasource uid 和当前 Grafana 元数据不匹配，导致查询无法自动升级。

我处理这类问题有两条路：

1. 在数据源设置里复制当前 Prometheus 数据源的 UID。
2. 进入 Dashboard JSON 模型，全局搜索旧 UID，替换为新 UID，保存后重新打开面板。

如果旧数据源已经不见了，那就新建一个 Prometheus 数据源，记下新的 UID，再替换进面板 JSON 里。替换时建议先备份 JSON，毕竟面板内容多，手滑改坏了方便回滚。

5.4 压测结束后的数据尾巴和性能干扰

压测结束后面板曲线戛然而止，这不是故障，是 Prometheus 拉不到新指标了。有些人在压测结束后看到曲线断开，会误以为监控挂了，实际上是正常的结束边界。如果你希望曲线更平滑地收尾，可以在压测结束前让线程组进入“平稳递减”模式，或者加一个持续控空的请求周期。不过在实际业务里，压测停止就是瞬间停止，真实观测边界更重要。

另外，压测过程中如果还有 JMeter 自带的聚合报告监听器在跑，或者结果树开着，都会影响施压机性能。插件的指标上报是异步的，但它只是轻量 HTTP Server，本身影响不大。真正影响 JMeter 的是在压测时打开 GUI 监听器、存取大量响应数据。压测机尽量用命令行非 GUI 模式启动，脚本里只留必要断言和后端监听器，这样施压机资源才能全部给到压测流量上。

6. 优化建议与扩展方向

6.1 抓取频率与数据存储的权衡

Prometheus 默认抓取频率是 15 秒，对常规服务监控够用，但对压测这种短时间高动态场景来说，15 秒太粗了，建议调成 5 秒。同时storage.tsdb.retention.time控制数据保留时长，默认是 15 天。压测数据如果只是临时看，15 天足够；如果要长期做趋势对比，建议开启 Prometheus 的远程存储或者定时把面板截图归档到工单系统。

抓取频率短会导致 Prometheus 本地 TSDB 文件增长加快，但压测场景一般只持续几十分钟到几小时，整体数据量并不大，这个压力可以忽略。真正需要注意的是 JMeter 插件上报间隔和 Prometheus 抓取间隔尽量保持一致，否则会产生大量重复序列，浪费存储空间。

6.2 多机压测与系统监控指标

单机压测是最基础的形式，但真实的全链路压测往往有多个施压节点。每个节点上的 JMeter 都会暴露 9270 端口，Prometheus 的 scrape_configs 里配置多个 targets 即可：

scrape_configs: - job_name: 'jmeter_test' static_configs: - targets: - '192.168.1.10:9270' - '192.168.1.11:9270' - '192.168.1.12:9270'

这样 Grafana 面板上就能按 instance 标签区分每个施压节点的数据。更进一步的实用思路是在所有施压机和目标服务器上装 node_exporter，把 CPU、内存、磁盘、网络指标也接入同一个 Prometheus，这样压测时一眼就能判断瓶颈到底在客户端、网络还是服务端。我自己最常用的一招是：把 JMeter 的 TPS 曲线和被测服务器的 CPU 使用率曲线叠在同一个 Panel 里，一重合就能快速看出服务的容量拐点。

6.3 持续集成与告警自动化

如果你们团队已经有 CI/CD 体系，压测监控完全可以做成自动化：Jenkins/GitLab CI 里触发 JMeter 非 GUI 压测，压测过程中 Prometheus 持续采集；同时通过 Alertmanager 配置告警规则，比如“响应时间超过 500ms 持续 3 分钟”或“错误率超过 1% 持续 5 分钟”，触发后调用企业微信/钉钉机器人通知。这样夜间无人值守压测时，任何异常都能第一时间找到人。告警规则在 Prometheus 里配置也很简单：

groups: - name: jmeter_alerts rules: - alert: JMeterErrorRateHigh expr: sum(rate(jmeter_test_errors_count[5m])) / sum(rate(jmeter_test_requests_count[5m])) > 0.01 for: 3m labels: severity: warning annotations: summary: "压测错误率超过 1%"

这套东西本质上是用开源组件搭了一个轻量级可观测平台，不只是压测能用，服务监控、接口监控甚至业务指标监控都能复用同一套基础设施。我后来在团队里落地时，就是把 Prometheus 配置、Grafana 面板 JSON 以及 JMeter 测试计划模板放到 Git 仓库统一管理，新项目直接复制模板改参数，从准备环境到看到第一个监控曲线通常一支烟的时间就够了。

最后再分享一个我在实际使用中的小技巧：把压测脚本、面板 JSON 和 prometheus.yml 全部纳入版本管理并打上标签。每次压测后，记录这次压测的基准曲线，比如上周的 P95 是多少、TPS 峰值是多少。下次压测时把两次曲线叠在同一个 Grafana Dashboard 里对比，就能非常直观地看出代码变更或扩容带来的性能变化。这种前后对比的价值，比单纯跑一组数据大得多。这套监控方案最开始可能只是为了“看得见”，但真正用熟以后，你会发现它能帮你回答很多比“压测过了没”更重要的问题。