统一观测丨如何使用Prometheus 实现性能压测指标可观测

作者：可观测团队

什么是性能压测可观测

如果说2022年最热的运维话题，非可观测莫属。可观测性从传统监控场景不断延伸，逐渐覆盖 Metrics、Traces、Logs 三个维度并将之相互融合，可观测性帮助企业在复杂的分布式系统中更加快速的排查、定位问题，是分布式系统中必不可少的运维工具。

在性能压测领域中，可观测性更为重要，除了有助于定位性能问题，其中 Metrics 性能指标更直接决定了压测是否通过，系统最终是否可以上线，具体如下：

• Metrics - 监控指标

• • 系统性能指标，包括请求成功率、系统吞吐量、响应时长

  • 资源性能指标，衡量系统软硬件资源使用情况，配合系统性能指标，观察系统资源水位

• Logs - 日志

• • 施压引擎日志，观察施压引擎是否健康，压测脚本执行是否有报错

  • 采样日志，采样记录API的请求和响应详情，辅助排查压测过程中的一些出错请求的参数是否正常，并通过响应详情，查看完整的错误信息

• Traces - 分布式链路追踪

用于性能问题诊断阶段，通过追踪请求在系统中的调用链路，定位报错 API 的报错系统和报错堆栈，快速定位性能问题点。

本篇阐述如何使用 Prometheus 实现性能压测 Metrics 的可观测性。

压测监控核心指标

压测过程中，对系统硬件、中间件、数据库资源的监控也很重要，包括系统性能指标、资源指标、中间件指标、数据库指标、前端指标、稳定性指标、批量处理指标、可扩展性指标、可靠性指标等。

系统性能指标

1. 交易响应时间

2. 1. 定义及解释响应时间指用户从客户端发起一个请求开始，到客户端接收到从服务器端返回的响应结束，整个过程所耗费的时间。在性能检测中一般以压力发起端至被压测服务器返回处理结果的时间为计量，单位一般为秒或毫秒。平均响应时间指系统稳定运行时间段内，同一交易的平均响应时间。一般而言，交易响应时间均指平均响应时间。平均响应时间指标值应根据不同的交易分别设定，一般情况下，分为复杂交易响应时间、简单交易响应时间、特殊交易响应时间。其中，特殊交易响应时间的设定必须明确该交易在响应时间方面的特殊性

   2. 简称 Response Time: RT

   3. 参考标准不同行业不同业务可接受的响应时间是不同的，一般情况，对于在线实时交易：对于批量交易：

• • 互联网企业：500 毫秒以下，例如淘宝业务 10 毫秒左右

  • 金融企业：1 秒以下为佳，部分复杂业务 3 秒以下

  • 保险企业：3 秒以下为佳

  • 制造业：5 秒以下为佳

  • 时间窗口：即整个压测过程的时间，不同数据量则时间不一样，例如双 11 和 99 大促，数据量级不一样则时间窗口不同。大数据量的情况下，2 小时内可完成压测

1. 系统处理能力

2. 1. 定义及解释系统处理能力是指系统在利用系统硬件平台和软件平台进行信息处理的能力。系统处理能力通过系统每秒钟能够处理的交易数量来评价，交易有两种理解：一是业务人员角度的一笔业务过程；二是系统角度的一次交易申请和响应过程。前者称为业务交易过程，后者称为事务。两种交易指标都可以评价应用系统的处理能力。一般的建议与系统交易日志保持一致，以便于统计业务量或者交易量。系统处理能力指标是技术测试活动中重要指标

   2. 简称一般情况下，用以下指标来度量：

• • HPS（Hits Per Second） ：每秒点击次数，单位是次/秒

  • TPS（Transaction per Second）：系统每秒处理交易数，单位是笔/秒。

  • QPS（Query per Second）：系统每秒处理查询次数，单位是次/秒。对于互联网业务中，如果某些业务有且仅有一个请求连接，那么 TPS=QPS=HPS，一般情况下用 TPS 来衡量整个业务流程，用 QPS 来衡量接口查询次数，用 HPS 来表示对服务器单击请求

1. 1. 标准无论 TPS、QPS、HPS，此指标是衡量系统处理能力非常重要的指标，越大越好，根据经验，一般情况下：

• • 金融行业：1000 TPS~50000 TPS，不包括互联网化的活动

  • 保险行业：100 TPS~100000 TPS，不包括互联网化的活动

  • 制造行业：10 TPS~5000 TPS

  • 互联网电子商务：10000 TPS~1000000 TPS

  • 互联网中型网站：1000 TPS~50000 TPS

  • 互联网小型网站：500 TPS~10000 TPS

