【性能测试】ChaosTesting(混沌测试)&ChaosBlade(混沌实验工具)(一)

一、chaos testing

1. 介绍

软件测试方法，有目的地、有计划的引入系统中的混乱和不稳定因素，从而测试系统在面对故障和不确定性时的稳定性、可恢复性和鲁棒性。有助于在生产环境之前或期间，识别和解决系统中可能存在的弱点，以确保系统在实际运行中能够正常工作

2. 测试目的

探索系统在不同异常条件下的行为

3. 关键特征和原则

3.1 有目的的引入混乱

并非随机性的破坏系统，而是有计划地、有目的地引入故障、错误或不稳定因素，例如随机终止服务、模拟网络故障、延迟或丢包等

3.2 生产环境下测试

通常在生产环境或非生产环境的生产仿生环境中进行，这有助于测试系统在真实条件下的表现，而不仅仅是在受控测试环境中

3.3 监控和度量

进行混沌测试时，团队通常会使用监控工具和度量指标来跟踪系统的各个方面，以评估系统对混乱的响应

3.4 迭代

团队通过每一次测试收集的数据和经验来不断改进系统的可靠性和鲁棒性

3.5 以用户为中心

关注的不仅仅是系统内部的稳定性，还关注用户体验。团队会评估系统在混乱条件下是否能够提供良好的用户体验

3.6 防止深层次故障

通过引入混乱，chao testing有助于发现并修复系统中的潜在问题，防止深层次故障

3.7 自动化

为了有效的实施混沌测试，通常采用自动化工具和脚本，以便能够在系统中引入混沌因素并监控

4. 传统测试和chaos testing的差异

4.1 测试目标

传统测试： 确认是否按照预期工作
混沌测试： 测试系统在不可预测的混乱环境中的表现

4.2 测试方法

传统测试： 采用预定义的测试计划和测试用例
混沌测试： 更加注重随机性和不可预测性，通过引入各种混乱因素来观察系统在复杂和混乱环境下的行为

4.3 测试环境

传统测试： 通常在受控的测试环境中进行，测试人员尽可能的模拟真实环境并排除外部干扰，以确保测试的准确性和可重复性
混沌测试： 更关注真实世界中的不确定性和变化。测试环境更接近生产环境，并且引入了混沌因素来模拟真实场景中可能发生的问题

4.4 测试周期

传统测试： 通常在软件开发声明周期的早起或中期进行，着重于开发生命周期的早期或者中期进行，着重于确认软件是否满足规格和设计
混沌测试： 可以在整个软件开发周期中进行，但更倾向于在系统准备投入生产之前进行，以便发现系统在真实环境中的弱点

4.5 测试结果

**传统测试：**通常产生明确的通过/不通过结果，并用于确认系统的特定功能或性能是否达到预期
混沌测试： 强调系统在复杂条件下的整体稳定性和弹性。测试人员可能更注重观察系统在混沌环境中的行为，而不仅仅是验证特定的功能点

5. 挖掘系统各级别的弱点

通过系统基础设施和应用程序堆栈的各个级别引入故障和不稳定性，chaos testing可以帮助识别并加固系统基础设置和应用程序堆栈各个级别的弱点，提高系统弹性和容忍度，主要有以下5个方面：

5.1 系统整体弹性测试

chaos testing允许在系统整体层面上引入故障，以模拟真实世界中可能发生的各种问题，例如服务器故障、网络问题、资源瓶颈等。这有利于评估系统对这些问题的反应。并能确保系统能够从故障中迅速恢复

5.2 应用程序层面的鲁棒性

在应用程序层面，chaos testing可以测试应用程序的鲁棒性和容错能力。例如模拟数据库故障，服务超时或其他应用程序组件的故障，以确保应用程序能够适应这些情况并提供合理的用户体验

5.3 微服务和服务间通信

对于采用微服务架构的系统，chaos testing有助于了解各个微服务间的通信和依赖关系。通过模拟特定微服务的故障，可以评估系统在单个微服务失败时的表现，以及是否能够正确处理微服务之间的故障

5.4 基础设施和云服务的可靠性

chaos testing可以测试系统在使用云服务时的可靠性，模拟云服务中的故障，如实例终止，存储故障等，有助于确保系统能够在这些环境中稳定运行

