性能瓶颈定位最佳实践：使用Prometheus 观测性能压测指标

最新推荐文章于 2024-05-31 17:25:47 发布

weixin_39009745

最新推荐文章于 2024-05-31 17:25:47 发布

阅读量1.2k

点赞数 12

文章标签： prometheus 腾讯云

本文链接：https://blog.csdn.net/weixin_39009745/article/details/135966633

版权

本文介绍了在性能压测中如何通过腾讯云可观测体系，利用Prometheus和Grafana来收集、监控和分析系统指标，以识别系统瓶颈，包括Counter、Gauge和Histogram的使用，以及如何设计和查询核心指标来评估系统容量和性能拐点。

摘要由CSDN通过智能技术生成

柯开腾讯云可观测

前言

性能压测是一个充满挑战的领域，性能评估和优化贯穿在我们开发、测试、部署、上线等各个阶段，直接影响系统运行效率和用户使用体验。通过性能测试，我们可以：

确定系统在特定条件下的响应速度、稳定性和可扩展性；
验证系统是否满足预定的性能标准，比如：吞吐量、响应时间、资源利用率等。
在高负载情况下，系统可能会表现出不稳定，性能测试可以帮助发现在高负载下可能导致系统崩溃或错误的瓶颈。
压测也可以节省业务成本：观测系统链路各环节负载，对于负载较低的环节也可以适当缩容。帮助我们在链路各个环节设置合适的负载比例，在提升系统总体稳定性同时，有效的节省成本。

用户做性能测试最根本的诉求是评估系统容量以及发现系统瓶颈，用户系统需要观测的点通常包括：业务应用指标、操作系统、网络延时,那么我们如何才能准确评估系统呢？

性能压测可观测

在做性能压测的时候，我们都会问到以下问题：

我的系统最大能承载多大的 QPS？要满足10万用户同时访问，我的网站能不能承受对应压力？压测过程中出现错误，怎么去定位是哪里错误...

对于这些问题，很多时候真正的难点不是如何去解决问题，而是如何去定位问题。只要定位到了系统瓶颈点，很多时候解决起来就没有那么复杂了。

首先我们需要能够在压测时，对系统的各项指标了如指掌。可观测体系主要包含3大支柱：Metrics、 Logs、 Traces。三者既可独立工作，也可相辅相成，推导出系统整体的状况。

Metircs: 是一种聚合的度量数值，能够量化系统各个维度指标，常用来提供系统全局视图，一般包括 Counter, Gauge,Histogram 等指标类型。

Logs: 应用程序运行过程中产生的日志或者事件，能够提供我们系统运行的上下文信息，例如：某个变量值，发生错误详情等。

Traces: 提供请求从发送到完成响应整个链路。在分布式系统中，一个请求完成需要经过多个服务，Trace 给我们独特视角，提供请求在链路各个环节的响应时间、响应体、是否报错等。通过 Trace 更方便分析出请求中的异常环节。

本文我们主要介绍在压测过程中 Prometheus 存储指标，并使用 Grafana 将指标可视化。通过观测指标的动态变化，发现系统瓶颈。

指标概述

Counter：只增不减的计数器

Counter 是一种累积度量指标，用于表示一个只能增加的值，如果重置系统或服务，Counter 可能会从0开始重新计数。Counter 最常见的用途是计数器，用来记录发生的事件数量，比如请求的数量、完成的任务数、错误的数量等。

例如，我们有一个 Counter 类型指标：http_requests_total ，用于记录请求次数。

通过 rate()函数获取请求 QPS:

rate(http_requests_total[5m])

查询系统访问量前10的 http 请求：

topk(10, http_requests_total)

Gauge: 有增有减的度量衡

Gauge 与 Counter 不同，Counter 用来反映事件发生次数，而 Gauge 用来反映系统当前的状态。比如当前的温度、服务器 CPU/内存使用率、剩余可用内存等。

比如：通过 Gauge 指标，查看节点剩余可用内存：


# HELP node_memory_MemAvailable_bytes Memory information field MemAvailable_bytes. 
# TYPE node_memory_MemAvailable_bytes gauge
node_memory_MemAvailable_bytes