1. 并发用户

2. 1. 定义及解释并发用户数指在同一时刻内，登录系统并进行业务操作的用户数量。并发用户数对于长连接系统来说最大并发用户数即是系统的并发接入能力。对于短连接系统而言最大并发用户数并不等于系统的并发接入能力，而是与系统架构、系统处理能力等各种情况相关。例如系统吞吐能力很强，加上短连接一般都有连接复用，往往并发用户数大于系统的并发接入连接数。所以对于大部分短连接类型的系统，吞吐量模式（RPS模式，Request Per Second）比较适合，也是阿里的最佳实践，PTS 支持 RPS 模式的压测，吞吐量的压测构建和衡量一步到位。在测试中，采用虚拟用户来模拟现实中用户进行业务操作

   2. 简称 Virtual User：VU

   3. 标准一般情况下，性能测试是将系统处理能力容量测出来，而不是测试并发用户数，除了服务器长连接可能影响并发用户数外，系统处理能力不受并发用户数影响，可以用最小的用户数将系统处理能力容量测试出来，也可以用更多的用户将系统处理能力容量测试出来

1. 错误率

2. 1. 定义及解释错误率指系统在负载情况下，失败交易的概率。错误率＝（失败交易数/交易总数）×100%。稳定性较好的系统，其错误率应该由超时引起，即为超时率。

   2. 简称 Virtual Failure Ratio：FR: VU

   3. 标准不同系统对错误率的要求不同，但一般不超出千分之六，即成功率不低于 99.4%

资源指标

1. CPU

2. 1. 定义及解释中央处理器是一块超大规模的集成电路，是一台计算机的运算核心（Core）和控制核心（ Control Unit）。它的功能主要是解释计算机指令以及处理计算机软件中的数据。CPU Load：系统正在干活的多少的度量，队列长度。系统平均负载

   2. 简称 Central Processing Unit：CPU

   3. 标准 CPU 指标主要指的 CPU 使用率、利用率，包括用户态（user）、系统态（sys）、等待态（wait）、空闲态（idle）。CPU使用率、利用率要低于业界警戒值范围之内，即小于或者等于 75%、CPU sys%小于或者等于 30%，CPU wait% 小于或者等于 5%。单核 CPU 也需遵循上述指标要求。CPU Load 要小于CPU核数

1. Memory

2. 1. 定义及解释内存是计算机中重要的部件之一，它是与 CPU 进行沟通的桥梁。计算机中所有程序的运行都是在内存中进行的，因此内存的性能对计算机的影响非常大

   2. 简称 Memory 就是内存的简称

   3. 标准现代的操作系统为了最大利用内存，在内存中存放了缓存，因此内存利用率 100% 并不代表内存有瓶颈，衡量系统内有瓶颈主要靠 SWAP（与虚拟内存交换）交换空间利用率，一般情况下，SWAP 交换空间利用率要低于 70%，太多的交换将会引起系统性能低下

1. 磁盘吞吐量

2. 1. 定义及解释磁盘吞吐量是指在无磁盘故障的情况下单位时间内通过磁盘的数据量

   2. 简称 Disk Throughput

   3. 标准磁盘指标主要有每秒读写多少兆，磁盘繁忙率，磁盘队列数，平均服务时间，平均等待时间，空间利用率。其中磁盘繁忙率是直接反映磁盘是否有瓶颈的重要依据，一般情况下，磁盘繁忙率要低于 70%

1. 网络吞吐量

2. 1. 定义及解释网络吞吐量是指在无网络故障的情况下单位时间内通过的网络的数据数量。单位为 Byte/s。网络吞吐量指标用于衡量系统对于网络设备或链路传输能力的需求。当网络吞吐量指标接近网络设备或链路最大传输能力时，则需要考虑升级网络设备

   2. 简称 Network Throughput

   3. 标准网络吞吐量指标主要有每秒有多少兆流量进出，一般情况下不能超过设备或链路最大传输能力的 70%

中间件指标

1. 定义及解释常用的中间件例如 Tomcat、Weblogic 等指标主要包括 JVM、ThreadPool、JDBC，具体如下：

1. 标准

• • 当前正在运行的线程数不能超过设定的最大值。一般情况下系统性能较好的情况下，线程数最小值设置 50 和最大值设置 200 比较合适

  • 当前运行的 JDBC 连接数不能超过设定的最大值。一般情况下系统性能较好的情况下，JDBC 最小值设置 50 和最大值设置 200 比较合适

  • GC 频率不能频繁，特别是 FULL GC 更不能频繁，一般情况下系统性能较好的情况下，JVM 最小堆大小和最大堆大小分别设置 1024 M 比较合适

