作者：可观测团队

什么是功用压测可观测

假如说2022年最热的运维话题，非可观测莫属。可观测性从传统监控场景不断延伸，逐步掩盖 Metrics、Traces、Logs 三个维度并将之彼此融合，可观测性协助企业在杂乱的分布式体系中更加快速的排查、定位问题，是分布式体系中必不可少的运维东西。

在功用压测领域中，可观测性更为重要，除了有助于定位功用问题，其间 Metrics 功用目标更直接决定了压测是否经过，体系终究是否能够上线，详细如下：

  • Metrics – 监控目标

    • 体系功用目标，包含恳求成功率、体系吞吐量、呼应时长
    • 资源功用目标，衡量体系软硬件资源运用状况，合作体系功用目标，调查体系资源水位

  • Logs – 日志

    • 施压引擎日志，调查施压引擎是否健康，压测脚本履行是否有报错
    • 采样日志，采样记载API的恳求和呼应概况，辅佐排查压测进程中的一些犯错恳求的参数是否正常，并经过呼应概况，检查完整的错误信息

  • Traces – 分布式链路追寻

用于功用问题确诊阶段，经过追寻恳求在体系中的调用链路，定位报错 API 的报错体系和报错仓库，快速定位功用问题点。

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

压测监控中心目标

压测进程中，对体系硬件、中间件、数据库资源的监控也很重要，包含体系功用目标、资源目标、中间件目标、数据库目标、前端目标、安稳性目标、批量处理目标、可扩展性目标、牢靠性目标等。

体系功用目标

  1. 买卖呼应时刻

    1. 界说及解说呼应时刻指用户从客户端主张一个恳求开始，到客户端接收到从服务器端回来的呼应结束，整个进程所耗费的时刻。在功用检测中一般以压力主张端至被压测服务器回来处理成果的时刻为计量，单位一般为秒或毫秒。均匀呼应时刻指体系安稳运转时刻段内，同一买卖的均匀呼应时刻。一般来说，买卖呼应时刻均指均匀呼应时刻。均匀呼应时刻目标值应根据不同的买卖分别设定，一般状况下，分为杂乱买卖呼应时刻、简略买卖呼应时刻、特殊买卖呼应时刻。其间，特殊买卖呼应时刻的设定必须清晰该买卖在呼应时刻方面的特殊性
    2. 简称 Response Time: RT
    3. 参考规范不同行业不同事务可接受的呼应时刻是不同的，一般状况，关于在线实时买卖：关于批量买卖：
    • 互联网企业：500 毫秒以下，例如淘宝事务 10 毫秒左右
    • 金融企业：1 秒以下为佳，部分杂乱事务 3 秒以下
    • 稳妥企业：3 秒以下为佳
    • 制造业：5 秒以下为佳
    • 时刻窗口：即整个压测进程的时刻，不同数据量则时刻不一样，例如双 11 和 99 大促，数据量级不一样则时刻窗口不同。大数据量的状况下，2 小时内可完结压测

  1. 体系处理才能

    1. 界说及解说体系处理才能是指体系在利用体系硬件平台和软件平台进行信息处理的才能。体系处理才能经过体系每秒钟能够处理的买卖数量来点评，买卖有两种了解：一是事务人员角度的一笔事务进程；二是体系角度的一次买卖申请和呼应进程。前者称为事务买卖进程，后者称为事务。两种买卖目标都能够点评运用体系的处理才能。一般的主张与体系买卖日志坚持一致，以便于统计事务量或许买卖量。体系处理才能目标是技能测验活动中重要目标
    2. 简称一般状况下，用以下目标来衡量：
    • HPS（Hits Per Second） ：每秒点击次数，单位是次/秒
    • TPS（Transaction per Second）：体系每秒处理买卖数，单位是笔/秒。
    • QPS（Query per Second）：体系每秒处理查询次数，单位是次/秒。关于互联网事务中，假如某些事务有且仅有一个恳求衔接，那么 TPS=QPS=HPS，一般状况下用 TPS 来衡量整个事务流程，用 QPS 来衡量接口查询次数，用 HPS 来表示对服务器单击恳求
    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. 并发用户

    1. 界说及解说并发用户数指在同一时刻内，登录体系并进行事务操作的用户数量。并发用户数关于长衔接体系来说最大并发用户数即是体系的并发接入才能。关于短衔接体系而言最大并发用户数并不等于体系的并发接入才能，而是与体系架构、体系处理才能等各种状况相关。例如体系吞吐才能很强，加上短衔接一般都有衔接复用，往往并发用户数大于体系的并发接入衔接数。所以关于大部分短衔接类型的体系，吞吐量形式（RPS形式，Request Per Second）比较适合，也是阿里的最佳实践，PTS 支撑 RPS 形式的压测，吞吐量的压测构建和衡量一步到位。在测验中，选用虚拟用户来模仿实践中用户进行事务操作
    2. 简称 Virtual User：VU
    3. 规范一般状况下，功用测验是将体系处理才能容量测出来，而不是测验并发用户数，除了服务器长衔接或许影响并发用户数外，体系处理才能不受并发用户数影响，能够用最小的用户数将体系处理才能容量测验出来，也能够用更多的用户将体系处理才能容量测验出来

  3. 错误率

    1. 界说及解说错误率指体系在负载状况下，失败买卖的概率。错误率＝（失败买卖数/买卖总数）100%。安稳性较好的体系，其错误率应该由超时引起，即为超时率。
    2. 简称 Virtual Failure Ratio：FR: VU
    3. 规范不同体系对错误率的要求不同，但一般不超出千分之六，即成功率不低于 99.4%