查看剩余可用内存比例（这个语句通常可用来设置一个警报，当剩余可用内存低于某个阈值时通知你，这样你就可以采取行动避免系统出现内存不足的情况）：

(node_memory_MemFree_bytes/node_memory_MemTotal_bytes)*100

Histogram/Summary: 分析数据分布

Histogram 和 Summary 主要用于统计和分析样本的分布情况。在很多时候，我们会使用平均值来量化某些指标，比如 CPU 平均使用率，请求平均响应时间。这种方式的问题是：如果大多数请求响应时间在100ms, 个别请求响应时间在10s, 平均响应时间会掩盖掉部分请求响应时间长的长尾请求。

为了区分是平均的慢还是长尾的慢，最简单的方式就是按照请求延迟的范围进行分组。比如：统计延迟在0～10ms请求有多少、10～50ms的请求有多少。通过这种方式我们可以快速分析系统慢的原因。使用 Histogram 和 Summary 来快速了解监控样本的分布情况。

以 Histogram 为例，通常我们使用 histogram_quantile 函数来计算百分位数。例如，要计算请求响应时间的第90百分位数：

histogram_quantile(0.9, rate(http_response_duration_seconds_bucket[5m]))

这个查询会返回过去5分钟内所有记录的请求持续时间的第90百分位数。通过这种方式，Histogram 为你提供了强大的工具来监控和理解你的系统性能。

设计观测指标

我们可以通过性能压测暴露系统瓶颈，通过选择合适可观测工具、设计科学的指标监控，根据指标变化来帮助我们定位系统瓶颈。

核心指标

压测过程中，从施压方看我们需要关注的核心指标有：

请求响应时间：包括平均响应时间、响应时间百分比水位
请求 RPS
请求成功率，失败率
请求错误原因
压测并发数
检查点成功数，失败数
请求发送接收字节数
施压机内存/CPU 使用率等

指标维度

每个指标最好能够区分不同的维度，比如：

按返回码统计不同请求的 QPS，比如返回码为200的请求的 QPS 是多少，返回码为500的请求的 QPS 是多少？
统计发往不同服务的请求的 QPS，比如压测 www.test1.com 和 www.ok1.com 的请求的 QPS 分别是多少？

以 http 请求为例，常见的维度划分如下：

job: 压测任务标识，每一次压测都是一个不同的 job。
method: 请求方法，比如 GET,POST,HEAD 等。
proto: 请求协议，比如 http,https,http2。
service: 请求地址，比如 http://www.test1.com。
status: 请求响应码，比如 200,404,500 等。
result: 标识请求响应码，比如200或者其他小于400对应OK， 404对应 Not Found , 500对应 Internal Error 。
check: 检查点/断言名字，一般用于简单描述该断言的作用。

指标设计

基于此我们设计一套最基本、常用的指标体系，能够覆盖绝大部分用户的使用需求。你也可以基于我们设计的指标体系进行拓展，来满足不同的需求。

Metric	Type	Labels	Description
req_total	Counter	job,method, proto,service, status, result	请求次数
req_duration_seconds	Histogram	job,method, proto,service, status, result	请求耗时
checks_total	Counter	job, check, result	检查点
send_bytes_total	Counter	job,method, proto,service, status, result	发送字节数
receive_bytes_total	Counter	job,method, proto,service, status, result	接收字节数
num_vus	Gauge	job	并发数，可用于指代虚拟用户数量。如果是JMeter压测，也可用于指代线程数

有了以上指标，那么就可以设计一系列查询语句，查询我们感兴趣的内容。

查看实时的并发用户数

sum(num_vus{job=~"$job"})

查看请求的 QPS

# 查看不同请求的QPSsum(rate(req_total{job=~"$job"}[1m])) by (service)# 查看成功请求的QPSsum(rate(req_total{job=~"$job",result="ok"}[1m]))# 查看指定http://www.test1.com服务的QPSsum(rate(req_total{job=~"$job",service="http://www.test1.com"}[1m]))

查看请求失败率

