openEuler ARM64 上 JMeter+Prometheus+InfluxDB 监控链路搭建指南

简介本资源面向需要在 openEuler 22.03 SP2 aarch64 平台上搭建性能监控与压测体系的运维及测试人员整合了 JMeter、Prometheus 与 InfluxDB 三件套的安装包可解决压测数据采集、时序存储与可视化监控链路搭建的问题适合具备一定 Linux 基础、希望快速落地监控方案的中高级用户。压缩包共 7 个文件以 4 个 json 配置文件和 3 个 gz 压缩包为主json 文件可用于监控面板或采集配置导入gz 包则对应各组件在 arm64 架构下的可执行程序整体约 125.1MB。目前已有 95 人学习下载。借助该资源读者可省去逐一下载与架构适配的麻烦直接获得与 oe2203sp2.aarch64 匹配的组件版本快速完成 JMeter 压测结果写入 InfluxDB、再由 Prometheus 抓取与展示的完整链路验证同时可参考包内配置文件理解监控指标的采集与展示方式降低环境搭建与版本兼容的试错成本。1. 一套能直接跑在 oe2203sp2.aarch64 上的监控组合包手上有一台 openEuler 22.03 SP2 的 ARM64 服务器想给 JMeter 压测做一套完整的指标采集链路结果发现网上绝大多数教程都是 x86_64 Ubuntu 的路径照着走不是二进制架构不匹配就是 systemd 单元文件路径对不上。这套「jmeterPrometheusinfluxdb 软件包 oe2203sp2.aarch64」解决的正是这个场景把 JMeter、Prometheus、InfluxDB 三个组件的 aarch64 版本打包在一起省掉逐个找 ARM 架构安装包的麻烦。它适合需要在国产化 ARM 服务器上搭建压测监控链路的测试和运维人员也适合刚接触 JMeter 压测、想一次性把数据落库和可视化打通的新手。下面按「组件怎么装 → 链路怎么通 → 坑在哪」的顺序拆开讲。2. 三个组件在 ARM64 上的角色分工与选型理由2.1 为什么是 JMeter Prometheus InfluxDB 这个组合JMeter 负责产生压测流量并输出采样数据InfluxDB 负责时序数据的持久化存储Prometheus 负责指标抓取和告警规则。三者组合的核心逻辑是JMeter 通过 Backend Listener 把每次请求的响应时间、吞吐量、错误率实时写入 InfluxDBPrometheus 再从 InfluxDB 或 JMeter 暴露的端点拉取指标最终在 Grafana 上做可视化。这套链路比 JMeter 自带的聚合报告强在「实时性」——压测过程中就能看到曲线变化而不是等压测结束才出报告。选 InfluxDB 而不是直接用 Prometheus 存 JMeter 数据是因为 JMeter 的 Backend Listener 原生支持 InfluxDB 的 line protocol 写入格式配置成本最低。Prometheus 的 pull 模型更适合抓取周期性指标而 JMeter 的采样数据是高频事件流push 到 InfluxDB 更自然。常见做法是 InfluxDB 存原始采样数据Prometheus 抓 InfluxDB 的聚合结果或 JMeter 的 Prometheus 插件暴露的指标。2.2 aarch64 架构下的安装包选择oe2203sp2 是 openEuler 22.03 SP2 的简称底层是 aarch64 架构。这个架构下最容易翻车的地方是很多教程给的 InfluxDB 下载链接默认指向 amd64装完启动直接报cannot execute binary file: Exec format error。所以拿到软件包后第一件事是确认每个二进制的架构。# 确认系统架构输出应为 aarch64 uname -m # 确认系统版本 cat /etc/openEuler-release # 检查已下载的二进制文件架构 file /path/to/influxd file /path/to/prometheus file /path/to/jmeter/bin/jmeteruname -m返回aarch64说明系统是 ARM64file命令对每个二进制输出ELF 64-bit LSB executable, ARM aarch64才说明架构匹配。如果某个文件显示x86-64那它在这个系统上跑不起来需要换包。JMeter 本身是 Java 应用理论上跨平台但它依赖的 JDK 必须是 aarch64 版本。oe2203sp2 自带的 OpenJDK 通常可以用但版本可能偏低。JMeter 5.x 要求 JDK 8 以上推荐 JDK 11 或 17。检查方式java -version # 输出中应包含 OpenJDK 64-Bit Server VM 且架构为 aarch64如果系统没有 JDK 或版本不对用dnf install java-11-openjdk-devel安装。注意不要从 x86 机器上拷贝 JDK 目录过来架构不对照样报错。2.3 目录规划与端口分配三个组件默认端口容易冲突建议提前规划。InfluxDB 默认 8086Prometheus 默认 9090JMeter 本身不占固定端口但 Backend Listener 需要能访问 InfluxDB 的 8086。如果服务器上已经有其他服务占了这些端口启动时会报bind: address already in use。# 检查端口占用情况 ss -tlnp | grep -E 8086|9090 # 建议的目录结构 /opt/monitoring/ ├── influxdb/ │ ├── influxd │ └── influxdb.conf ├── prometheus/ │ ├── prometheus │ └── prometheus.yml └── jmeter/ └── apache-jmeter/把三个组件放在同一个父目录下方便统一管理启动脚本和日志。InfluxDB 的数据目录建议单独挂载或指定到大盘压测数据量大的时候默认路径容易把根分区写满。3. 从零把链路跑通安装、配置、验证3.1 InfluxDB 的安装与初始化InfluxDB 1.x 和 2.x 的配置差异很大JMeter 的 Backend Listener 对两者支持方式不同。1.x 用 database retention policy 的概念2.x 用 bucket token。这里以 1.8 版本为例因为它的配置对 JMeter 最友好。# 进入 influxdb 目录 cd /opt/monitoring/influxdb # 赋予执行权限 chmod x influxd # 启动 InfluxDB前台运行方便看日志 ./influxd -config influxdb.conf首次启动会自动创建元数据。启动成功后另开终端验证# 查看 InfluxDB 版本 curl -s http://localhost:8086/ping -I # 返回 204 说明服务正常 # 创建 JMeter 专用数据库 curl -XPOST http://localhost:8086/query --data-urlencode qCREATE DATABASE jmeter/ping返回 204 是 InfluxDB 的健康检查端点比看进程更可靠。创建数据库用 HTTP API 而不是命令行客户端是因为软件包里不一定带了influx客户端。数据库名jmeter要和后面 JMeter Backend Listener 配置里的保持一致。3.2 Prometheus 的配置与启动Prometheus 需要一份prometheus.yml核心是配置抓取目标。如果只是抓 JMeter 通过插件暴露的指标配置一个 static_configs 即可。# prometheus.yml global: scrape_interval: 15s evaluation_interval: 15s scrape_configs: - job_name: jmeter static_configs: - targets: [localhost:9270] metrics_path: /metricsscrape_interval设为 15 秒是压测场景的常用值太短会增加 Prometheus 负担太长会丢失瞬时峰值。targets里的 9270 是 JMeter Prometheus 插件的默认端口如果没用插件而是从 InfluxDB 转这里要改成对应的 exporter 地址。cd /opt/monitoring/prometheus chmod x prometheus ./prometheus --config.fileprometheus.yml --storage.tsdb.path./data--storage.tsdb.path指定数据目录默认是当前目录下的 data。启动后访问http://localhost:9090能看到 Prometheus 的 Web UI在 Status → Targets 里确认 jmeter 这个 job 的状态是 UP。3.3 JMeter 的 Backend Listener 配置JMeter 侧的关键是添加 Backend Listener 并选择 InfluxDB 的实现类。在测试计划上右键 → 添加 → 监听器 → Backend Listener然后配置以下参数参数值说明Backend Listener implementationorg.apache.jmeter.visualizers.backend.influxdb.InfluxdbBackendListenerClientInfluxDB 写入实现influxdbUrlhttp://localhost:8086/write?dbjmeter写入地址db 对应数据库名applicationmy_test应用标识用于区分不同测试measurementjmeter存储的 measurement 名summaryOnlyfalsefalse 表示记录每次采样samplersList.*正则匹配要记录的采样器配置完成后运行一个简单的 HTTP 请求测试然后在 InfluxDB 里查数据# 查询 jmeter 数据库中的 measurement curl -G http://localhost:8086/query?dbjmeter \ --data-urlencode qSHOW MEASUREMENTS如果返回结果里有jmeter说明数据已经写入。没有的话检查 JMeter 日志里的InfluxdbBackendListenerClient相关报错常见的是连接被拒绝或数据库不存在。3.4 用 Grafana 做可视化验证数据通了之后用 Grafana 连 InfluxDB 建面板是最直观的验证方式。添加数据源时选 InfluxDBURL 填http://localhost:8086Database 填jmeter。然后新建 Dashboard查询语句示例SELECT mean(avg) FROM jmeter WHERE $timeFilter GROUP BY time($__interval), transaction这条查询按事务分组统计平均响应时间。$timeFilter和$__interval是 Grafana 的内置变量分别代表时间范围和自动计算的时间间隔。如果面板出不来曲线先确认 InfluxDB 数据源测试连接是否通过再检查 measurement 和字段名是否拼写正确。4. 避坑与排查aarch64 环境下最容易翻车的五个点4.1 二进制架构不匹配导致无法启动现象执行./influxd或./prometheus时报cannot execute binary file: Exec format error。原因下载的二进制是 x86_64 架构而系统是 aarch64。很多下载站默认给 amd64 包不仔细看就中招。解决用file命令确认每个二进制的架构输出必须包含ARM aarch64。如果不对重新找 aarch64 版本的包。JMeter 本身是 jar 包跨平台但依赖的 JDK 必须是 aarch64 版本java -version输出里会标明。4.2 InfluxDB 启动后端口被占用现象InfluxDB 启动日志报bind: address already in use或者启动成功但curl localhost:8086/ping无响应。原因8086 端口被其他进程占用或者 InfluxDB 绑定到了非 localhost 的地址而防火墙没放行。解决ss -tlnp | grep 8086找到占用进程要么停掉冲突服务要么改 InfluxDB 配置里的bind-address。改端口的话 JMeter 的 influxdbUrl 也要同步改。4.3 JMeter 写入 InfluxDB 报 400 错误现象JMeter 日志里出现InfluxdbBackendListenerClient: Error writing to InfluxDBHTTP 状态码 400。原因通常是数据库不存在或者 measurement 名包含特殊字符或者时间戳格式不对。InfluxDB 1.x 对写入格式比较严格。解决先用SHOW DATABASES确认jmeter库存在。然后检查 Backend Listener 里的measurement参数不要用中文或空格。时间戳问题一般出现在 JMeter 版本和 InfluxDB 版本不匹配时换用软件包里配套的版本通常能解决。4.4 Prometheus 抓不到 JMeter 指标现象Prometheus 的 Targets 页面里 jmeter job 显示 DOWN错误信息是connection refused。原因JMeter 没有暴露 metrics 端点或者端口不是配置里的 9270。JMeter 原生不带 Prometheus 端点需要装 jmeter-prometheus-plugin 插件或者通过 InfluxDB exporter 中转。解决确认 JMeter 的lib/ext目录下有 prometheus 插件 jar 包。如果没有要么补上插件要么把 Prometheus 的抓取目标改成 InfluxDB 的 exporter 地址。软件包里如果没带这个插件需要单独获取。4.5 压测数据量过大导致磁盘写满现象压测跑了一段时间后 InfluxDB 写入变慢甚至报错df -h看到根分区使用率 100%。原因JMeter 每次采样都写一条记录高并发下每秒可能产生数万条数据InfluxDB 默认数据目录在根分区很快写满。解决启动 InfluxDB 时用-data-dir指定到大容量分区或者在配置文件的[data]段里改dir路径。另外可以设置 retention policy 自动清理旧数据CREATE RETENTION POLICY one_week ON jmeter DURATION 7d REPLICATION 1 DEFAULT这条语句创建一个 7 天保留策略并设为默认超过 7 天的数据自动删除。5. 进阶技巧用 Beanshell 断言把业务指标也写进监控基础链路跑通后只能看到 HTTP 层面的响应时间和状态码。实际压测中往往需要监控业务层面的指标比如返回 JSON 里某个字段的值、业务错误码的分布。这时候可以用 JMeter 的 Beanshell 断言在断言里把自定义指标写入 InfluxDB。// Beanshell 断言脚本示例 import org.apache.jmeter.util.JMeterUtils; import java.net.HttpURLConnection; import java.net.URL; import java.io.OutputStream; // 获取响应内容 String response prev.getResponseDataAsString(); // 解析业务字段假设返回 JSON 里有 code 字段 int bizCode 0; try { // 简单字符串查找生产环境建议用 JSON 库 int idx response.indexOf(\code\:); if (idx 0) { String sub response.substring(idx 7, idx 10).replaceAll([^0-9], ); bizCode Integer.parseInt(sub); } } catch (Exception e) { bizCode -1; } // 写入 InfluxDB String influxUrl http://localhost:8086/write?dbjmeter; String line biz_metric,applicationmy_test code bizCode System.currentTimeMillis() 000000; try { URL url new URL(influxUrl); HttpURLConnection conn (HttpURLConnection) url.openConnection(); conn.setRequestMethod(POST); conn.setDoOutput(true); OutputStream os conn.getOutputStream(); os.write(line.getBytes()); os.flush(); os.close(); conn.getResponseCode(); } catch (Exception e) { log.error(写入业务指标失败: e.getMessage()); }这段脚本的逻辑是从响应体里提取业务码拼成 InfluxDB 的 line protocol 格式通过 HTTP POST 写入。biz_metric是自定义的 measurement 名application是 tagcode是 field。时间戳用System.currentTimeMillis()乘以 1000000 转成纳秒因为 InfluxDB 默认精度是纳秒。几个关键参数说明prev.getResponseDataAsString()拿到的是当前采样器的响应体如果响应很大要注意内存indexOf做字符串查找是图省事正式用建议引入 JSON 解析库写入失败只记日志不抛异常避免因为监控写入问题导致压测本身失败。用这个方式可以把业务错误率、关键字段的分布都纳入监控面板。我一般会在压测前先跑一轮小流量确认 Beanshell 断言里的字段解析逻辑没问题再放大并发。从那以后每次配 JMeter 监控我都会先用一条请求验证 InfluxDB 里能查到数据再挂全量压测省得跑了几十万请求才发现数据根本没写进去。希望帮到你。本文还有配套的精品资源点击获取