技术分享 | 性能测试可视化监控与实战分析

导读：性能测试是一项非常看重过程的测试，需要在压测过程中有察觉性能问题和定位到性能问题的能力。完善的性能监控图形工具和图形分析技能，是压测过程中性能分析及定位的基础。本文将分享可视化监控平台快速搭建与常见异常图形分析。

一、背景

在性能监控内容中，有操作系统、应用服务器、中间件、队列、缓存、数据库、网络、前端、负载均衡、Web 服务器、存储、代码等很多需要监控的点。

以往我们的ERP是部署在Windows下，通过Windows自带的Perfmon工具可实现基础指标的监控(如下图)。

目前ERP国产化改造后，支持容器化部署，所有应用及中间件均部署在K8S集群中，数据库在集群外部署，且未来随着混合云的应用，我们需要部署一套能集成各种环境的监控分析平台，统一入口分析。本文分享将分享监控平台的快速搭建及常见监控图谱的分析实践。

二、监控平台搭建

2.1 监控组件选取

1.采集器选取：选取目前包含130多个插件的telegraf

2.数据收集库选取：选取时序数据库influxdb

3.可视化平台选取：选取目前最强大的grafana

以上3个开源工具，可以满足目前几乎所有的系统、组件、数据库的监控，另外为了能高度兼容K8S云原生环境的监控，我们选取prometheus。

2.2 快速搭建可视化监控平台

2.2.1 安装和启动时序数据库influxdb-1.8.10

#wget https://dl.influxdata.com/influxdb/releases/influxdb-1.8.10.x86_64.rpm

#yum localinstall influxdb-1.8.10.x86_64.rpm

#systemctl start influxdb

查看influxdb是否安装成功，安装成功如下所示

# influxd

2.2.2 安装和启动采集器telegraf-1.21.1

#wget https://dl.influxdata.com/telegraf/releases/telegraf-1.21.1-1.x86_64.rpm 

#yum localinstall telegraf-1.21.1-1.x86_64.rpm

#systemctl start telegraf

查看telegraf状态如下图正常

配置telegraf文件

#vi /etc/telegraf/telegraf.conf

如下图所示，只需要配置红色箭头3个地方，即可以自动连接到influxdb。

如下图所示，开启相关收集器的插件，查找对应的inputs.即可

比如，还能配置mysql相关指标监控，如下图，查找对应的inputs.mysql即可。

2.2.3 安装和启动grafana-6.5.1-1

#wget https://dl.grafana.com/oss/release/grafana-6.5.1-1.x86_64.rpm

#yum localinstall grafana-6.5.1-1.x86_64.rpm

# systemctl status grafana-server.service

2.2.4 监控中引入数据源

以上部署方式，已满足大多数监控。如果测试的环境还包含K8S集群，那么可以单独安装有针对性的prometheus，即kube-prometheus在K8S集群中，这样同时可安装成功prometheus和grafana，并可以免除手工配置。只需要配置好ingress后，再通过grafana的数据源添加influxdb的数据源，这样就可以实现可视化立体监控统一入口。

2.2.5 重要事项说明

Influxdb版本说明。写这篇文章时，influxdb的版本已经更新到了influxdbV1.21.1版本，但还是建议大家使用influxdbV1.8.10。因为influxdbV1.21.1版本对应的grafana监控模板很难找到，influxdbV1.21.1的权限token设置等要更多一些，入门使用influxdbV1.8.10还是更加方便些。而Telegraf和grafana可以采用最新的版本。

telegraf修改配置说明。无需在influxdb中手动创建数据库。在配置好telegraf.conf的database后，重启telegraf可以自动生成该库，并自动写入数据(下图为查influxdb中，生成了telegraf数据库)。

其它说明。Influxdb默认端口8086。grafana默认端口3000。

grafana监控模板可上grafana官网获取，比如这里用的服务器资源监控模板是https://grafana.com/dashboards/14842

mysql指标监控用的是https://grafana.com/dashboards/1177

2.2.6 监控平台效果展示

操作完以上配置后，就可以开始使用强大的监控平台了。如下图

Linux服务器监控（例）

K8S集群监控（例）

Mysql监控（例）