# 请求总体失败率sum(rate(req_total{job=~"$job",result!="ok"}[1m]))/sum(rate(req_total{job=~"$job"}[1m]))# 基于请求维度，查看各请求的失败率sum(rate(req_total{job=~"$job",result!="ok"}[1m])) by (service)/sum(rate(req_total{job=~"$job"}[1m])) by (service)

查询请求响应时间

# 查询请求平均响应时间sum(rate(req_duration_seconds_sum{job=~"$job"}[15s]))/sum(rate(req_duration_seconds_count{job=~"$job"}[15s]))
# 查询请求中位数（50百分位）响应时间histogram_quantile(0.50, sum(rate(req_duration_seconds_bucket{job=~"$job"}[1m])) by (le))
# 查询请求90百分位响应时间histogram_quantile(0.90, sum(rate(req_duration_seconds_bucket{job=~"$job"}[1m])) by (le))

查询请求出入带宽

# 请求出带宽汇总sum(rate(send_bytes_total{job=~"$job",region=~"$region"}[1m]))# 请求入带宽汇总sum(rate(pts_engine_receive_bytes_total{job=~"$job",region=~"$region"}[1m]))

检查点成功率（用户自定义的 test 语句，在 JMeter 中对应断言）

# 检查点成功率sum(rate(checks_total{job=~"$job", result="ok"}[1m]))/sum(rate(checks_total{job=~"$job"}[1m]))# 指定检查点成功率sum(rate(checks_total{job=~"$job", result="ok",check="response contains hello"}[1m]))/sum(rate(checks_total{job=~"$job", check="response contains hello"}[1m]))

用户也可以基于以上 demo 进行灵活扩充，对被压测服务进行同样的监控。在压测时候，对比查看压测平台生成的指标报告与用户服务的指标报告，综合分析排查问题。

我们使用 Prometheus 存储以上指标，使用查询语句在 Prometheus 中查询我们感兴趣的数据，最后通过 Grafana 可视化展示以上数据。一边压测，一边实时观测服务性能指标变化。

使用腾讯云云压测

腾讯云云压测是一款分布式性能测试服务，可模拟海量用户的真实业务场景，全方位验证系统可用性和稳定性。支持按需发起压测任务，提供百万并发多地域流量发起能力。

支持原生 JMeter 压测，白屏录入以及高级脚本模式，支持十几种协议，还具备常态化压测、持续测试、集成腾讯云的云监控产品生态等能力，提供最佳实践方案，保障业务性能质量。

下面我们使用腾讯云云压测来压测我们服务。除开生成 PTS 原生的报告外，也将压测指标导出一份到腾讯云 Prometheus。

创建 JMeter 压测场景

上传 jmx 脚本

必选：上传 jmx 脚本
可选：
- 上传 Jar 包：如果你的脚本中使用了 JMeter 三方插件，你可以上传对应jar 包，来拓展 JMeter 功能
- 上传 properties 文件：在原生 jmeter.properties 文件基础上，自定义 JMeter 属性
- sv 文件：在 Jmeter 中读取 csv 文件中的数据，作为变量在脚本中引用
- 其他文件：任何在 jmx 中脚本引用的其他文件
将报告导出到腾讯云 Prometheus

在高级配置 -> 压测指标导出 -> 腾讯云 Prometheus 托管集群，点击添加配置，选择你的实例：

如果你在该地域没有实例，你也可以点击新建实例。

运行压测脚本

点击保存并运行即可开始压测。

查看实时报告

你可以选择不同的页签，查看不同维度的报告详情。

在 Prometheus 中查看压测报告

在压测过程中，我们将指标同步发送到腾讯云 Prometheus 中。我们也可以在 Prometheus 中查询我们指标，自定义感兴趣的查询语句。

1.登录 Prometheus 控制台, 在搜索栏根据实例名称找到你的 Prometheus 实例

2.单击实例 ID，进入实例详情

如果你的 Prometheus 实例没有对应的 Grafana, 可以点击绑定 Grafana。通过 Grafana 来展示 Prometheus 指标