5.5 网络和通信可靠性

引入网络故障、通信延迟和丢包等方面测试，可以确保系统能够在不稳定的网络环境中正常运行。

6. 混乱因素的六大类别

6.1 资源故障 resource failures

模拟系统资源（如内存、处理器、磁盘空间）的耗尽或故障。
这可以帮助测试系统在资源有限或不可用的情况下的表现。

6.2 服务故障 service failures

模拟单个或多个服务的故障，包括服务崩溃、超时、响应错误等。
这有助于评估系统在服务故障的情况下的容错和恢复能力。

6.3 网络故障 network failures

引入网络故障，如模拟延迟、丢包、网络分区等，以测试系统在不稳定网络环境下的表现。
这对于分布式系统特别重要。

6.4 数据故障 data failures

模拟与数据相关的故障，如数据库连接失败、数据损坏、数据丢失等。
这有助于测试系统在处理数据异常情况时的鲁棒性

6.5 安全故障 securify failures

引入安全相关的混乱，如模拟拒绝服务攻击、未经授权访问、数据泄漏等。
有数据评估系统在安全威胁的情况下的反应能力

6.6 环境故障 environmental failures

模拟环境因素引发的故障，例如模拟服务器硬件故障、配置错误或第三方依赖问题等。
有助于测试系统在现实世界中各个环境不稳定狭隘的表现

7. 注意事项

1. 在执行Chaos Testing时，需要注意谨慎操作，并确保执行的操作不对生产环境产生不良影响，从而避免影响客户的测试和使用；
2. 并且必须使用Running状态的Pod进行测试，否则测试意义不大；
3. 除此之外，注意结合监控和日志记录跟踪系统的行为，从而提前发现并解决潜在问题。

二、 chaosblade混沌试验工具

测试官方文档：https://chaosblade-io.gitbook.io/chaosblade-help-zh-cn/

1. chaoblade能解决哪些问题

1.1 衡量微服务的容错能力

通过模拟调用延迟、服务不可用、机器资源满载等，查看发生故障的节点或实例是否被自动隔离，下线、流量调度是否正确，预案是否有效，同时观察系统整体的QPS或RT是否受到影响，在此基础上可以缓慢增加故障节点范围，验证上游服务限流降级、熔断等是否有效、最终故障节点增加到请求服务超时，估算系统容错红线，衡量系统容错能力

1.2 验证容器编排配置是否合理

通过模拟杀服务Pod、杀节点、增大Pod资源负载，观察系统服务可用性，验证副本配置、资源限制配置以及Pod下部署的容器是否合理。

1.3 测试PaaS层是否健壮

通过模拟上层资源负载，验证调度系统的有效性；模拟依赖分布式存储不可用，验证系统的容错能力；模拟调度节点不可用，测试调度任务是否自动迁移到可用节点；模拟贮备节点故障，测试主备节点是否正常

1.4 验证监控告警的时效性

通过对系统注入故障，验证监控指标是否准确，监控维度是否完善，告警阈值是否合理，告警是否快速，告警接收人是否正确，通知渠道是否可用等，提升监控告警的准确性和时效性

1.5 定位与解决问题的应急能力

通过故障突袭，随机对系统注入故障，考察相关人员对问题的应急能力，以及问题上报，处理流程是否合理，达到以战养战，锻炼人定位与解决问题的能力

2. 组件架构

Component Architecture

• Cli 包含 create、destroy、status、prepare、revoke、version 6 个命令
  • prepare： 简写 p，混沌实验前的准备，比如演练 Java 应用，则需要挂载 java agent。要演练应用名是 business 的应用，则在目标主机上执行 blade p jvm --process business。如果挂载成功，返回挂载的 uid，用于状态查询或者撤销挂载使用。
  • revoke： 简写 r，撤销之前混沌实验准备，比如卸载 java agent。命令是 blade revoke UID
  • create: 简写是 c，创建一个混沌演练实验，指执行故障注入。命令是 blade create [TARGET] [ACTION] [FLAGS]，比如实施一次 Dubbo consumer 调用 xxx.xxx.Service 接口延迟 3s，则执行的命令为 blade create dubbo delay --consumer --time 3000 --service xxx.xxx.Service，如果注入成功，则返回实验的 uid，用于状态查询和销毁此实验使用。
  • destroy： 简写是 d，销毁之前的混沌实验，比如销毁上面提到的 Dubbo 延迟实验，命令是 blade destroy UID
  • status： 简写 s，查询准备阶段或者实验的状态，命令是 blade status UID 或者 blade status --type create