数据库指标

1. 定义及解释常用的数据库例如 ＭySQL 指标主要包括 SQL、吞吐量、缓存命中率、连接数等，具体如下：

标准

• • SQL 耗时越小越好，一般情况下微秒级别

  • 命中率越高越好，一般情况下不能低于 95%

  • 锁等待次数越低越好，等待时间越短越好

▧前端指标

1. 定义及解释前端指标主要包括页面展示和网络所花的时间，具体如下：

1. 标准

• • 页面要尽可能小及压缩

  • 页面展示和花费时间越短越好

稳定性指标

1. 定义及解释最短稳定时间：系统按照最大容量的 80% 或标准压力（系统的预期日常压力）情况下运行，能够稳定运行的最短时间。一般来说，对于正常工作日（8小时）运行的系统，至少应该能保证系统稳定运行８小时以上。对于 7×24 运行的系统，至少应该能够保证系统稳定运行 24 小时以上。如果系统不能稳定的运行，上线后，随着业务量的增长和长时间运行，将会出现性能下降甚至崩溃的风险

2. 标准

• • TPS 曲线稳定，没有大幅度的波动

  • 各项资源指标没有泄露或异常情况

批量处理指标

1. 定义及解释指批量处理程序单位时间内处理的数据数量。一般用每秒处理的数据量来衡量。处理效率是估算批量处理时间窗口最重要的计算指标。关于批量处理时间窗口，不同系统的批量处理时间窗口在起止时间上可以部分重叠。另外，同一系统内部，也可能存在多个批量处理过程同时进行，其时间窗口相互叠加。长时间批量处理将会对联机在线实时交易产生重大的性能影响

2. 标准

• • 在数据量很大的情况下，批处理时间窗口时间越短越好

  • 不能影响实时交易系统性能

可扩展性指标

1. 定义及解释指应用软件或操作系统以集群方式部署，增加的硬件资源与增加的处理能力之间的关系。计算公式为：（增加性能/原始性能）/（增加资源/原始资源）×100%。扩展能力应通过多轮测试获得扩展指标的变化趋势。一般扩展能力非常好的应用系统，扩展指标应是线性或接近线性的，现在很多大规模的分布式系统的扩展能力非常好。

2. 标准

• • 理想的扩展能力是资源增加几倍，性能就提升几倍。

  • 扩展能力至少在70%以上。

可靠性指标

1. 双机热备对于将双机热备作为可靠性保障手段的系统，可衡量的指标如下：

• • 节点切换是否成功及其消耗时间。

  • 双机切换是否有业务中断。

  • 节点回切是否成功及其耗时

  • 双机回切是否有业务中断。

  • 节点回切过程中的数据丢失量。在进行双机切换的同时，使用压力发生工具模拟实际业务发生情况，对应用保持一定的性能压力，保证测试结果符合生产实际情况。

1. 集群对于使用集群方式的系统，主要通过以下方式考量其集群可靠性：

• • 集群中某个节点出现故障时，系统是否有业务中断情况出现。

  • 在集群中新增一个节点时，是否需要重启系统。

  • 当故障节点恢复后，加入集群，是否需要重启系统。

  • 当故障节点恢复后，加入集群，系统是否有业务中断情况出现。

  • 节点切换需要多长时间。在验证集群可靠性的同时，需根据具体情况使用压力工具模拟实际业务发生相关情况，对应用保持一定的性能压力，确保测试结果符合生产实际情况。

1. 备份和恢复本指标为了验证系统的备份、恢复机制是否有效可靠，包括系统的备份和恢复、数据库的备份和恢复、应用的备份和恢复，包括以下测试内容：

• • 备份是否成功及其消耗时间。

  • 备份是否使用脚本自动化完成。

  • 恢复是否成功及其消耗时间。

  • 恢复是否使用脚本自动化完成指标体系的运用原则。

  • 指标项的采用和考察取决于对相应系统的测试目的和测试需求。被测系统不一样，测试目的不一样，测试需求也不一样，考察的指标项也有很大差别。

  • 部分系统涉及额外的前端用户接入能力的，需要考察用户接入并发能力指标。

  • 对于批量处理过程的性能验证，主要考虑批量处理效率并估算批量处理时间窗口。

  • 如测试目标涉及到系统性能容量，测试需求中应根据相关指标项的定义，明确描述性能指标需求。

  • 测试指标获取后，需说明相关的前提条件（如在多少的业务量、系统资源情况等）。

