云原生时代如何用 Prometheus 实现性能压测可观测-Metrics 篇-六虎

作者：拂衣

什么是功用压测可观测

可观测性包括 Metrics、Traces、Logs3 个维度。可观测才能帮助我们在复杂的散布式体系中快速排查、定位问题，是散布式体系中必不可少的运维东西。

在功用压测领域中，可观测才能更为重要，除了有助于定位功用问题，其中Metrics功用目标更直接决议了压测是否经过，对体系上线有决议性左右，具体如下：

• Metrics，监控目标

体系功用目标，包括恳求成功率、体系吞吐量、呼应时长

资源功用目标，衡量体系软硬件资源运用情况，合作体系功用目标，调查体系资源水位

• Logs，日志

施压引擎日志，调查施压引擎是否健康，压测脚本履行是否有报错

采样日志，采样记载 API 的恳求和呼应详情，辅佐排查压测过程中的一些出错恳求的参数是否正常，并经过呼应详情，查看完好的过错信息

• Traces，散布式链路追踪用于功用问题诊断阶段，经过追踪恳求在体系中的调用链路，

定位报错 API 的报错体系和报错堆栈，快速定位功用问题点

本篇论述怎样运用 Prometheus 完成功用压测 Metrics 的可观测性。

压测监控的中心目标

体系功用目标

压测监控最重要的 3 个目标：恳求成功率、服务吞吐量(TPS)、恳求呼应时长(RT)，这 3 个目标任意一个呈现拐点，都能够以为体系已达到功用瓶颈。

这儿特别阐明下呼应时长，关于这个目标，用均匀值来判别很有误导性，因为一个体系的呼应时长并不是均匀散布的，往往会呈现长尾现象，体现为一部分用户恳求的呼应时刻特别长，但全体均匀呼应时刻契合预期，这样其实是影响了一部分用户的体验，不应该判别为测试经过。因而关于呼应时长，常用 99、95、90 分位值来判别体系呼应时长是否达标。

别的，假如需求调查恳求呼应时长的散布细节，能够弥补恳求建联时长(Connect Time)、等待呼应时长(Idle Time)等目标。

资源功用目标

压测过程中，对体系硬件、中间件、数据库资源的监控也很重要，包括但不限于：

• CPU 运用率 • 内存运用率 • 磁盘吞吐量 • 网络吞吐量 • 数据库连接数 • 缓存命中率 … …

具体可见《测试目标》[1]一文。

施压机功用目标

压测链路中，施压机功用是简略被忽略的一环，为了确保施压机不是整个压测链路的功用瓶颈，需求重视如下施压机功用目标：

• 压测进程的内存运用量 • 施压机 CPU 运用率，Load1、Load5 负载目标 • 根据 JVM 的压测引擎，需求重视废物回收次数、废物回收时长

为什么用 Prometheus 做压测监控

开源压测东西如 JMeter 本身支撑简略的体系功用监控目标，如：恳求成功率、体系吞吐量、呼应时长等。可是关于大规模散布式压测来说，开源压测东西的原生监控有如下缺乏：

监控目标不够全面，一般只包含了基础的体系功用目标，只能用于判别压测是否经过。可是假如压测不经过，需求排查、定位问题时，如分析一个 API 的 99 分位建联时长，原生监控目标就无法完成。
聚合时效性不能确保
无法支撑大规模散布式的监控数据聚合
监控目标不支撑按时刻轴回溯

综上，在大规模散布式压测中，不推荐运用开源压测东西的原生监控。

下面比照 2 种开源的监控计划：

计划一：Zabbix

Zabbix 是前期开源的散布式监控体系，支撑 MySQL 或 PostgreSQL 联系型数据库作为数据源。

关于体系功用监控，需求施压机供给秒级的监控目标，每秒高并发的监控目标写入，使联系型数据库成为了监控体系的瓶颈。

关于资源功用监控，Zabbix 对物理机、虚拟机的目标很全面，可是对容器、弹性计算的监控支撑还不够。

计划二：Prometheus