• 相关混沌实验数据使用 SQLite 存储在本地（chaosblade 目录下） Create 和 destroy
• 命令调用相关的混沌实验执行器创建或者销毁混沌实验 Prepare 和 revoke
• 命令调用混沌实验准备执行器准备或者恢复实验环境，比如挂载 jvm-sandbox
• 混沌实验和混沌实验环境准备记录都可以通过 status 命令查询

3. 案例

3.1 工具执行命令

3.1.1 命令

# 1. 查看blade命令帮助文档
blade -h
# 2. 所有命令都可以添加-h来查看此命令如何使用，如穿件混沌试验
blade create -h
# 3. 所有命令都可以添加-d来查看更细的执行信息
blade create cpu fullload -d

3.1.2 参数

-d 
# --debug 设置工具为DEBUG模式，主要用于调试使用
-h 
# --help 查看blade命令帮助文档

3.1.3 相关命令

# 1. 创建一个混沌试验
[blade create](blade create.md)
# 2. 销毁一个混沌试验
blade_destory.md
# 3. 准备混沌试验环境，部分实验执行前必须执行
blade_prepare.md
# 4. 撤销混沌实验环境，与prepare操作对应
blade_revoke.md
# 5. 查询混沌实验和混沌实验环境状态
[blade status](blade status.md)
# 6. 查询部分实验所需的系统参数
blade_query.md
# 7. 打印blade工具版本信息
[blade version](blade version.md)
# 8. server模式
[blade server](blade server.md)

3.2 创建一个混沌实验

3.2.1 介绍

创建混沌实验命令，每个实验对应一个uid，后续查询、销毁实验都要用到此uid，如果遗忘了uid，可以通过blade status --type create命令进行查询。create可以简写成c，即blade create可以简写为blade c

3.2.2 命令

# 1.创建cpu满载实验
blade create cpu fullload --cpu-count 1
# 返回结果如下
{"code":200, "success":true, "result":"6fa04946baf42920"}
# code的值等于200说明执行成功，其中result的值就是uid
# 使用top命令验证实验结果
top
%Cpu0 :100.0us, 0.0 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
# 撤销上述实验
blade destory 6fa04946baf42920
# 返回结果如下
{"code":200, "success":true, "result":"command: cpu fullload --cpu-count 2 --debug false --help false"}
# 使用top命令验证实验结果
top
%Cpu0 : 0.3 us, 0.3 sy, 0.0 ni, 99.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st

3.3 创建CPU负载的混沌实验

3.3.1 介绍

CPU相关的混沌实验包含CPU满载，可以指定核数、具体核满载或者总CPU负载百分比
旨在CPU在特定的负载下，验证服务质量、监控告警、流量调度、弹性伸缩等能力
load、fullload、fl命令都可以，即 blade create cpu load、blade create cpu fullload、blade create cpu fl
----执行命令----
      blade create cpu load [flags]

3.3.2 参数

# 1. 设定运行时长，单位是秒，通用参数
--timeout string
# 2. 指定CPU满载的个数
--cpu-count string
# 3. 指定CPU满载具体核，核索引从0开始(0-3 or 1,3)
--cpu-list string
# 4. 指定CPU负载百分比，取值在0-100
--cpu-percent string

3.3.3 示例

# 1. 创建CPU满载实验
blade create cpu load
# 返回结果如下
{"code":200,"success":true,"result":"beeaaf3a7007031d"}
# 使用top命令验证实验效果
Tasks: 100 total,   2 running,  98 sleeping,   0 stopped,   0 zombie
%Cpu0  : 21.3 us, 78.7 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu1  : 20.9 us, 79.1 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu2  : 20.5 us, 79.5 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu3  : 20.9 us, 79.1 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
# 核都满载，实验生效，销毁实验
blade destroy beeaaf3a7007031d
# 返回结果如下
{"code":200,"success":true,"result":"command: cpu load --help false --debug false"}

