关于阿里云:统一观测丨如何使用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 小时内可实现压测

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

• • HPS（Hits Per Second）：每秒点击次数，单位是次 / 秒
  • TPS（Transaction per Second）：零碎每秒解决交易数，单位是笔 / 秒。
  • QPS（Query per Second）：零碎每秒解决查问次数，单位是次 / 秒。对于互联网业务中，如果某些业务有且仅有一个申请连贯，那么 TPS=QPS=HPS，个别状况下用 TPS 来掂量整个业务流程，用 QPS 来掂量接口查问次数，用 HPS 来示意对服务器单击申请

1. 3. 规范无论 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

3. 并发用户
4. 1. 定义及解释并发用户数指在同一时刻内，登录零碎并进行业务操作的用户数量。并发用户数对于长连贯零碎来说最大并发用户数即是零碎的并发接入能力。对于短连贯零碎而言最大并发用户数并不等于零碎的并发接入能力，而是与零碎架构、零碎解决能力等各种状况相干。例如零碎吞吐能力很强，加上短连贯个别都有连贯复用，往往并发用户数大于零碎的并发接入连接数。所以对于大部分短连贯类型的零碎，吞吐量模式（RPS 模式，Request Per Second）比拟适宜，也是阿里的最佳实际，PTS 反对 RPS 模式的压测，吞吐量的压测构建和掂量一步到位。在测试中，采纳虚构用户来模仿事实中用户进行业务操作
   2. 简称 Virtual User：VU
   3. 规范个别状况下，性能测试是将零碎解决能力容量测进去，而不是测试并发用户数，除了服务器长连贯可能影响并发用户数外，零碎解决能力不受并发用户数影响，能够用最小的用户数将零碎解决能力容量测试进去，也能够用更多的用户将零碎解决能力容量测试进去
5. 错误率
6. 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 核数
3. Memory
4. 1. 定义及解释内存是计算机中重要的部件之一，它是与 CPU 进行沟通的桥梁。计算机中所有程序的运行都是在内存中进行的，因而内存的性能对计算机的影响十分大
   2. 简称 Memory 就是内存的简称
   3. 规范古代的操作系统为了最大利用内存，在内存中寄存了缓存，因而内存利用率 100% 并不代表内存有瓶颈，掂量零碎内有瓶颈次要靠 SWAP（与虚拟内存替换）替换空间利用率，个别状况下，SWAP 替换空间利用率要低于 70%，太多的替换将会引起零碎性能低下
5. 磁盘吞吐量
6. 1. 定义及解释磁盘吞吐量是指在无磁盘故障的状况下单位工夫内通过磁盘的数据量
   2. 简称 Disk Throughput
   3. 规范磁盘指标次要有每秒读写多少兆，磁盘忙碌率，磁盘队列数，均匀服务工夫，均匀等待时间，空间利用率。其中磁盘忙碌率是间接反映磁盘是否有瓶颈的重要依据，个别状况下，磁盘忙碌率要低于 70%
7. 网络吞吐量
8. 1. 定义及解释网络吞吐量是指在无网络故障的状况下单位工夫内通过的网络的数据数量。单位为 Byte/s。网络吞吐量指标用于掂量零碎对于网络设备或链路传输能力的需要。当网络吞吐量指标靠近网络设备或链路最大传输能力时，则须要思考降级网络设备
   2. 简称 Network Throughput
   3. 规范网络吞吐量指标次要有每秒有多少兆流量进出，个别状况下不能超过设施或链路最大传输能力的 70%

中间件指标

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

2. 规范

• • 以后正在运行的线程数不能超过设定的最大值。个别状况下零碎性能较好的状况下，线程数最小值设置 50 和最大值设置 200 比拟适合
  • 以后运行的 JDBC 连接数不能超过设定的最大值。个别状况下零碎性能较好的状况下，JDBC 最小值设置 50 和最大值设置 200 比拟适合
  • GC 频率不能频繁，特地是 FULL GC 更不能频繁，个别状况下零碎性能较好的状况下，JVM 最小堆大小和最大堆大小别离设置 1024 M 比拟适合

数据库指标

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

规范

• • SQL 耗时越小越好，个别状况下微秒级别
  • 命中率越高越好，个别状况下不能低于 95%
  • 锁期待次数越低越好，等待时间越短越好

前端指标

1. 定义及解释前端指标次要包含页面展现和网络所花的工夫，具体如下：

2. 规范

• • 页面要尽可能小及压缩
  • 页面展现和破费工夫越短越好

稳定性指标