3.选择数据采集 ->集成中心
搜索云压测 PTS 应用，在 Dashboard 操作中，点击 Dashboard 安装/升级，将云压测监控面板安装到 Prometheus 绑定的 Grafana 上

4.在 Grafana 中查看压测报告

登录 Prometheus 绑定的 Grafana 页面
搜索 PTS，查看云压测压测报告
点击 PTS 任务详情，查看报告详情
压测时如何评估系统瓶颈

在压测时，我们主要关注：系统吞吐量（RPS，网络带宽）、响应时间、并发用户数等。

这三者可以用简单公式进行概括：

RPS = VU（并发数）/ 平均响应时间

如何理解压测公式?

我们以一个线程循环去执行某个请求为例：如果请求平均响应时间是10ms, 那么一个并发每秒可执行100个请求，对应的 RPS = 100req/s。

从这个公式我们可以推导，如果想提升压测的总体 RPS，有以下几种方法：

增加并发数，且请求平均响应时间保持不变。

这种情况就是被压服务还没有饱和，压测 RPS 随着并发压力的增加而增加。
降低请求平均响应时间， VU 保持不变。

这种情况比较理想，请求平均响应时间降低，代表被压服务进行了优化，单个 VU 单位时间内能够发送更多的请求。在现实压测中，很可能随着 VU 增加，被压系统压力增加，响应时间也随之增加。

如果响应时间增加系数小于 VU 增加系数，总体 RPS 还是在变大，系统还未达到瓶颈。
如果响应时间增加系数大于 VU 增加系数，压测的表现就是随着 VU 增大，总体 RPS 反而降低，此时系统已经达到瓶颈。

评估系统性能拐点

压测就是在压力不断增加情况下，找到业务系统扩展性的拐点，即系统瓶颈/最大容量。

在一定的阶段，我们观测到扩展性是线性变化的。到达某一点时，此时对于资源的争夺开始影响性能。这一点也可以认为是系统拐点。作为曲线分界，过了拐点，整体的吞吐量会随着资源争夺加剧偏离线性扩展。最终，资源争夺的开销反而导致完成的请求数变少，吞吐量反而下降。

这种情况可能在系统负载到达 100% 使用率（饱和点）之后发生，也可能在接近100% 使用率的时候，这个时候排队比较明显。

性能的非线性变化，我们也可以通过响应时间的变化来看出来：

性能下降的原因非常多，除开上面提到的频繁上下文切换外：可能的原因还有：系统内存不够，开始频繁的换页（swap）来补充内存。随着系统磁盘 IO 增加，磁盘 IO 可能进入缓冲排队。另外还有可能系统内部实现队列算法，来进行削峰操作，导致请求处理等待时间变长。

Prometheus 近期国际站控制台全新改版上线、优化了告警功能、新增支持更多云产品的采集功能等等。更多详情可点击产品月报进行了解。

为了给您提供更好的腾讯云可观测平台产品服务，希望您能抽出 2-3 分钟扫描以下二维码填写问卷！优质反馈将有机会获得腾讯龙年限定公仔、腾讯视频 SVIP 月卡、微信气泡狗抱枕、U型枕任意礼品。

联系我们

如有任何疑问，欢迎扫码进入官方交流群~

关于腾讯云可观测平台

腾讯云可观测平台（Tencent Cloud Observability Platform，TCOP）基于指标、链路、日志、事件的全类型监控数据，结合强大的可视化和告警能力，为您提供一体化监控解决方案。满足您全链路、端到端的统一监控诉求，提高运维排障效率，为业务的健康和稳定保驾护航。功能模块有：
Prometheus 监控：开箱即用的 Prometheus 托管服务；
应用性能监控 APM：支持无侵入式探针，零配置获得开箱即用的应用观测能力；
云拨测 CAT：利用分布于全球的监测网络，提供模拟终端用户体验的拨测服务；
前端性能监控 RUM：Web、小程序等大前端领域的页面质量和性能监测；
Grafana 可视化服务：提供免运维、免搭建的 Grafana 托管服务；
云压测 PTS：模拟海量用户的真实业务场景，全方位验证系统可用性和稳定性；
......等等

点击播放视频快速了解👇
《腾讯云可观测平台》