以下文章来源于 CSDN,作者为 weixin_37753227。
前段时间,我司开始实行远程办公的模式。为了保障远程办公的安全,我们使用了 JumpServer 堡垒机作为远程办公的入口,并搭载了高可用环境。不过,由于我们搭载的节点是部署在国内某云的海外节点上,上个月海外光缆出现问题,导致全体同事无法办公。也因为这个事件,我们开始着手研究混沌工程的相关内容。
在研究的过程中,我们发现了另一个问题,即每次操作都需要手动写命令,不能再次自动执行,这耗费了我们大量的精力。好在我们看到 JumpServer 的交流群中在推他们团队的另一款产品——一站式开源持续测试平台 MeterSphere。出于对 JumpServer 的好感,我们决定试一下这个平台。
了解后我们发现,MeterSphere 接口自动化能力非常强大,任务定时执行还支持 Cron 表达式的图形化方式,可以让我这种对 Cron 不是那么懂的人都能用的飞起,感觉可以通过这个平台把混沌测试中的故障注入和接口测试结合起来。
关于 ChaosBlade,用我个人理解的一句话解释就是:ChaosBlade 是阿里开源的一个混沌注入的工具。所谓 “混沌注入” 可以理解为制造各种可能发生的故障(比如 CPU、存储、网络等故障),来模拟线上环境可能会发生的一些问题,通过判断注入后系统是否还能保持稳定来分析和测试出系统的健壮性,从而进一步改善系统。
下面就跟大家简单介绍下,通过 MeterSphere 是如何调用 ChaosBlade 完成一个场景自动化测试的。
准备工作
我们准备的是单节点 JumpServer 一台,这里因为只是实验,配置不做多要求,参考 JumpServer 的推荐配置即可。
准备一台服务器用于安装 MeterSphere 开源持续测试平台,具体操作和使用可参考官网文档。
从 ChaosBlade 的 GitHub 地址上下载基于 Linux 环境的最新安装包,下载完成后传到被测服务器上并解压即可,无需编译。
比如解压到了服务器的/opt 目录下,进入解压后的文件夹,可以看到以下内容:
├── bin
│ ├── chaos_burncpu
│ ├── chaos_burnio
│ ├── chaos_changedns
│ ├── chaos_delaynetwork
│ ├── chaos_dropnetwork
│ ├── chaos_filldisk
│ ├── chaos_killprocess
│ ├── chaos_lossnetwork
│ ├── jvm.spec.yaml
│ └── tools.jar
├── blade
└── lib
└── sandbox
其中 blade 是可执行文件,即 ChaosBlade 工具的 CLI,混沌实验执行的工具。
在这里先简单介绍一下如何使用这个工具:
我们用 CPU 满载(CPU 使用率为 100%)的演练场景举例(注意,在不清楚影响面的情况下,此命令切勿直接在韧性不够的生产系统机器上执行),执行以下命令实施实验:
./blade create cpu fullload
执行结果返回:
{"code":200,"success":true,"result":"7c1f7afc281482c8"}
通过 top 命令查看 CPU 使用率:
CPU usage: 93.79% user, 6.20% sys, 0.0% idle
此时命令已经生效,停止混沌实验,执行:
./blade destroy 7c1f7afc281482c8
返回以下结果,表示停止实验成功:
{"code":200,"success":true,"result":"command: cpu fullload --debug false --help false"}
再去观察 CPU 情况,CPU 负载已回到正常状态:
CPU usage: 6.36% user, 4.74% sys, 88.88% idle
一次 CPU 满载演练完成。
配置相关
我们知道 MeterSphere 可以做到创建场景接口自动化测试,测试的流程包括:
确定一个可观察的稳定指标,如 JumpServer 的资产列表查询;
在 MeterSphere 上定义一个查询稳定指标的接口用例:调用 JumpServer 的资产列表查询的接口;
可以看到,在没有外界干扰的情况下,能够正常调用 JumpServer 的接口查询资产列表。
可以通过如下命令查看 CPU 使用率:
iostat -c 1 1000
可以看到,这次请求的响应时间比较长,说明服务器 CPU 负载的提升,对系统的稳定性有一定的影响,可能会影响后续接口的正常调用。
可以看到对比之前请求,响应时间延长了,原先的 56ms 变成了 192ms。但是依然还是能够正常的请求接口获取数据,说明 CPU 满负载还不能破坏我们预先设定的稳定指标(即正常查询资产列表)。
可以看到,当成功销毁混沌实验后,服务器的 CPU 负载情况已经恢复到原始状态。
可以看到,这一次请求查询中间件列表的接口,响应时间为 63ms,对比在混沌注入后的接近 200ms,速度又变快了。说明服务器 CPU 的负载对于接口响应时延还是有一定影响,到此实验结束。
结果展示
上面只是列出了每个测试用例的截图,这里将完整的场景接口自动化做一个展示:
点击执行,观察结果:
从结果来看,7 个步骤均执行完成,该流程场景测试成功。并且能看出,在混沌注入前后,对接口请求的效果是有一定的影响。明显在注入之后的系统响应时间变长,但是也可以看出 CPU 满负载依然不能破坏稳态,系统依然能稳定运行,JumpServer 也能正常访问。
实验小结及补充
命令:
start 启动 server 模式, 暴露 web 服务
stop 停止 server 模式, 关闭 web 服务
start 命令参数:
-p, --port string 服务端口号,默认是 9526
案例:
# 启动 server 模式,服务端口是 8080
blade server start --port 8080
success, listening on 8080
# 触发 CPU 负载 50% 场景
curl "http://xxx.xxx.xxx.xxx:8080/chaosblade?cmd=create%20cpu%20load%20--cpu-percent%2050"
{"code":200,"success":true,"result":"e08a64a9af02c393"}
# 销毁实验场景
curl "http://xxx.xxx.xxx.xxx:8080/chaosblade?cmd=destroy%20e08a64a9af02c393"
# 停止 blade server
blade server stop
{"code":200,"success":true,"result":"pid is 12619"}
2.相关链接
MeterSphere GitHub 地址:
https://github.com/metersphere/metersphere
ChaosBlade 地址:
https://github.com/chaosblade-io/chaosblade/wiki/%E6%96%B0%E6%89%8B%E6%8C%87%E5%8D%97
ChaosBlade Web 服务 HTTP 接口地址:
https://chaosblade-io.gitbook.io/chaosblade-help-zh-cn/blade-server
MeterSphere 官网地址:
————————————————
版权声明:本文为 CSDN 博主「weixin_37753227」的原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接及本声明。
原文链接:
https://blog.csdn.net/weixin_37753227/article/details/119568691