最近看到一篇 Paper，Observability and Chaos Engineering on System Calls for Containerized Applications in Docker，讲的是如何对 Docker 里面的应用来做 fault injection 以及应用混沌工程，刚好我们正在进行 TiDB Cloud Chaos 平台的研发，要解决同样的问题 - 对在 Docker 里面运行的 TiDB 做混沌工程。
假设我们要从头基于 K8s 来搭建一个 Chaos 测试平台，能让用户在这上面跑各种这样的应用，然后我们对其进行混沌实验 - 包括通过 metrics 定义稳态，错误注入，观察状态变化这些。那么我们可能会面临如下几个问题：
- 如何对应用进行错误注入？我们是一个通用的测试平台，不可能知道具体跑在上面的应用，所以应用对我们是黑盒，我们不可能对每种应用都写一套对应的错误注入。
- 如何对应用进行观测？我们不可能对每个应用分别列出来可观测的指标。
- 应用现在是跑在 Docker 环境里面的，Docker 可以认为是一个隔离的环境，所以我们如何在 Docker 外面对这个应用进行观察和错误注入？
对于上面的第一点，我们不知道具体的应用，但我们知道这些应用如何跟更下层的操作系统交互的，也就是 system call，譬如如果我们要从硬盘读写数据，就会去调用 write，read 这些系统函数，那么如果我们能给 system call 进行错误注入，就自然就是对应用进行干扰了。
而对于第二个问题，因为是 docker 环境，所以通用的 CPU，mem，I/O 这些指标是能获取的得到的，另外也可以知道 system call 的调用情况（譬如调用最多的系统调用是什么）。虽然我们不关心具体的应用，但一些通用的应用，譬如走 HTTP 协议的，那么我们还是能通过监控 HTTP status code 来对系统进行监控的。
最后来说说如何对 docker 里面的应用进行观察和错误注入，这个其实也是比较简单的，docker 原生提供了支持，通过 share namespace 的方式，就可以方便的去操作 docker 里面的应用。对于 system call，我们可以通过 strace 来对 system call 进行错误注入，譬如 strace -e inject=open:error=EACCES -p pid，也可以直接统计 system call 的调用次数。我们可以通过 docker run --pid=container:hello_world --cap-add sys_ptrace -it ubuntu strace -p <pid> 来 strace docker 里面运行的某个应用。我们也可以运行 docker run --network=container:3460fd797b2d -it <image> 来抓网络包，解析 HTTP status code。
上面就是这篇 paper 提到的工具 ChaosOrca 的做法，它的主要架构如下：
它主要包括几个组件：
- Monitor：主要用来监控系统，对于 system call，会记录该 call 的类型，参数以及返回值。
- Perturbator：主要用来动态对系统进行干扰，任何干扰使用一个 tuple
(s, e, d)来定义，其中 s 是 system call 的类型，e 是要注入的 error code，d 则是要执行该 system call 之前，delay 的时间。 - Orchestrator：根据用户定义策略实际来编排 Perturbator 的执行。
- Visualization：可视化，数据都会存到 Prometheus 进行展示
可以看到 ChaosOrca 的架构还是比较简单的，对我们来说，如果要在 K8s 上面做一个 Chaos framework，其实也是类似的方式，后面拼的可能就是提供更强大的错误注入方式，以及能更好的分析出是否系统出现问题，当然还有提供更好的可用性支持吧。
