A Goal-Driven Survey on Root Cause Analysis

TL;DR

This paper reframes Root Cause Analysis (RCA) for cloud microservices through a goal-driven lens, arguing that traditional data-centric taxonomies obscure the true objectives of RCA tasks. It formalizes ideal RCA as a mapping $\mathcal{F}: \mathcal{O} \rightarrow \mathcal{G}$ to produce a complete incident propagation graph, and defines seven orthogonal goals that span data fusion, robustness, adaptive learning, real-time performance, interpretability, multi-granularity, and actionability. Through a systematic review of 135 papers (2014–2025), the authors show that current work largely targets subset outputs (e.g., root-cause points) rather than full propagation graphs, revealing gaps in evaluation, data availability, and modeling approaches. They categorize approaches across seven goals, highlight trends such as the rise of LLM-based semantic fusion and few-shot generalization, and discuss benchmarks, datasets, and tools while identifying gaps toward graph-building RCA and end-to-end remediation workflows. The work concludes with a forward-looking agenda: next-generation benchmarks with ground-truth graphs, unified causal-graph Generative models, and deeper integration of RCA into the software engineering lifecycle, aiming to transform RCA from a reactive diagnostic task into a proactive reliability driver.

Abstract

Root Cause Analysis (RCA) is a crucial aspect of incident management in large-scale cloud services. While the term root cause analysis or RCA has been widely used, different studies formulate the task differently. This is because the term "RCA" implicitly covers tasks with distinct underlying goals. For instance, the goal of localizing a faulty service for rapid triage is fundamentally different from identifying a specific functional bug for a definitive fix. However, previous surveys have largely overlooked these goal-based distinctions, conventionally categorizing papers by input data types (e.g., metric-based vs. trace-based methods). This leads to the grouping of works with disparate objectives, thereby obscuring the true progress and gaps in the field. Meanwhile, the typical audience of an RCA survey is either laymen who want to know the goals and big picture of the task or RCA researchers who want to figure out past research under the same task formulation. Thus, an RCA survey that organizes the related papers according to their goals is in high demand. To this end, this paper presents a goal-driven framework that effectively categorizes and integrates 135 papers on RCA in the context of cloud incident management based on their diverse goals, spanning the period from 2014 to 2025. In addition to the goal-driven categorization, it discusses the ultimate goal of all RCA papers as an umbrella covering different RCA formulations. Moreover, the paper discusses open challenges and future directions in RCA.

Figures (8)

• Figure 1: The structure of this survey. We first introduce the background, our formal framework, and survey methodology (§\ref{['sec:background']}-§\ref{['sec:surveymethod']}). Then, we systematically analyze RCA research through the lens of a seven-goal taxonomy (§\ref{['sec:multidimension']}-§\ref{['sec:goal7_actionability']}). Finally, we discuss research trends, future opportunities, and related work before concluding (§\ref{['sec:trend']}-§\ref{['sec:conclusion']}).
• Figure 2: Procedure of incident management. Starting from incident preparation, which involves techniques like software testing, canary releases, and disaster recovery simulations to closely mimic real-world conditions and prepare for potential issues. Once the product is deployed, it enters the incident detection stage, where monitoring systems, anomaly detection, and customer reports are used to identify any abnormalities in runtime services. If an issue arises, the process moves to the incident localization phase. Here, SREs work to quickly determine which service is the root cause and further pinpoint the specific underlying issues, including analyzing the log, metric, trace, etc. To halt the failure's propagation, the next step is incident mitigation, where common actions might include downgrading the service or rolling back to a previous code version, depending on the identified root cause. Following mitigation, the focus shifts to incident resolution. During this phase, SREs and developers collaborate to resolve the incident completely. Once the system is fully restored, the final phase is a incident improvement (postmortem review), which involves analyzing the incident to extract lessons learned and implementing measures to prevent future occurrences.
• Figure 3: Overview of Root Cause Analysis. The observation space includes monitoring units as its basic building blocks. Each unit contains static files (such as configuration and code) and the runtime resources (for example, CPU, memory, and network) needed to transform these static programs into processes that interact with other services. Additionally, there is telemetry data that describes the runtime behavior of these processes, as well as the operations and global configurations maintained during maintenance. The inference component comprises various implemented methods alongside their corresponding evaluation metrics; its practical application is critically constrained by efficiency requirements ( e.g., real-time performance). Finally, the output identifies the incident's root causes and illustrates how the root cause propagates to the observed symptoms. This includes an incident propagation graph composed of an incident propagation chain. Each chain contains the root cause, trigger (optional), and result nodes.
• Figure 4: An Out-of-Memory (OOM) incident propagation chain. The OOM event in Service#2 is the observed symptom. The root cause is the code change within Service#2. The trigger is the increased traffic volume, which activates the latent flaw. Mitigating the trigger ( e.g., traffic reduction) provides a temporary fix, while resolving the root cause ( e.g., fixing the code) offers a permanent solution.
• Figure 5: The number of collected papers published per year in top-tier venues, distinguishing between those with and without company collaboration.

Theorems & Definitions (6)

• definition 1: Input Space
• definition 2: Output Space
• definition 3: Root Cause Event Node
• definition 4: Trigger Event Node
• definition 5: Symptom Event Node
• definition 6: Intermediate Event Node