资源目标

  1. CPU

    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

    1. 界说及解说内存是核算机中重要的部件之一，它是与 CPU 进行交流的桥梁。核算机中一切程序的运转都是在内存中进行的，因而内存的功用对核算机的影响非常大
    2. 简称 Memory 便是内存的简称
    3. 规范现代的操作体系为了最大利用内存，在内存中存放了缓存，因而内存利用率 100% 并不代表内存有瓶颈，衡量体系内有瓶颈首要靠 SWAP（与虚拟内存交流）交流空间利用率，一般状况下，SWAP 交流空间利用率要低于 70%，太多的交流将会引起体系功用低下

  5. 磁盘吞吐量

    1. 界说及解说磁盘吞吐量是指在无磁盘毛病的状况下单位时刻内经过磁盘的数据量
    2. 简称 Disk Throughput
    3. 规范磁盘目标首要有每秒读写多少兆，磁盘繁忙率，磁盘行列数，均匀服务时刻，均匀等候时刻，空间利用率。其间磁盘繁忙率是直接反映磁盘是否有瓶颈的重要依据，一般状况下，磁盘繁忙率要低于 70%

  7. 网络吞吐量

    1. 界说及解说网络吞吐量是指在无网络毛病的状况下单位时刻内经过的网络的数据数量。单位为 Byte/s。网络吞吐量目标用于衡量体系关于网络设备或链路传输才能的需求。当网络吞吐量目标挨近网络设备或链路最大传输才能时，则需求考虑晋级网络设备
    2. 简称 Network Throughput
    3. 规范网络吞吐量目标首要有每秒有多少兆流量进出，一般状况下不能超过设备或链路最大传输才能的 70%

中间件目标

  1. 界说及解说常用的中间件例如 Tomcat、Weblogic 等目标首要包含 JVM、ThreadPool、JDBC，详细如下：

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

  1. 规范
    • 当时正在运转的线程数不能超过设定的最大值。一般状况下体系功用较好的状况下，线程数最小值设置 50 和最大值设置 200 比较合适
    • 当时运转的 JDBC 衔接数不能超过设定的最大值。一般状况下体系功用较好的状况下，JDBC 最小值设置 50 和最大值设置 200 比较合适
    • GC 频率不能频频，特别是 FULL GC 更不能频频，一般状况下体系功用较好的状况下，JVM 最小堆巨细和最大堆巨细分别设置 1024 M 比较合适

数据库目标

  1. 界说及解说常用的数据库例如 ＭySQL 目标首要包含 SQL、吞吐量、缓存命中率、衔接数等，详细如下：

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

规范

    • SQL 耗时越小越好，一般状况下微秒级别
    • 命中率越高越好，一般状况下不能低于 95%
    • 锁等候次数越低越好，等候时刻越短越好

前端目标

  1. 界说及解说前端目标首要包含页面展现和网络所花的时刻，详细如下：

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

  1. 规范
    • 页面要尽或许小及压缩
    • 页面展现和花费时刻越短越好

安稳性目标

  1. 界说及解说最短安稳时刻：体系依照最大容量的 80% 或规范压力（体系的预期日常压力）状况下运转，能够安稳运转的最短时刻。一般来说，关于正常工作日（8小时）运转的体系，至少应该能确保体系安稳运转８小时以上。关于 724 运转的体系，至少应该能够确保体系安稳运转 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 更适用于云资源的监控，特别对 Kubernates 和容器的监控非常全面，对运用云原生技能的用户，上手更简略。

总结下来，Prometheus 相较 Zabbix，更适合于压测中高并发监控目标的收集和聚合，而且更适用于云资源的监控，且易于扩展。PTS 供给压测时的体系功用目标， Prometheus 供给资源监控和全体可观测的才能，一站式解决压测可观测的问题。

怎么运用Prometheus 完结压测监控

开源 JMeter 改造

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

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

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

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 压测专属版，欢迎大家选购！

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