# 2. 指定随机两个核满载
blade create cpu load --cpu-count 2
# 使用 top 命令验证结果如下，实验生效
Tasks: 100 total,   2 running,  98 sleeping,   0 stopped,   0 zombie
%Cpu0  : 17.9 us, 75.1 sy,  0.0 ni,  7.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu1  :  3.0 us,  6.7 sy,  0.0 ni, 90.3 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu2  :  0.7 us,  0.7 sy,  0.0 ni, 98.7 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu3  : 19.7 us, 80.3 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st

# 3. 指定索引是0,3的核满载，核的索引从0开始
blade create cpu load --cpu-list 0,3
# 使用 top 命令验证结果如下，实验生效
Tasks: 101 total,   2 running,  99 sleeping,   0 stopped,   0 zombie
%Cpu0  : 23.5 us, 76.5 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu1  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu2  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu3  : 20.9 us, 79.1 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st

# 4. 指定索引1到3的核满载
blade create cpu load --cpu-list 1-3

Tasks: 102 total,   4 running,  98 sleeping,   0 stopped,   0 zombie
%Cpu0  :  2.4 us,  7.1 sy,  0.0 ni, 90.2 id,  0.0 wa,  0.0 hi,  0.3 si,  0.0 st
%Cpu1  : 20.0 us, 80.0 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu2  : 15.7 us, 78.7 sy,  0.0 ni,  5.7 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu3  : 19.1 us, 78.9 sy,  0.0 ni,  2.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st

# 5. 指定百分比负载
blade create cpu load --cpu-percent 60
# 可以看到CPU总的使用率达到60%，空闲40%
Tasks: 100 total,   1 running,  99 sleeping,   0 stopped,   0 zombie
%Cpu(s): 15.8 us, 44.1 sy,  0.0 ni, 40.0 id,  0.0 wa,  0.0 hi,  0.1 si,  0.0 st

3.4 磁盘读写io负载实验

----执行命令----
      blade create disk burn

3.4.1 介绍

提升磁盘读写io负载，可以指定受影响的目录，也可以通过调整读写块的大小提升io负载，默认值是10，单位是M，块的数量固定为100，即在默认情况下，写会占用1000M的磁盘空间，读会占用600M的空间，因为读操作会先创建一个600M的固定大小文件，预计在3s之内，在创建时写io会升高。
验证磁盘io高负载下对系统服务的影响，比如监控告警、服务稳定性等。

3.4.2 参数

–path string： 指定提升磁盘 io 的目录，会作用于其所在的磁盘上，默认值是 /
–read： 触发提升磁盘读 IO 负载，会创建 600M 的文件用于读，销毁实验会自动删除
–size string： 块大小, 单位是 M, 默认值是 10，一般不需要修改，除非想更大的提高 io 负载
–timeout string： 设定运行时长，单位是秒，通用参数
–write： 触发提升磁盘写 IO 负载，会根据块大小的值来写入一个文件，比如块大小是 10，则固定的块的数量是 100，则会创建 1000M 的文件，销毁实验会自动删除

3.4.3 示例

# 1. 在执行实验之前可先观察磁盘io读写负载
iostat -x -t 2
# 上述命令会 2 秒刷新一次读写负载数据，截取结果如下
Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00     2.50    0.00    2.00     0.00    18.00    18.00     0.00    1.25    0.00    1.25   1.25   0.25
# 2. 主要观察rkB/s、wkB/s、%util数据。执行磁盘读IO负载高场景
blade create disk burn --read --path /home
# 执行 iostat 命令可以看到读负载增大，使用率达 99.9%。执行 blade destroy UID(上述执行实验返回的 result 值)可销毁实验。

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00     3.00  223.00    2.00 108512.00    20.00   964.73    11.45   50.82   51.19   10.00   4.44  99.90
# 销毁上述实验后，执行磁盘写 IO 负载高场景
blade create disk burn --write --path /home

# 执行 iostat 命令可以看到写负载增大，使用率达 90.10%。
Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00    43.00    0.00  260.00     0.00 111572.00   858.25    15.36   59.71    0.00   59.71   3.47  90.10

# 可同时执行读写 IO 负载场景，不指定 path，默认值是 /
blade create disk burn --read --write

# 通过 iostat 命令可以看到，整个磁盘的 io 使用率达到了 100%
Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00    36.00  229.50  252.50 108512.00 107750.00   897.35    30.09   62.70   53.49   71.07   2.07 100.00

