## 3 Problem Description and Proposed Solution
### Method of the Proposed Approach
#### 3.2.3 Optimized PC Algorithm Based on Knowledge Graph
Prometheus ([[https://prometheus.io](https://prometheus.io)]([https://prometheus.io](https://prometheus.io))) was used to collect the KPIs of microservices such as response time and throughput, Heapster ([[https://github.com/kubernetes-retired/heapster](https://github.com/kubernetes-retired/heapster)]([https://github.com/kubernetes-retired/heapster](https://github.com/kubernetes-retired/heapster))) was used to collect KPI data related to containers, and then Zabbix ([[https://www.zabbix.com](https://www.zabbix.com)]([https://www.zabbix.com](https://www.zabbix.com))) was used to collect server-related KPI data. ### Building an O&M Knowledge Graph of the MSA System in the Kubernetes Environment

On the basis of the above deployment architecture, the knowledge graph was constructed as shown in Figure 5.1 The Sock Shop application was deployed in the Kubernetes cloud environment,

Figure 5.2 Deployment architecture of the whole experiment environment. Figure 5.3 Sock Shop architecture. which is commonly used in microservice architectures. In Kubernetes, Service was the core of the distributed cluster architecture. Pod was used for isolating the process that provides services for the service. It was the smallest unit on the nodes in Kubernetes, each service process was wrapped into the corresponding Pod, and a container was running in a Pod. The relation between Service and Pod in Kubernetes was implemented by Label and Label Selector. In terms of cluster management, Kubernetes divided the cluster into a master node and a group of worker nodes. Thus, the O&M knowledge graph contained at least the following subjects: Cloud Environment, Master Node, Node, Service, Pod, and Container. Their relations could be defined as follows: \begin{tabular}{c c c c} \(\bullet\) & _Environment_ & _has_ & _Node_ \\ \(\bullet\) & _MasterNode_ & _manage_ & _Node_ \\ \(\bullet\) & _Pod_ & _deployed_in_ & _Node_ \\ \(\bullet\) & _Pod_ & _contain_ & _Container_ \\ \(\bullet\) & _Pod_ & _provide_ & _Service_ \\ \(\bullet\) & _Service1_ & _call_ & _Service2_ \\ \(\bullet\) & _Service/Pod/Node_ & _ns_ & _Namespace_ \\ \(\bullet\) & _Service/Pod/Node_ & _profile_ & _KPIs_ \\ \end{tabular} 

### Simulation Experiment and Analysis

In this section, we tested our method from mainly two aspects: first, the executable of the causal search algorithm was tested, and then the effectiveness of the causal search algorithm was tested. In the first part, we used an example of CPU fault injection to test whether the cause and effect path output by the causal search algorithm contains the reason we expect. In the second part, to test the causal discovery performance of the proposed method, we further injected faults into several services and finally tested the performance with two metrics: precision and recall values. #### 4.3.1 Testing for Causality Search

In the experiment, we used chaos experimental tools to inject CPU fault injection attacks into the target environment, and set the duration of the injection to 30 min. Using fault injection, we used CPU utilization fault injection scripts on the front-end service containers. At the same time, the data of resource KPIs in the environment were collected, and the specific performance indicators were collected as shown in Table 1.