三、性能测试异常图形分析

性能测试过程中,如果压力平稳，长时间保持在一定的QPS请求量。那么其响应时间曲线、服务器资源利用曲线、网络吞吐曲线应该是平稳的。如果存在着不平稳，可能存在性能和稳定性问题。

性能测试过程中,如果压力在设计与需求范围内逐步增加，对应的响应时间曲线、服务器资源利用曲线、网络吞吐曲线应该是逐步增加，如果存在突然增加，可能存在性能和稳定性问题。

以下列举性能测试过程中，异常性能监控图形分析，供参考。

3.1多维度对比图形异常

现象：压测过程中系统响应变慢、超时。

分析：如上图所示，在监控面板中显示mysql threads connected连接持续走高，其它图形平稳或者短时间变高后回落。判定为mysql客户端连接数出现等待，可能是连接数资源不够。由于单个pod连接数有限制，通过增加K8S中对应应用的pod个数后，该问题得到解决。

3.2水平持续后，断崖式下跌

现象，压测过程中系统报503错误。

分析：如上图。性能测试过程中压力平稳，一直保持在一定的QPS请求量，但数据库服务器内存“水平持续后，断崖式下跌，且未完全消除变为0”。产生的原因大概率由数据库服务重启引起。此时需要查看日志进行分析。Mysql可以查看mysql.log，查找到对应时间点异常信息进行分析，找到对应SQL进行优化后，该问题得到解决。

3.3缓慢增长后，断崖式下跌

现象，24小时稳定性能测试过程中，监控异常。

分析：如上图。性能测试过程中压力平稳，一直保持在一定的QPS请求量，但应用程序pod内存“缓慢匀速增涨到最大值后断崖式下跌，且其它资源使用正常，且它资源无异常“一般为内存泄漏或异常。通过抓取dump进一步分析，发现代码存在异常导致内存泄漏，优化后得到解决。

3.4反复式断崖下跌

现象1，24小时稳定性能测试过程中，内存异常。

分析：如上图。在压力平稳的情况下，应用程序pod内存反复断崖式下跌，内存使用并未达到瓶颈值，图形中颜色多变。该情况为重新创建了新pod，剔除了原有pod。经分析为程序处理不及时，内存中轨迹日志堆积引起的系统异常，后经代码修改后，该问题得到解决。

现象2，24小时稳定测试过和中，CPU异常。

分析：如上图。在压力平稳的情况下，数据库CPU反复断崖式下跌。一般存在性能较差的SQL语句，可以进行SQL跟踪分析。通过SQL跟踪分析为定时任务SQL存在性能问题引起，优化后该问题得到解决。

3.5 快速式增长，不下跌

现象，压测过程中系统报连接数已超出。

分析：如上图。性能测试过程中压力平稳，一直保持在一定的QPS请求量，数据库客户端连接数缓慢增涨后维持高位。该问题可能由数据库引起，也可能引程序引起。因为数据库排查相对快，首先需要跟踪SQL，查看SQL是否存在死锁与阻塞。在SQL无死锁阻塞的情况下，可判定为应用存在着锁。应用存在着锁，分析相对困难，需要抓包或进行代码逐行屏蔽排除分析，此处需要开发协助。此处后经修改代码后，问题得到解决。

3.6 缓慢增长，不下跌

现象，24小时稳定性能测试过程中，系统响应越来越慢。

分析：如上图。性能测试过程中压力平稳，一直保持在一定的QPS请求量，数据库CPU缓慢增涨后维持高位。通过分析为数据库日志表数据持续增涨后，日志写入时间耗时变长，SQL执行消耗资源越来越大引起。后经过分表和优化索引后问题得到解决。

三、总结

grafana+influxdb +telegraf+prometheus结合起来的应用范围和监控、预警能力非常强大，还可以结合jmeter进行使用，还可以进行数据接入分析，创建自定义数据分析模型。后续文章我们会深入讲解它们的应用和性能分析例子。

------ END ------

作者简介
赵同学： 测试专家，目前负责天际开放平台的测试工作。

也许您还想看：

更多明源云·天际开放平台场景案例与开发小知识，可以关注明源云天际开发者社区公众号：