3.5 磁盘填充混沌实验

----执行命令----
      blade create disk fill

3.5.1 介绍

模拟磁盘填充，可以指定填充的目录和填充大小
验证磁盘满下对系统服务的影响，比如监控告警、服务稳定性等

3.5.2 参数

–path string： 需要填充的目录，默认值是/
–size string： 需要填充的文件大小，单位是M，取值是整数，例如 --size 1024
–reserve string： 保留磁盘大小，单位是MB。取值是不包含单位的正整数，例如 --reserve 1024
–percent string： 指定磁盘的使用率，取值是不带%号的正整数，例如 --percent 80
–timeout string： 设定运行时长，单位是s，通用参数

3.5.3 示例

# 1. 执行实验之前，先看下/home所在磁盘大小
df -h /home

Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        40G  4.0G   34G  11% /
# 执行磁盘填充，填充40G，即达到磁盘满的效果(可用34G)
blade create disk fill --path /home --size 40000
# 返回结果
{"code":200,"success":true,"result":"7a3d53b0e91680d9"}

# 查看磁盘大小
df -h /home

Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        40G   40G     0 100% /

# 销毁实验
blade destroy 7a3d53b0e91680d9

{"code":200,"success":true,"result":"command: disk fill --debug false --help false --path /home --size 40000"}

# 查看磁盘大小
df -h /home

Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        40G  4.0G   34G  11% /


# 2. 执行按百分比填充磁盘，并且保留填充磁盘的文件句柄
blade c disk fill --path /home --percent 80 --retain-handle

{"code":200,"success":true,"result":"f1fa65e70950d0eb"}

df -h
/dev/vda1        40G   30G  8.1G  79% /

# 查看文件句柄
lsof /home/chaos_filldisk.log.dat
COMMAND     PID USER   FD   TYPE DEVICE    SIZE/OFF   NODE NAME
chaos_fil 19297 root    3r   REG  253,1 17697865728 394174 /home/chaos_filldisk.log.dat

# 3. 执行保留固定大小实验场景
blade c disk fill --path /home --reserve 1024

df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        40G   37G  1.1G  98% /

3.6 内存占用

----执行命令----
      blade create mem load

3.6.1 介绍

指定内存占用，注意，此场景触发内存占用满，即使指定了–timeout参数，也可能出现通过blade工具无法恢复的情况，可以通过重启机器解决！！！推荐指定内存百分比！
由于目前内存大小计算通过menory.stat文件计算，所以和free命令计算不一致，同top命令一致，验证时请使用top命令查看

3.6.2 参数

–mem-percent string： 内存使用率，取值是从0到100的整数
–mode string： 内存占用模式，有ram和cache两种，例如 --mode ram采用代码实现，可控制占用速率，优先推荐此模式；cache 是通过挂载tmpfs实现；默认值是 --mode cache
–reserve string： 保留内存的大小，单位是MB，如果 mem-percent 参数存在，则优先使用 mem-percent 参数
–rate string： 内存占用速率，单位是 MB/S，仅在 --mode ram 时生效
–timeout string： 设定运行时长，单位是秒，通用参数

3.6.3 示例

# 在执行命令之前，先使用 top 命令查看内存使用信息，如下，总内存大小是 8G，使用了 7.6%
KiB Mem :  7.6/8010196  

# 执行内存占用 50%
blade c mem load --mode ram --mem-percent 50

# 查看内存使用
KiB Mem : 50.0/8010196 

# 执行内存占用 100%
KiB Mem : 99.6/8010196

# 保留 200M 内存，总内存大小 1G
blade c mem load --mode ram --reserve 200 --rate 100
KiB Mem :  1014744 total,    78368 free,   663660 used,   272716 buff/cache
KiB Swap:        0 total,        0 free,        0 used.   209652 avail Mem
KiB Mem : 79.7/1014744  [||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||                   ]

3.7 网络延迟实验场景

----执行命令----
      blade create network delay

3.7.1 介绍

可以指定网卡、本地端口、远程端口、目标 IP 延迟。需要特别注意，如果不指定端口、ip 参数，而是整个网卡延迟，切记要添加 --timeout 参数或者 --exclude-port 参数，前者是指定运行时间，自动停止销毁实验，后者是指定排除掉的延迟端口，两者都是防止因延迟时间设置太长，造成机器无法连接的情况，如果真实发生此问题，重启机器即可恢复。

