# Hi-RCA: A Hierarchy Anomaly Diagnosis Framework Based on Causality and Correlation Analysis
## 2 Related Work  
Compared to logs and traces, metric data can manifest abnormality in the system and require no instrumentation to the source code. Many approaches in the literature employ observational metrics to infer the root causes of performance issues. We classify the related work based on metric data into two types: non-causal methods and causality-based approaches. Non-causal methods can be classified into unsupervised models and supervised machine learning-based approaches. For unsupervised methods, it is common to train a baseline model based on normal data, and detect anomalies when KPIs diverge from the baseline model [8; 9; 10; 11]. To distinguish the normal fluctuations and anomalous situations, CoFlux [12] determines whether two KPIs are correlated by fluctuations automatically, considering the temporal order and fluctuating direction. [PERSON] et al. [13] analyze time series anomalies based on correlation analysis and the Hidden Markov Model (HMM [14]) which is used to find close relationships between abnormal KPIs. \(\varepsilon\)-diagnosis [15] infers the possible root causes based on the similarity computation of monitored samples; KPIsare anomalous if the similarity is below a given tolerance threshold. Based on Robust Principal Component Analysis (RPCA [16]), CloudDiag [17] identifies the services that most contributed to the anomaly. Root causes are ranked based on the number of times they appeared in anomalous categories. PAL [18] and FChain [19] exploit offline detection of anomalous KPIs to generate a ranked list. To reduce false positives, they filter external reasons by checking whether anomalies affected all application services. The earliest anomalies are indeed considered the most probable root causes. For supervised methods, labeled anomaly data are required. [PERSON] et al. [20] utilize a variational autoencoder [21] to model normal behavior and recognize anomalies based on reconstruction error. They also train a convolutional neural network [22] on the anomalous traces, to recognize which failures caused a performance anomaly in a service. [PERSON] [23] trained deep learning algorithms on massive amounts of data to identify root causes, but its performance may degrade with system updates. [PERSON] proposed Arvalus and its improved algorithm D-Arvalus [24]. In the two algorithms, the system components are regarded as microservices, and the dependencies between components are regarded as connections, to identify the root cause in a graph. Sage [25] leverages unsupervised learning to identify causes of performance degradation in complex microservice dependency graphs. It examines the impact of microservices on end-to-end performance based on microservice dependency graphs via graph variational autoencoders. GDN [26] detects anomalies based on multivariate time series. It uses an implicit embedding feature construction to learn the relationship between monitored objects, uses a graph attention-based method to predict the metric values, and anomalies are detected based on the comparison of the results between real values and the predicted values. UBL [27] leverages self-organizing maps to capture emergent system behaviors and predict unknown anomalies for cloud infrastructures. Machine learning-based models provide meaningful perspectives for root cause location. However, the limitations come from two aspects. The first is labeled data limitation; in the actual situation, it is hard to obtain sufficient anomaly cases for model training. The second is interpretability, which is vital for the result of root cause location. Hence, engineers need to understand the mechanism behind how the root cause is located; otherwise, the outcome may not be trusted. For causation-based analysis, one of the dominant methods for anomaly diagnosis is to derive an automatic causality graph [5; 6; 7; 28], then determine the root cause based on the graph-based analysis. In these causality graphs, vertices are typically modeled as the services, and oriented arcs indicate the microservices' dependency.