Log Analysis
| Architecture | Normal Log Flow |
|---|---|
 |
 |
| 故障 | Log Flow |
|---|---|
| Cart服务被关闭 |  |
| Catelogue服务被关闭 |  |
| User服务被关闭 |  |
| Payment服务被关闭 |  |
| Order服务被关闭 |  |
- 关闭Cart之后，font-end将无法得到cart的信息，具体日志如下：
- 关闭Cart-db，Cart将无法获取cart信息，也无法存储新的信息，其具体日志如下：
- 上图为删除cart-db之后，系统font-end的日志状态。可以看到，即使可以连到cart接口，也不存在任何的返回数据。
上图更清晰的看到，cart在连接它的数据库时，发错的连接数据库报错信息。
- Catalogue服务主要较为独立，主要的功能就是获取目录信息，所以它的故障的主要来源在于Catalogue数据库。当删除Catalogue-db后，日志的状态如下：
上述的日志，展现出catalogue-db被删除后，catalogue的get方法无法获取到任何数据信息。
- 如果font-end被关闭，那么就失去了order和cart的post方法，这两个服务将没有任何反应，相应的，payment也就不会有任何动作，整个系统处于无响应状态。
这是font-end被关闭后，cart服务的日志报错，在报错中可以看到，cart出现网络层错误，无法获取正常的命令。
- 整个系统的订单服务被关闭后，系统不产生订单，也就不会产生后续的支付等操作，所以order服务的失效，会导致一系列的连锁反应。
上图可见，font-end中无法order服务发送请求 ，同时，其余的服务，如cart，address也一同没有任何回应。
对于orders，也会产生500错误。
order服务被关闭后，shipping的日志报java.Exception错误，产生程序错误。
同时产生的报错，表示shipping服务的连接断开，通道发生错误。
RabbitMQ的服务依赖于shipping的服务，所以，当shipping服务连接错误后，Rabbitmq也会产生连接错误。具体情况如下：
关闭payment服务对于其他服务并没有产生在日志中的报错，因为从服务的依赖关系来看，并没有其他的服务依赖于payment服务。
queue-master服务同上
- 关闭user服务，则整个系统将产生错误。因为在Sock-shop系统中，下订单，加入购物车等动作行为，都依赖于存在用户id，当不存在用户时，则这些服务会由于无法获取id值而报错。具体日志如下：
上面的日志说明order所需要的某一个service失效无法获取，即被关闭的user服务。
payment服务的日志是每次付款行为都有一次记录，当user的服务短暂失效时，payment返回结果“false”表示本次付款操作失败。
对Kubernetes集群中的某一节点注入CPU负载后，集群中各个Pod的日志表现出不同的报错情况。具体分析如下：
- 可以看到，日志输出明确表示，由于超时无法创建订单，并且没有任何信息返回
- 在cpu负载的情况下，无法形成order订单，所以最终在日志中输出了创建订单超时失败的错误。
- 在付款服务的日志中，由于order服务，payment服务等的失效，所以在使用cpu负载的节点的时候，付款也失败，返回false。
- 由于order服务错误，依赖于order服务的shipping服务产生错误
- 由于cpu的负载，user服务无法正常产生，获取ID，所以产生上述错误
- 在user服务出错后，session服务日志显示没有任何信息产生。
在对磁盘注入了高“读操作”之后，系统由于无法抢占读写空间而产生错误。具体的日志情况如下：
- 由于节点主机磁盘正处在高负载状态，order服务无法获取对磁盘的操作权利，所以产生了超时错误，产生订单失败。
- 原因同上，由于磁盘不足，付款行为无法成功，最终返回false。
在对集群内一个节点注入一个高内存后，会使得系统内的一些服务产生内存不足的错误，具体的日志信息如下：
- 上图中java堆溢出，程序异常。
- 上同，程序抛出堆不足异常。
最后，本项目可以断掉主机的网络服务。在对集群的某一主机进行网络攻击，停掉主机的网络服务后，系统各个服务产生的日志错误如下：
- 在停止了网络服务后，font-end无法再连接到order服务，于是几次请求尝试返回都为 500，并且无法获取任何返回信息。
- 失去网络服务后，order服务由于长期 得不到任何额响应报超时错误。
- 和前面的多次不同的故障注入不同的是，在某一个节点的网络服务后，payment返回false的频率明显增大，因为只要服务使用了该节点的主机运行，则必然会失败。
- 在网络被切断的状态下，user服务同样无法成功运行，从而无法为系统提供一个id供给后续操作的使用。
在对每一个Pod形成的日志进行分析后，我们总结出了Sock-shop微服务架构系统中的每个服务之间相互的依赖关系。最后的总结，即本文档上方的服务依赖架构图 。
本项目分别从硬件层面（CPU，memory，disk， network）和应用从面（Pod）进行故障注入。从上述的日志分析中可以看出，在硬件层面的故障注入产生的结果多表现为“超时”，“请求失败”， “返回false”等，实际较难反向分辨故障产生的原因。但是，我们可以使用故障注入工具，为系统进一步开发容错机制，或者对现有的机制进行评估，这有利于系统的安全性，可靠性。
对于应用层面的故障注入，即删除Pod或者整个Service，所产生的日志错误展现出更多的信息。具体如上述日志分析，在 删除不同的Pod之后，受影响的日志往往能够表现出故障的原因甚至故障的来源。对于这样的日志， 进一步的总结 归纳，有利于我们通过服务报错及时找到发生故障的原因。同时，由于一个服务的错误总是由另一个引起的，甚至我们能够通过日志推断出整个系统的服务架构，进而评估该系统的编排是够合理，服务之间是否可以进一步解耦以及该微服务架构是否拥有较为完善的容错机制。
这些都有待进一步的研究。