本地端口和远程端口之间是或的关系，即这两个端口都会发生延迟，只要指定了本地端口或者远程端口，无需指定需要排除的端口。端口与 IP 之间是与的关系，即指定的 IP:PORT 发生延迟。

网络延迟场景主要验证网络异常的情况下，系统的自我容错能力。

3.7.2 参数

–destination-ip string： 目标 IP. 支持通过子网掩码来指定一个网段的IP地址, 例如 192.168.1.0/24. 则 192.168.1.0~192.168.1.255 都生效。你也可以指定固定的 IP，如 192.168.1.1 或者 192.168.1.1/32，也可以通过都号分隔多个参数，例如 192.168.1.1,192.168.2.1。
–exclude-port string： 排除掉的端口，默认会忽略掉通信的对端端口，目的是保留通信可用。可以指定多个，使用逗号分隔或者连接符表示范围，例如 22,8000 或者 8000-8010。 这个参数不能与 --local-port 或者 --remote-port 参数一起使用
–exclude-ip string： 排除受影响的 IP，支持通过子网掩码来指定一个网段的IP地址, 例如 192.168.1.0/24. 则 192.168.1.0~192.168.1.255 都生效。你也可以指定固定的 IP，如 192.168.1.1 或者 192.168.1.1/32，也可以通过都号分隔多个参数，例如 192.168.1.1,192.168.2.1。
–interface string： 网卡设备，例如 eth0 (必要参数)
–local-port string： 本地端口，一般是本机暴露服务的端口。可以指定多个，使用逗号分隔或者连接符表示范围，例如 80,8000-8080
–offset string： 延迟时间上下浮动的值, 单位是毫秒
–remote-port string： 远程端口，一般是要访问的外部暴露服务的端口。可以指定多个，使用逗号分隔或者连接符表示范围，例如 80,8000-8080
–time string： 延迟时间，单位是毫秒 (必要参数)
–force： 强制覆盖已有的 tc 规则，请务必在明确之前的规则可覆盖的情况下使用
–ignore-peer-port： 针对添加 --exclude-port 参数，报 ss 命令找不到的情况下使用，忽略排除端口
–timeout string： 设定运行时长，单位是秒，通用参数

3.7.3 示例

# 1. 访问本机 8080 和 8081 端口延迟 3 秒，延迟时间上下浮动 1 秒
blade create network delay --time 3000 --offset 1000 --interface eth0 --local-port 8080,8081

{"code":200,"success":true,"result":"9b4aa9fabe073624"}

# 可以在另一台相同网络内的机器通过 telnet 命令验证，即 telnet xxx.xxx.xxx.xxx 8080
# 销毁实验
blade destroy 9b4aa9fabe073624

# 2. 本机访问外部 14.215.177.39 机器（ping www.baidu.com 获取到的 IP）80 端口延迟 3 秒
blade create network delay --time 3000 --interface eth0 --remote-port 80 --destination-ip 14.215.177.39

# 可在本机通过 telnet 14.215.177.39 80 命令验证
# 对整个网卡 eth0 做 5 秒延迟，排除 22 和 8000到8080 端口
blade create network delay --time 5000 --interface eth0 --exclude-port 22,8000-8080

# 会发现 22 端口和 8000 到 8080 端口不受影响，可在另一台相同网络内的机器通过分别 telnet xxx.xxx.xxx.xxx 8080 和 telnet xxx.xxx.xxx.xxx 8081 进行测试

3.7.4 常见问题

Q： {“code”:604,“success”:false,“error”:“RTNETLINK answers: File exists\n exit status 2 exit status 1”}
A： 网络相关的场景实验已存在，销毁原有的后再执行。 可以通过 blade status --type create 命令来查看已执行的实验， success 状态的表示正在执行； 如果查找不到相关实验，比如已经删除了原有的 chaosblade 目录，则可通过以下命令恢复实验，注意 eth0 替换为你机器的网卡设备：

tc filter del dev eth0 parent 1: prio 4
tc qdisc del dev eth0 root

也可以添加 –force 命令强制覆盖原有规则。