# Hi-RCA: A Hierarchy Anomaly Diagnosis Framework Based on Causality and Correlation Analysis
## 2 Related Work
To capture the causality, several causal inference methods are used. Refs. [5; 6] exploit the PC algorithm [29] to build a causality graph while considering the service availability and resource consumption. Ref. [30] uses two causal inference models to derive a metric causality graph, where the DirectLiNGAM method [31] is adopted to model the causality between resource metrics and the Granger causality test [32] is used to infer the causality between resource and service metrics. MicroCause [33] applies a variant of the PC algorithm to capture the time order of metrics to metrics to construct the causality among metrics. [PERSON] et al. [34] propose a root cause analysis method based on a knowledge graph and a causal search algorithm. Furthermore, they describe how to construct a knowledge graph and improve the PC algorithm. [PERSON] et al. [35] propose an automatic diagnosis system based on a causality graph and supervised learning, which require no expert knowledge and implementation details. Based on the causality graph, different root cause determination methods are proposed, and one of the common methods is the random walking algorithm. Refs. [4; 5; 6] perform a random walk to pinpoint the possible root cause. The random walk starts from the application frontend and makes a fixed number of iterations. At each iteration, the probability of visiting a service in the neighborhood is proportional to the correlation of its KPIs with those of the application frontend. The root cause is located based on the visiting time of services, under the assumption that most visited services constitute the most probable root causes for the anomaly. MS-Rank [5] proposes a hybrid influence graph construction algorithm and introduces a new metric concept, which uses multiple types of metrics to discover the causal relationship between microservices. FacGraph [28] searches for anomaly propagation subgraphs in the obtained causality graphs, each subgraph having a tree-like structure, and the tree root is the frontend. Subgraphs' anomaly scores are based on the appearance frequency in the causality graphs. With a threshold mechanism, root causes are returned as a set of leave services of the kept subgraphs. ServiceRank [36] uses a second-order random walk to identify the root causes. Loud [8] uses the causality graph of KPI metrics from the anomaly detection system directly and locates the faulty components using different graph centrality algorithms. CausalInfer [37] uses the depth-first search method to traverse the metric causal dependency graph of each microservice to obtain the cause of the failure. In different causality formulations, some researchers build dependent graphs from the correlation analysis. MonitorRank [38] uses the historical and current time series metrics, considering internal and external factors. It proposes a pseudo-anomaly clustering algorithm to classify external factors and identifies anomalous services with a random walk algorithm. MicroHECL [39] analyzes possible anomaly propagation chains and ranks candidate root causes. FluxInfer [40] constructs a weighted undirected dependency graph to represent the dependency relationships of anomalous KPIs, then applies a weighted PageRank algorithm to localize root cause-related KPIs. However, since a microservice system consists of diverse microservices with a large amount of monitoring metrics, it is hard to capture the accurate dependency based on the microservices' invocation relationship and deployment relationship. Furthermore, the dependency graph is not equivalent to the anomaly propagation graph. Hence, under diverse anomaly types with different propagation situations, it is challenging to pinpoint the root cause based on a static graph. For causality models, sufficient anomaly data volume is required, but unfortunately, due to the actual situation, it is hard to collect enough anomaly data to satisfy the requirements. Some methods require independent tests for all gathered metrics, which may cause a significant overhead.