施压机性能指标

压测链路中，施压机性能是容易被忽略的一环，为了保证施压机不是整个压测链路的性能瓶颈，需要关注如下施压机性能指标：

• 压测进程的内存使用量

• 施压机 CPU 使用率，Load1、Load5 负载指标

• 基于 JVM 的压测引擎，需要关注垃圾回收次数、垃圾回收时长

为什么用 Prometheus 做压测监控

开源压测工具如 JMeter，本身支持简单的系统性能监控指标，如请求成功率、系统吞吐量、响应时长等。但是对于大规模分布式压测来说，开源压测工具的原生监控有如下不足：

1. 监控指标不够全面，一般只包含了基础的系统性能指标，只能用于判断压测是否通过。但是如果压测不通过，需要排查、定位问题时，如分析一个 API 的99分位建联时长，原生监控指标就无法实现。

2. 聚合时效性不能保证；

3. 无法支持大规模分布式的监控数据聚合；

4. 监控指标不支持按时间轴回溯。

综上，在大规模分布式压测中，不推荐使用开源压测工具的原生监控。

下面对比2种开源的监控方案：

方案一：Zabbix

Zabbix 是早期开源的分布式监控系统，支持 MySQL 或 PostgreSQL 关系型数据库作为数据源。

对于系统性能监控，需要施压机提供秒级的监控指标，每秒高并发的监控指标写入，使关系型数据库成为了监控系统的瓶颈。

对于资源性能监控，Zabbix 对物理机、虚拟机的指标很全面，但是对容器、弹性计算的监控支持还不够。

方案二：Prometheus

Prometheus 使用时序数据库作为数据源，相比传统关系型数据库，读写性能大大提高，对于施压机大量的秒级监控数据上报的场景，性能表现良好。

对于资源性能监控，Prometheus 更适用于云资源的监控，尤其对 Kubernetes 和容器的监控非常全面，对使用云原生技术的用户，上手更简单。

总结下来，Prometheus 相较 Zabbix，更适合于压测中高并发监控指标的采集和聚合，并且更适用于云资源的监控，且易于扩展。PTS 提供压测时的系统性能指标， Prometheus 提供资源监控和整体可观测的能力，一站式解决压测可观测的问题。

怎么使用 Prometheus 实现压测监控

开源 JMeter 改造

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

JMeter 提供了插件机制，可以自定义插件来扩展 Prometheus 监控能力。在自定插件中，需要扩展 JMeter 的 BackendListener，让在采样器执行完成时，更新每个压测指标，如成功请求数、失败请求数、请求响应时长。并将各压测指标在内存中保存，在 Prometheus 拉数据时，通过 HTTP 服务暴露出去。整体结构如下：

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

1. 增加指标注册中心

2. 扩展 Prometheus 指标更新器

3. 实现自定义 JMeter BackendListener，在采样器执行结束后，调用 Prometheus 更新器

4. 实现 HTTP Server，如果有安全需要，补充鉴权逻辑

PTS 压测工具& Prometheus 监控

性能测试 PTS（Performance Testing Service）是一款阿里云 SaaS 化的性能测试工具。PTS 支持自研压测引擎，同时支持开源 JMeter 压测，在 PTS 上开放压测指标到 Prometheus，无需开发自定义插件来改造引擎，只需一步白屏化操作即可。

由于性能测试 PTS 已经与阿里云 Prometheus 监控进行了云产品自监控集成，因此咱们可以直接在阿里云 Prometheus 监控中进行集成开通。在已集成区域，单击云产品卡片，您可以在弹出的面板中查看该云产品的指标、大盘及告警的监控数据。

• 指标：您可以在指标页签查看性能测试 PTS 的监控指标信息，其中包括您所创建的 PTS 压测任务以及 PTS 施压机的自监控。

• 大盘：您可以在大盘页签查看当前云产品的预置大盘。

• 告警：您可以在告警页签创建 Prometheus 告警规则，查看监控告警信息。如何创建告警规则的具体操作，请参见 Prometheus 告警规则。

总结

本文阐述了：

1. 什么是性能测试可观测

2. 为什么用 Prometheus 做压测性能指标监控

3. 如何使用开源 JMeter 和云上 PTS 实现基于 Prometheus 的压测监控

PTS 压测监控导出 Prometheus 功能，欢迎使用。同时，PTS 全新售卖方式来袭，基础版价格直降50%！百万并发价格只需 6200！更有新用户 0.99 体验版、VPC 压测专属版，欢迎大家选购！

点击此处进入可观测大促专场