1. 定义及解释最短稳固工夫：零碎依照最大容量的 80% 或规范压力（零碎的预期日常压力）状况下运行，可能稳固运行的最短时间。一般来说，对于失常工作日（8 小时）运行的零碎，至多应该能保证系统稳固运行8小时以上。对于 7×24 运行的零碎，至多应该可能保证系统稳固运行 24 小时以上。如果零碎不能稳固的运行，上线后，随着业务量的增长和长时间运行，将会呈现性能降落甚至解体的危险
2. 规范

• • TPS 曲线稳固，没有大幅度的稳定
  • 各项资源指标没有泄露或异常情况

批量解决指标

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

• • 在数据量很大的状况下，批处理工夫窗口工夫越短越好
  • 不能影响实时交易系统性能

可扩展性指标

1. 定义及解释指应用软件或操作系统以集群形式部署，减少的硬件资源与减少的解决能力之间的关系。计算公式为：（减少性能 / 原始性能）/（减少资源 / 原始资源）×100%。扩大能力应通过多轮测试取得扩大指标的变化趋势。个别扩大能力十分好的利用零碎，扩大指标应是线性或靠近线性的，当初很多大规模的分布式系统的扩大能力十分好。
2. 规范

• • 现实的扩大能力是资源减少几倍，性能就晋升几倍。
  • 扩大能力至多在 70% 以上。

可靠性指标

1. 双机热备对于将双机热备作为可靠性保障伎俩的零碎，可掂量的指标如下：

• • 节点切换是否胜利及其耗费工夫。
  • 双机切换是否有业务中断。
  • 节点回切是否胜利及其耗时
  • 双机回切是否有业务中断。
  • 节点回切过程中的数据失落量。在进行双机切换的同时，应用压力产生工具模仿理论业务产生状况，对利用放弃肯定的性能压力，保障测试后果合乎生产理论状况。

2. 集群对于应用集群形式的零碎，次要通过以下形式考量其集群可靠性：

• • 集群中某个节点呈现故障时，零碎是否有业务中断状况呈现。
  • 在集群中新增一个节点时，是否须要重启零碎。
  • 当故障节点复原后，退出集群，是否须要重启零碎。
  • 当故障节点复原后，退出集群，零碎是否有业务中断状况呈现。
  • 节点切换须要多长时间。在验证集群可靠性的同时，需依据具体情况应用压力工具模仿理论业务产生相干状况，对利用放弃肯定的性能压力，确保测试后果合乎生产理论状况。

3. 备份和复原本指标为了验证零碎的备份、复原机制是否无效牢靠，包含零碎的备份和复原、数据库的备份和复原、利用的备份和复原，包含以下测试内容：

• • 备份是否胜利及其耗费工夫。
  • 备份是否应用脚本自动化实现。
  • 复原是否胜利及其耗费工夫。
  • 复原是否应用脚本自动化实现指标体系的使用准则。
  • 指标项的采纳和考查取决于对相应零碎的测试目标和测试需要。被测系统不一样，测试目标不一样，测试需要也不一样，考查的指标项也有很大差异。
  • 局部零碎波及额定的前端用户接入能力的，须要考查用户接入并发能力指标。
  • 对于批量处理过程的性能验证，次要思考批量解决效率并估算批量解决工夫窗口。
  • 如测试指标波及到零碎性能容量，测试需要中应依据相干指标项的定义，明确形容性能指标需要。
  • 测试指标获取后，需阐明相干的前提条件（如在多少的业务量、系统资源状况等）。

施压机性能指标

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

• 压测过程的内存使用量
• 施压机 CPU 使用率，Load1、Load5 负载指标
• 基于 JVM 的压测引擎，须要关注垃圾回收次数、垃圾回收时长

为什么用 Prometheus 做压测监控

开源压测工具如 JMeter，自身反对简略的零碎性能监控指标，如申请成功率、零碎吞吐量、响应时长等。然而对于大规模分布式压测来说，开源压测工具的原生监控有如下有余：

1. 监控指标不够全面，个别只蕴含了根底的零碎性能指标，只能用于判断压测是否通过。然而如果压测不通过，须要排查、定位问题时，如剖析一个 API 的 99 分位建联时长，原生监控指标就无奈实现。
2. 聚合时效性不能保障；
3. 无奈反对大规模分布式的监控数据聚合；
4. 监控指标不反对按时间轴回溯。

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

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

计划一：Zabbix

Zabbix 是晚期开源的分布式监控零碎，反对 MySQL 或 PostgreSQL 关系型数据库作为数据源。

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

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

计划二：Prometheus

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

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

总结下来，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 压测专属版，欢送大家选购！

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