1. 为什么推荐把这三个工具搅在一起做性能测试的朋友大概率都经历过这个尴尬场景JMeter 脚本跑起来了压测正在进行可你只能干瞪眼等聚合报告最终结果。聚合报告是静态的要等测试结束才能看到完整数据就算实时看着查看结果树也只能看到一堆绿色红色压根谈不上实时监控。后来我换成了JMeter InfluxDB Grafana这套组合情况完全不同。JMeter 负责发压InfluxDB 负责存时序数据Grafana 负责把数据画成看得懂的曲线面板。压测从启动那一刻起吞吐量、响应时间、错误率、线程数全都在大屏上实时跳动哪里出现拐点、哪个接口开始变慢一眼就能看出来。这套方案特别适合搞接口压测、全链路压测或者日常性能回归的人。不管你是刚接触性能测试的小白还是已经折腾过一段时间的老手只要想把压测过程看得明明白白这套组合都值得搭建一次。我先说结论这套方案最大的价值不是看上去很酷而是它把性能测试从跑完看报告变成了边跑边看趋势让你在测试过程中就能发现瓶颈、定位问题而不是等全部跑完才发现数据异常还得重跑一遍。2. 搭建前的方案选型与组件认知2.1 三个组件各自扮演什么角色JMeter是压测工具这个不用多解释。但它本身有个短板虽然自带监听器比如聚合报告、图形结果但这些结果都保存在内存里测试一停数据就没了而且不适合做长时间压测的趋势分析。InfluxDB是时序数据库简单说就是专门用来存储按时间变化的数据的数据库。压测过程中每秒都会产生大量指标数据比如当前并发数、响应时间、TPS 等这些数据天然适合用时序库来存储。InfluxDB 能把这些数据按时间顺序排好写入和查询速度都很快。Grafana是可视化平台从 InfluxDB 里查数据然后把数据画成折线图、柱状图、仪表盘支持自定义面板还能多个数据源整合到一个仪表盘里。它的界面是网页版的浏览器打开就能看非常适合放在显示器上做大屏监控。打个比方JMeter 是发电厂InfluxDB 就是蓄水池Grafana 是把水表装在你家客厅的仪表盘。电厂发多少电、水流多快你在客厅随时能看清楚。2.2 版本选型先说避坑经验JMeter建议直接用当前最新的稳定版比如 5.4 以上。老版本有些监听器配置选项对不上网上资料也比较少遇到问题不好排查。JMeter 是 Java 写的需要提前装好 JDK 8 以上的环境。验证方式很简单命令行输入java -version能正常输出就行。InfluxDB这里有个重要分叉点。InfluxDB 1.x 和 2.x 的差异非常大从端口、数据库概念到 API 写法完全不一样。如果你是为了跟 JMeter 搭配搭建压测监控我个人强烈建议用 InfluxDB 1.8。原因很简单JMeter 的后端监听器Backend Listener官方推荐的客户端就是适配 InfluxDB 1.x 的网上能找到的模板、教程九成以上都基于 1.8出现问题能搜到现成的解决方案。2.x 引入了 token 认证、bucket 等新概念JMeter 接入需要额外写 Flux 查询脚本折腾成本高不少收益却不大。Grafana版本相对没那么敏感下载最新的稳定版即可默认端口是 3000。Grafana 主要靠浏览器访问只要服务器能开网页就行。2.3 组件安装与启动流程三个组件都是免安装的绿色软件解压即用。InfluxDB 1.8解压后打开配置文件 influxdb.conf重点确认两处bind-address和[http]部分。默认 HTTP 端口是 8086不用改。启动方式是命令行进入解压目录执行influxd注意是 influxd带 d 的是服务端。启动成功后访问http://服务器IP:8086/ping返回正常内容就说明服务起来了。Grafana解压后Linux 下执行bin/grafana-serverWindows 下执行grafana-server.exe。默认端口 3000浏览器打开http://服务器IP:3000首次登录账号密码都是 admin。登录后系统会强制让你改密码不着急的话可以先改成简单密码。JMeter解压后 Windows 下双击bin/jmeter.batLinux/mac 下运行bin/jmeter.sh。看到 JMeter 界面弹出来就说明 OK 了。安装这块基本没有难度但我还是建议把三个组件都放到一台专门跑监控的机器上而不是放在压测机发压的那台机器上。因为高强度压测时压测机本身的 CPU 和内存可能已经占用很高如果再让 Grafana 渲染、让 InfluxDB 写入磁盘可能会出现监控数据延迟甚至丢失反而影响判断。尤其是 InfluxDB 的磁盘 IO 消耗比较大放在压测机上很容易拉低压测机的性能导致测试结果出现明显的断崖式下跌但其实是监控组件在抢资源。3. 打通 JMeter 与 InfluxDB 的数据链路3.1 创建数据库和保留策略InfluxDB 1.x 启动后先在服务器上用命令行创建数据库。进入 InfluxDB 解压目录执行influx进入命令行客户端然后执行CREATE DATABASE jmeter; SHOW DATABASES;正常情况下能看到 jmeter 这个库。这一步其实就是在蓄水池里划了一块区域出来JMeter 的数据专门往这块区域写。这里提一下保留策略的问题。默认情况下新建数据库会带一个autogen的保留策略数据无限期保存。压测数据如果一直堆积磁盘迟早被吃满。我建议做一次压测就清一次数据或者创建一条保留策略CREATE RETENTION POLICY rp_7d ON jmeter DURATION 7d REPLICATION 1 DEFAULT;这条命令的意思是jmeter 库里的数据只保留 7 天超过自动清理。压测数据一般不需要长期留存保住最近几次的结果就够复盘了。3.2 JMeter 后端监听器配置这是整个搭建过程最核心的一步。打开 JMeter在你的测试计划下添加一个监听器 → 后端监听器Backend Listener。这个监听器跟普通的聚合报告不一样它专门负责把测试过程中的指标数据实时推送到外部存储。后端监听器有两个关键配置项后端监听器实现和参数配置。后端监听器实现选择org.apache.jmeter.visualizers.backend.influxdb.InfluxdbBackendListenerClient这个是 JMeter 官方提供、专门用于对接 InfluxDB 的客户端实现。参数配置里最重要的三个参数influxdbUrl形如http://监控机IP:8086/write?dbjmeter注意这个 URL 已经带上了/write?dbjmeter表示往 jmeter 这个库写入数据。application这是用来区分不同测试计划的标签比如app_test、order_interface。强烈建议每类压测任务用不同的 application 名后续在 Grafana 里筛选不同压测场景就靠它。testTitle当前测试的名称会显示在监控面板上方便识别正在跑的是哪一轮测试。其余参数比如samplersRegex可以通过正则过滤要采集的 sampler默认留空就行。percentiles参数控制要统计的百分位默认 99、95、50 三个常用的。如果只关心 95 线改成 95 就行面板里就会少一条线。配置完这些参数后一定要保存测试计划再试跑一次。压测过程中数据会源源不断地写入 InfluxDB。3.3 验证数据是否真正写入这一步很多人会跳过但恰恰是排查问题最有效的动作。压测运行十几秒后回到服务器命令行进入 influx 客户端执行查询USE jmeter; SELECT * FROM jmeter LIMIT 5;正常情况下能看到返回结果里面有application、testTitle、avg、count、max、min、pct95、pct99等字段。看到这些字段说明 JMeter → InfluxDB 这条链路已经通了。提示如果 SELECT 查询什么都查不到先别急着翻 Grafana问题大概率出在后端监听器的 influxdbUrl 写错了或者数据库名称对不上。先在这一步把数据问题定位干净再去折腾 Grafana。4. Grafana 面板配置与自定义指标4.1 添加 InfluxDB 数据源浏览器打开 Grafana 地址登录后进入 Dashboard 管理。第一步先添加数据源点击页面左侧的设置图标齿轮进入Data Sources然后 Add data source。数据源类型选InfluxDB注意选 1.x 的版本。填写三个关键信息URL填写http://监控机IP:8086不要写数据库名这是数据源层连接 influxdb 服务本身。Database填写jmeter就是刚才创建的数据库名。HTTP Method建议选 GET。填完点击 Save Test如果提示数据库连通正常说明 Grafana 和 InfluxDB 已经打通了。4.2 导入模板快速拥有专业面板手写 Grafana 面板比较费时间好在社区已经提供了大量现成的 JMeter 监控模板。InfluxDB 1.x 的经典模板里我比较推荐 ID 为 5496 的那套JMeter InfluxDB Dashboard支持查看当前并发数、响应时间分布、TPS 曲线、错误率等核心指标。导入模板的方法在 Grafana 里点击号 → Import输入模板 ID然后在下方选择刚才配置好的数据源确认导入。如果网络环境不方便在线拉模板也可以直接下载 JSON 文件后通过 Upload JSON file 的方式导入。有朋友会问模板 ID 是不是必须记住其实不用直接在 Grafama 官网 Dashboard 页面搜索 JMeter InfluxDB 就能找到一堆。找的时候留意一下模板适配的数据源类型有的模板是适配 Prometheus 数据源的跟 InfluxDB 不匹配导进去也显示不了数据。4.3 常用指标说明与面板微调模板导入后你会看到一排排图表。挑几个最常用的指标简单说明Test started / Running Time测试开始时间和已运行时长方便确认当前测试的状态。Total Threads / Active Threads显示当前并发线程数这条曲线能直观反映压测的线程增减过程比如爬坡是否按预期进行、线程是否在某时刻突然掉线。Avg Response Time平均响应时间曲线如果出现断崖式上涨大概率是系统处理不过来开始排队了。TPS / Throughput吞吐量每秒完成的请求数。这条曲线跟响应时间曲线配合着看能判断系统的处理容量边界。Error Rate错误率接口报错的比例。压测过程中错误率突然升高是异常最直接的信号。Http Code 响应码拆分有的模板会展示 200、404、500 等状态码的分布情况对于接口压测非常实用。模板里的面板布局不一定是完全符合你需求的可以点每个面板的编辑按钮修改查询,也可以拖拽调整位置。比如我把响应时间拆成了 95 线和 99 线两张图因为这两个指标对用户体验的判断比平均值敏感得多。4.4 数据聚合写法与核心查询逻辑如果你需要自己在 Grafana 里写查询还是要懂一点 InfluxQL 基础。JMeter 写入的数据都带 tags比如 application、testTitle、samplers 等这些是可以在查询里用于过滤的维度。比如我想看某个特定测试计划的 TPS查询可以这样写SELECT sum(count) FROM jmeter WHERE (application my_app) AND $timeFilter GROUP BY time(1s)$timeFilter是 Grafana 自动带入的时间范围参数。GROUP BY time(1s)表示按秒聚合出来的就是每秒的请求总量。如果模板里已经写好了查询尽量不要动但如果你发现模板里的字段跟你实际写入的字段对不上就可能需要按上面这种方式手写。以前有朋友问到sum by的用法这其实更多是 PromQLPrometheus 查询语言里的语法用在 Grafana Prometheus 的监控体系里。如果你只用 JMeter InfluxDB这个地方不用纠结 InfluxQL 就够了。5. 常见问题与排查技巧实录这套方案我搭过不下十次有些问题反复出现整理成一份排查速查表按这个顺序检查大概率能救你于水火。5.1 Grafana 面板没有数据的排查顺序这是最常遇到的问题面板是有的就是不出图。我的排查顺序是确认 JMeter 是否在运行。没跑压测的时候后端监听器不会产生数据面板自然空白。确认 InfluxDB 里有没有数据。用前面的 SELECT 查询验证。没数据就回头看第 3 步有数据就直接去查 Grafana。确认数据源配置对不对。URL 写错、数据库名写错都是低级的硬伤。确认 Grafana 面板的时间范围。面板默认显示最近 15 分钟的数据如果你压测是半小时前跑的切到Last 6 hours或者点刷新按钮。确认模板的查询字段是否跟数据一致。比如模板配置的是measurement名称但你的数据是另一个名称。5.2 InfluxDB 报错 no space left on device这个是热词里出现频率很高的报错遇到别慌多半就是磁盘满了。InfluxDB 在写入数据前需要写 WAL预写日志磁盘空间不够时就会报这个错误。排查方法用df -h查看磁盘空间重点看 InfluxDB 数据目录所在分区。清理方式有两种快速释放空间的直接清理旧数据比如执行DELETE FROM jmeter WHERE time now() - 1h或者彻底一点停掉 influxd删除 data 目录下的 WAL 或 TSM 文件再重启。根本解法是配置好保留策略让超过保留时间的旧数据自动清理。如果你一直没用保留策略压测数据日积月累磁盘早晚会被吃满。还有一个小坑如果 InfluxDB 的 WAL 文件本身损坏了重启时会一直卡在启动阶段日志里反复刷 WAL 相关的错误这时也需要清掉 data 目录里 wal 子目录的内容再启动。5.3 JMeter 后置监听器无效面板一直没有实时变化这个问题经常出现在 JMeter 和 InfluxDB 之间的时间不同步的场景。Grafana 面板左上角显示的是浏览器时间InfluxDB 数据写入用的是服务器时间如果两个时间偏差太大面板刷新时数据还没写入对应的区间看起来就像没数据。排查时看一下压测机和监控机的系统时间是否一致不一致就同步一下时间。实际测试环境中多个压测节点的时间校准过面板上的曲线才会严丝合缝。5.4 InfluxDB 连接被拒 / 写入失败后端监听器日志里如果看到连接被拒、连接超时的报错按两层排查先确认 influxd 服务进程是否还在运行防火墙是否放行了 8086 端口。再确认 influxdbUrl 是否拼写正确。特别是容器化部署的场景如果 JMeter 在本地、InfluxDB 在容器里URL 里的 IP 不能写 localhost要写容器的宿主机 IP 或者 Docker 网络里的容器 IP。有个小技巧在 JMeter 能访问到 InfluxDB 的那台机器上浏览器访问http://监控机IP:8086/ping通了就说明网络层面没问题。5.5 模板导入后报变量错误新版 Grafana比如 9.x、10.x在导入老模板时会提示版本不兼容有时候会出现变量没有默认值的报错。处理方式不复杂进入仪表盘设置 → Variables把变量的默认值配上特别是数据源变量确保它引用的是当前实际配置的数据源名称。6. 基于这个平台的压测实战经验延伸6.1 性能测试完整流程与实时监控的结合很多同学在做 JMeter 性能测试时只关注能不能跑出报告忽略了一个重要观念压测过程中实时数据比最后的报告更能说明问题。举一个我自己的实际案例有一次压测一个订单查询接口脚本每秒钟发 100 个请求聚合报告跑完后显示平均响应时间 120ms看起来一切正常。但回放 Grafana 面板时发现从测试第 80 秒开始响应时间就从 30ms 开始缓慢爬坡到第 150 秒变成了 350ms。因为全程是平均值的平滑曲线最终报告看起来差异不大但实际上系统已经出现了明显的性能退化。如果当时没有 Grafana 实时趋势图这个问题根本发现不了报告看起来合格实际上系统存在严重的慢查询隐患。后来我把这个接口放到多次压测里验证趋势最终定位到数据库索引失效的问题。6.2 压测过程的三看技巧实际压测中我习惯盯着 Grafana 面板做三个维度的判断一看趋势响应时间曲线是否平滑有没有突然的毛刺或断崖。曲线不是平缓的大概率是系统某层在做不稳定的事情比如 GC 停顿、缓存击穿、连接池重建。二看瓶颈TPS 增长速率是否和线程数增长匹配。如果线程数翻倍但 TPS 没涨别急着加压力先看系统是不是已经到了处理上限。这时再去配合监控系统的 CPU、内存、磁盘 IO 面板查资源消耗。三看异常拐点错误率曲线一旦出现拐点要立即看是哪个接口报错、错误码是什么。比如 500 报错激增说明后端服务已经崩溃超时错误增多说明队列开始堆积了。这些信号通过实时监控能提前捕捉到等压测跑完再分析压力可能已经对生产环境造成了影响。6.3 多台负载机分布式压测时的监控要点如果你的压测规模比较大JMeter 会采用分布式结构一台控制机Master带多台负载机Agent。这时候有个细节需要留意InfluxDB 后端监听器只需要配置在控制机的测试计划里负载机上不需要单独配置。原因很简单负载机把数据回传给控制机由控制机统一上报给后端监听器。但这也带来一个问题数据采集的实时性可能受制于控制机和负载机之间的网络。如果负载机数量多控制机回传压力大可以考虑在每一台负载机上单独配置后端监听器用不同的 application 名区分这样 Grafana 面板还能对比不同负载机之间的性能差异。6.4 压测平台与监控体系的关系这套三件套方案是业务压测视角的监控一定要和其他运维监控工具区分开。比如网上经常能搜到 Prometheus Grafana 的监控方案多用于采集服务器 CPU、内存、磁盘、网络等系统级指标或者配合 node-exporter 做系统告警。这些系统指标和 JMeter InfluxDB 的压测监控之间是一种很好的互补关系。压测过程中业务层的 TPS、响应时间异常往往跟系统层的资源耗尽脱不开关系两套监控对比着看定位问题就快得多。如果你已经搭了裸机或容器环境的监控平台完全可以在同一个 Grafana 里把 InfluxDB 和 Prometheus 两个数据源都接入业务压测指标和系统资源指标放到同一个看板里。这样压测一跑上面是接口响应时间、吞吐量下面就是集群的 CPU 和内存使用率瓶颈到底出在应用层还是基础设施层一眼就能看出来排查效率至少翻一倍。7. 写在最后的建议搭建这套平台本身并不复杂按这篇的步骤来快的半小时左右就能跑通。但平台搭起来只是开始真正的价值在于后续每一次压测你都会养成边压边看趋势的习惯。我个人实际操作中的体会是有实时监控和没有实时监控对压测结果的理解完全不一样。以前跑完压测我看着聚合报告上的数字总觉得差点意思现在整个压测过程变成了操控台视角系统什么状态、瓶颈在哪里、什么时候开始退化这些信息都是一目了然的。另外提醒一点这套方案搭好后别忘了在压测前把 Grafana 的时间范围选好把面板测试一下确认数据正常更新后再开始正式压测。不要等到压测跑到一半才发现仪表盘没配好操作起来手忙脚乱。这个平台后续还可以扩展的东西很多比如配合告警规则在指标异常时自动提醒或者把压测报告自动归档到其他存储。但那些都是锦上添花的事先把基础链路跑通、把实时监控这个习惯养成就足够让性能测试的质量上一个台阶了。
