简介：可观测性包含 Metrics、Traces、Logs3 个维度。可观测能力帮忙咱们在简单的分布式系统中疾速排查、定位问题，是分布式系统中必不可少的运维工具。
作者：拂衣
什么是性能压测可观测
可观测性包含 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 性能，目前收费公测中，欢送应用。
原文链接
本文为阿里云原创内容，未经容许不得转载。