Prometheus 运用时序数据库作为数据源，相比传统联系型数据库，读写功用大大提高，关于施压机大量的秒级监控数据上报的场景，功用体现杰出。

关于资源功用监控，Prometheus 更适用于云资源的监控，尤其对 Kubernates 和容器的监控十分全面，对运用云原生技能的用户，上手更简略。

总结下来，Prometheus 相较 Zabbix，更适合于压测中高并发监控目标的收集和聚合，并且更适用于云资源的监控，且易于扩展。

当然，运用成熟的云产品也是一个很好挑选，如压测东西 PTS[2]+可观测东西 ARMS[3]，便是一组黄金搭档。PTS 供给压测时的体系功用目标，ARMS 供给资源监控和全体可观测的才能，一站式解决压测可观测的问题。

怎样运用 Prometheus 完成压测监控

开源 JMeter 改造

Prometheus 是拉数据模型，因而需求压测引擎暴露 HTTP 服务，供 Prometheus 获取各压测目标。

JMeter 供给了插件机制，能够自定义插件来扩展 Prometheus 监控才能。在自定插件中，需求扩展 JMeter 的 BackendListener，让在采样器履行完成时，更新每个压测目标，如成功恳求数、失利恳求数、恳求呼应时长。并将各压测目标在内存中保存，在 Prometheus 拉数据时，经过 HTTP 服务暴露出去。全体结构如下：

JMeter 自定义插件需求改造的点：

添加目标注册中心
扩展 Prometheus 目标更新器
完成自定义 JMeter BackendListener，在采样器履行完毕后，调用 Prometheus 更新器
完成 HTTP Server，假如有安全需求，弥补鉴权逻辑

PTS 压测东西

功用测试 PTS（Performance Testing Service）是一款阿里云 SaaS 化的功用测试东西。PTS支撑自研压测引擎，一起支撑开源 JMeter 压测，在 PTS 上开放压测目标到 Prometheus，无需开发自定义插件来改造引擎，只需 3 步白屏化操作即可。具体过程如下：

PTS 压测的高档设置中，翻开【Prometheus】开关
压测开端后，在【监控导出】一键复制 Prometheus 装备
自建的 Prometheus 中张贴并热加载此装备，即可生效

具体参考：《怎样将 PTS 压测的目标数据输出到 Prometheus》[4]

快速搭建 Grafana 监控大盘

PTS 供给了官方 Grafana 大盘模板[5]，支撑一键导入监控大盘，并能够灵活修改和扩展，满足您的定制监控需求。

本大盘供给了大局恳求成功率，体系吞吐量(TPS)，99、95、90 分位呼应时长，以及按过错状态码聚合的过错恳求数等数据。

在 API 散布专栏中，能够直观的比照各 API 的监控目标，快速定位功用短板 API。

在 API 详情专栏中，能够查看单个 API 的具体目标，准确定位功用瓶颈。

别的，大盘还供给了施压机的JVM废物回收监控目标，能够辅佐判别施压机是否是压测链路中的功用瓶颈。

导入过程如下：

过程一

在菜单栏，点击 Dashboard 下的 import：

过程二

填写 PTS Dashboard 的 id：15981

在 Prometheus 挑选您已有的数据源，本示例中数据源名为 Prometheus。选中后，单击 Import 导入

过程三

导入后，在左上角【PTS 压测使命】，挑选需求监控的压测使命，即可看到当前监控大盘。

此使命名对应 PTS 控制台在监控导出-Prometheus 装备中的 jobname。

总结

本文论述了

什么是功用测试可观测
为什么用 Prometheus 做压测功用目标监控
怎样运用开源 JMeter 和云上 PTS 完成根据 Prometheus 的压测监控

PTS 压测监控导出 Prometheus 功用，现在免费公测中，欢迎运用。

一起，PTS 全新售卖方法来袭，基础版价格直降 50%！百万并发价格只需 6200！更有新用户 0.99 体验版、VPC 压测专属版，欢迎我们选购！

云原生时代如何用 Prometheus 实现性能压测可观测-Metrics 篇