CARE: Context Aware Root Cause Identification Using Distributed Traces and Profiling Metrics

1 CARE: Context Aware Root Cause Identification Using Distributed Traces and Profiling Metrics Mahsa Panahandeh, Naser Ezzati Jivan, Abdelwahab Hamou-Lhadj, James Miller Abstract—Root cause localization in microservices is challenging due to intricate service dependencies and the high volume and heterogeneity of collected monitoring data, which add complexity to the analysis. Conventional methods often overlook nuanced propagation patterns and contextual interactions among services, and they are limited in leveraging multi-source observability data for comprehensive root cause identification. This study introduces CARE, a context-aware, spectrum-analysis-based approach that integrates multi-source observability data and employs network analysis to prioritize the contextual significance of components in propagating anomalies across individual services, service communities, and requests. CARE’s weighted spectrum analysis leverages these prioritized contexts to pinpoint underlying performance issues. Evaluations on 224 cases from the TrainTicket benchmark and a real-world Internet service provider’s production system demonstrate CARE’s substantial accuracy gains, with top-1 accuracy of 72%-89% and top-5 accuracy of 84%-99% for single root causes, outperforming baselines by 8%-41%. CARE also shows significant improvements in dual root cause identification, exceeding baseline performance by 18%-37%, all while maintaining efficient resource usage, establishing CARE as a robust and resource-effective solution for root cause localization in complex microservice environments. Index Terms—Distributed traces, Network analysis, Spectrum analysis, Root case analysis, AIOps. I. INTRODUCTION MICROSERVICE-based systems are known for their scalability, modularity, and rapid deployment capabilities. However, their highly dynamic nature, coupled with frequent maintenance updates, makes them prone to failures and crashes in production [1], which has been shown to negatively impact productivity and cost [2]. Numerous studies have shown that even small performance anomalies can result in disproportionately large impacts [3]–[5]. For instance, Ahmad et al. [6] empirically demonstrated that injecting latency anomalies of up to 15,000 ms into cloud native microservices led to throughput reductions ranging from 23% to 87%. Under high concurrency levels (e.g., 1,200 users), these anomalies also caused service-level failures that affected 2-4% of users. Such performance degradations directly affect service availability and user satisfaction, with cascading effects on business continuity and revenue [6], [7]. As a result, timely and accurate detection of performance anomalies, followed by effective root cause analysis, is essential to maintain system resilience, reduce mean recovery time, and ensure service level objectives (SLOs) in production [4], [7], [8]. However, identifying anomalies and their root causes in microservice-based systems remains highly challenging. Studies report that service-level failures account for more than 22% This is the author’s accepted manuscript of a paper accepted for publication in IEEE Transactions on Software Engineering. The final published version will be available at https://doi.org/10.1109/TSE.2025.3645143. M. Panahandeh and J. Miller are with the Department of Electrical and Computer Engineering, University of Alberta, Edmonton, Canada. N. Ezzati Jivan is with the Department of Computer Science, Brock University, St. Catharines, Canada. A. Hamou-Lhadj is with the Department of Electrical and Computer Engineering, Concordia University, Montreal, Canada. of operational effort, making them one of the most resourceintensive types of problems to diagnose and resolve [9]. This complexity stems from the fact that a single-user request typically spans numerous loosely coupled services. The sheer volume of observability data generated in such environments renders manual diagnosis infeasible [10]. Even automated root cause identification approaches face significant challenges due to the ephemeral nature of services and the complexity of interservice communication patterns. Mechanisms such as asynchronous messaging, dynamic load balancing, and distributed consistency can obscure anomaly signals, making it difficult to accurately trace the origin of performance degradations [4]. This difficulty is widely recognized in the literature as a critical and still-open challenge in the domain of microservice-based systems. Many studies emphasize that understanding and tracking the propagation of anomalies across complex service interactions is essential yet nontrivial, due to the distributed, asynchronous, and often dynamic nature of modern architectures [4], [11]–[13]. In this paper, our aim is to address this gap by developing a context-aware multi-source method that detects the root causes of propagating anomalies. Consequently, understanding how anomalies traverse structural dependencies is the cornerstone of effective diagnosis. When a performance issue occurs, it rarely remains isolated but instead propagates through the dependent services. A performance issue in a single service can have a cascading effect on all services dependent on it. Alternatively, poor performance in a particular service might actually be rooted in another service it depends upon. Without understanding these structural interconnected dependencies, diagnosing issues becomes a complicated process. In the worst cases, the actual root cause may be entirely overlooked. Therefore, accurate diagnosis requires an understanding of service interactions and dependencies. This necessitates an in-depth study of structural dependencies, particularly in cases of forward or backward anomaly propagation where the starting point of an issue might be several services away from where it eventually manifests. Traditional troubleshooting methods for microservice systems predominantly focus on adjacent service calls [14], [15] or unidirectional propagation patterns [16]–[18], often neglecting the intricate interdependencies and broader contexts that are critical for accurately diagnosing faults. Although recent research has incorporated more sophisticated propagation patterns by considering service architecture and dependencies in root cause localization [2], [19]– [23], these approaches remain constrained in their ability to integrate and analyze multi-source observability data such as logs, traces, and profiling metrics. This limitation hinders a comprehensive understanding of complex fault propagation in microservices, ultimately affecting the effectiveness of root cause localization. Moreover, these methods are generally designed to address single root cause scenarios and may fall short in complex cases involving multiple root causes, where fault propagation paths can overlap or diverge. Additionally, many of these approaches are supervised, relying on labelled data to train models [20], [21], [24], which is impractical in real-world environments due to the sheer number of potential failure types and propagation paths. Studies on root cause analysis in microservice systems can generally 2 be categorized into two main categories. The first category encompasses studies that rely solely on execution traces to understand the propagation patterns between services in order to locate the root cause of faults and anomalies [2], [18], [23], [25], [26]. Our previous work [23] falls into this category, where we introduced a weighted spectrum analysis combined with social network analysis concepts like PageRank and community detection to locate root causes based solely on collected traces. While this approach advanced root cause localization by highlighting significant diagnostic contexts, it is limited by its reliance on collected trace data alone, which does not capture all aspects of service behaviour during anomalies, such as performance metrics that could provide additional insights into root cause analysis. The second category of studies relies on changes in profiling metrics (also known as key performance indicators (KPIs)) of individual services for finding the root cause [19], [20], [22]. However, each approach often overlooks critical insights offered by the other, limiting their ability to fully capture the complexity of fault propagation in microservices, especially in complex scenarios involving multiple root causes. Recently, Lee et al. [24] introduced an end-to-end troubleshooting framework that integrates multiple sources of observability data, such as logs, KPIs, and traces. Using machine learning, their approach models historical service interdependencies and propagation patterns through a graph attention network (GAT). A supervised binary classifier is then trained to detect anomalies in real-time and rank services by their likelihood of being the root cause. However, this approach has several limitations. First, it is fully supervised, requiring comprehensive coverage of all potential fault types, which reduces its practicality in real-world scenarios [2], [27]. Second, the learned dependency patterns in the GAT model function like a black box, limiting their utility for further analysis tasks, such as identifying critical paths during troubleshooting. Third, while the framework identifies expected service behavior based on historical data, it overlooks dynamic service behaviour during anomalies, a technique that several studies have shown [2], [26] to be effective in improving root cause localization. Dynamic service behavior refers to the real-time execution characteristics of services during anomaly periods, including the execution coverage (i.e., which services are invoked and how frequently), and the execution status of each service (e.g., success, failure, or degraded performance) as observed during both normal and abnormal executions that occur within the anomaly window. Capturing these patterns in real time can provide more accurate contextual signals to diagnose fault propagation and identify root causes. To address these limitations, we propose CARE (Context-Aware Root-cause idEntification), a novel approach for root cause analysis in microservice-based systems that integrates multi-source observability data, including distributed traces and profiling metrics. CARE uses unsupervised techniques to highlight critical contexts in anomaly propagation by studying both normal and abnormal data during anomalous events. The process begins by constructing two annotated service call graphs (SCGs), representing the normal and anomalous behaviour of the system in the presence of an anomaly. Within each graph, CARE evaluates three distinct contexts: individual services, service communities, and execution paths (derived from execution traces). First, CARE uses community clustering algorithms on the SCGs to identify critical interrelated services, capturing how behaviours propagate across services in both forward and backward directions. Second, a PageRank-based algorithm is used to prioritize services based on their propagation behaviour within the SCG, while also taking into account the importance of the community to which they belong. Third, execution traces are analyzed at the time of an anomaly to evaluate their role in propagating abnormal behaviour. Finally, given the significance of these three contexts, a weighted spectrum analysis is introduced to isolate frequent patterns of anomalous behaviour, ultimately ranking services by their likelihood of being the root cause. We conducted an extensive study to evaluate CARE using popular and comprehensive open-source microservice benchmarks from the literature [1], [2], including Train-Ticket [28], as well as a production microservice system from an Internet service provider [29]. The experimental results on 224 scenarios of two benchmarks show that CARE ranks the root-cause microservices at top-1 in 72%-89% of cases and its top-5 accuracy is 84%-99% for different experiments in single root-cause detection, significantly outperforming similar baselines at the top-1 accuracy by 29-41% for TrainTicket and by 8-12% for the the second benchmark. Additionally, our approach’s accuracy in identifying both root causes for scenarios with double root causes at top-2 is 55%, which is a 37% improvement compared to the baselines, and it goes up to 82% at top-5, which is 18% better than the baselines at top-5. Building upon our previous work [23], this paper introduces several significant enhancements: I) In the current paper, we use profiling metrics alongside distributed traces to model system behaviour at the time of an anomaly, whereas the previous paper was limited to studying different contexts based solely on traces. II) In the current paper, we introduce weighted service call graphs, which emphasizes the impact of anomalies on service invocations. III) In this paper, we expand our study to explore various community detection algorithms, going beyond the network analysis algorithms used in previous work. This includes approaches like Graph Neural Networks and adapted heuristic algorithms. IV) This paper also includes more extensive experiments and discussions on the methods and lessons learned compared to our previous work. By addressing the limitations of existing approaches, CARE represents a significant step forward in root cause analysis for microservice-based systems, offering both practical applicability and enhanced diagnostic capabilities. The main contributions of the current paper are as follows: •Exploiting both distributed traces and profiling metrics to study the significance of different contexts in behaviour propagation. •Employing social network analysis to analyze the structural interdependence of services, communities, and execution paths for forward and backward anomaly propagation and root cause identification. •Proposing an enhanced weighted spectrum analysis. While existing methods often rely on individual services and isolated executions, our approach introduces contextual layers, encompassing individual services, service communities, and execution paths into root cause analysis. II. BACKGROUND AND MOTIVATION EXAMPLE Spectrum-based Fault Localization (SBFL) with Distributed Traces: Distributed tracing is a relatively new tracing method aimed at providing observability in microservices. A distributed trace, or simply a trace, is identified by a unique trace ID and represents an end-to-end request across multiple service instances. It comprises tagged time intervals (spans) with caller-callee relationships and may include metadata like logs or tags for additional context [30]. As traces capture execution paths and classify requests as normal or abnormal, some studies propose their use as test cases in adapted software testing techniques, such as spectrum-based fault localization (SBFL), to pinpoint abnormal components in microservice systems [25], [26]. SBFL is a widely used debugging technique known for its lightweight nature and effectiveness [25], [26], [31]–[33]. A spectrum represents test coverage data collected from executed test cases, offering a dynamic view of component behaviour. During test execution, the data is gathered to indicate whether each component was executed and whether the test passed or failed. 3 TABLE I: Comparison of ranked list of candidates across Regular spectrum analysis, MicroRank, and CARE Methods Regular MicroRank CARE Services Score Services Score Services Score ts-train-service 0.9432 ts-travel-service 0.9573 ts-price-service 0.6801 ts-travel-service 0.9432 ts-train-service 0.9572 ts-train-service 0.5823 ts-route-service 0.9147 ts-route-service 0.9419 ts-basic-service 0.5745 ts-ticketinfo-service 0.9133 ts-ticketinfo-service 0.9278 ts-station-service 0.5650 ts-station-service 0.8824 ts-station-service 0.8973 ts-ticketinfo-service 0.5601 ts-basic-service 0.8666 ts-basic-service 0.8817 ts-route-service 0.5459 ts-price-service 0.7817 ts-price-service 0.7817 ts-travel-plan-service 0.4538 ts-route-plan-service 0.7638 ts-route-plan-service 0.7638 ts-route-plan-service 0.4410 ts-travel-plan-service 0.7454 ts-travel-plan-service 0.7454 ts-travel-service 0.3501 istio-ingressgateway 0.2221 istio-ingressgateway 0.3386 istio-ingressgateway 0.1022 ts-verification-code-service 0.0000 ts-verification-code-service 0.0000 ts-verification-code-service 0.0216 ts-auth-service 0.0000 ts-auth-service 0.0000 ts-auth-service 0.0023 For each component, four spectrum categories are defined: < Oef , Onf , Oep, Onp >, where the subscript specifies whether the component was executed (e) or not (n) and whether the test passed (p) or failed (f) [32]. Based on these spectrums, metrics such as Ochiai compute a suspiciousness score, indicating the likelihood of a component being faulty. Studies [2], [26] show that service instances handling a higher proportion of anomalous requests compared to normal ones are more likely to be faulty. Spectrum analysis with traces leverages this relationship to identify root causes. SBFL statistics with traces for a service can be defined by counting the number of abnormal and normal traces in the current time window that either cover or do not cover the service [10], [26]. These statistics are formulated as follows, where AN refers to the abnormal traces, N to the normal traces, and si∈Tmeans that trace T covers service si; the vertical-bar notation |.|denotes the number of traces satisfying the condition. Oef (si) = |T∈AN :si∈T|, Oep(si) = |T∈N:si∈T| Onf (si) = |T∈AN :si/∈T|, Onp(si) = |T∈N:si/∈T| (1) In this paper, we propose an adapted spectrum analysis technique for identifying root causes in distributed traces. Anomaly Severity: As an anomaly propagates through services, it may not necessarily impact all profiling metrics collected from service invocations and a sudden change in a metric’s value could be an irrelevant anomaly [1], [2]. Li et al. [2] suggest using anomaly severity to differentiate between an anomaly and noises in services performance. Anomaly severity qualifies the expected deviation of a metric from its normal distribution to identify metrics affected by an anomaly. Profiling metrics affected by an anomaly within a time window are those showing a significant change compared to their values for the same service invocation type in historical data. Anomaly severity of a profiling metric,α, for a single service invocation of S1→S2is defined as α=|metric−µmetric| σmetric , where µmetric and σmetric represent the mean and standard deviation of metric in historical data for S1→S2, and metric is the observed value of metric for the specific service invocation of S1→S2 within the sliding time window. The anomaly severity of a profiling metric associated with a service invocation is calculated as the average of anomaly severity values of that metric across all observed service invocations of the same type. We refer to this average anomaly severity computed from historical data as αreference. Similarly, αempirical is defined as an average of anomaly severity of a profiling metric from its respective mean values within a sliding time window. For an affected profiling metric of a specific service invocation, αempirical surpasses αreference, since more abnormal service invocations with respect to that profiling metric are expected to be observed within the sliding time window [2]. An affected profiling metric by an anomaly is identified as follows: αempirical −αreference > th1×αreference (2) A service invocation is considered abnormal with respect to each of its affected profiling metrics if the anomaly severity with respect to that profiling metric exceeds a certain threshold. In other words, |metric−µmetric| σmetric > th2, where µmetric and σmetric are calculated within a sliding time window. The thresholds th1and th2are selected based on a sensitivity analysis experiment [34], in which the F1-score of anomaly detection was measured across a range of threshold values to evaluate their impact on the performance of the target task, i.e., anomaly detection, tailored to the dataset. Li et al. [2] showed that the most robust and stable F1-score for anomaly detection on the same dataset used in our CARE evaluation is achieved when th1= 0.1 and th2= 1. Therefore, in this paper, we adopt the same threshold values suggested by Li et al. [2], i.e., th1= 0.1and th2= 1. Motivational Discussion: Applying spectrum-based methods to distributed traces has limitations in root cause localization. Unlike test cases, which are designed to cover components and execution paths evenly, traces may involve certain services or request types more frequently due to user behaviour. In Table I, the first compartment shows the results of applying regular spectrum analysis to successful and failed traces with an anomaly injected into the ’ts-priceservice’ from the TrainTicket benchmark [28]. This table presents the ranked list of candidates, including services ranked by their suspiciousness score. As shown, the regular spectrum analysis ranks the true root cause, ’ts-price-service’, in the seventh position. Our experiments reveal that, in addition to lower accuracy, a common issue with regular spectrum analysis is its inability to differentiate services’ suspiciousness scores. In many cases, multiple services are ranked similarly, complicating the decision on which service to prioritize for root cause analysis. For example, in this scenario, both top-ranked services have identical scores, making it difficult for testers to identify the root cause. Accordingly, Yu et al. [26] propose a weighted spectrum analysis method called MicroRank, which adapts spectrum analysis for trace data. MicroRank prioritizes more frequently called services, given their role in anomaly propagation, and less frequently observed request types to address trace imbalances. It also favors traces with fewer invoked services, as their smaller scope is more likely to reveal the true root cause. However, in our experiments, we found that MicroRank [26] struggles when the root cause is not frequently observed in different propagation paths within abnormal traces. Furthermore, its trace prioritization can sometimes lead to a less significant trace with a shorter scope overshadowing one that includes more critical services. In Table I, the middle compartment shows MicroRank’s output, ranking the true root cause seventh among the candidates. To understand why, Figure 1 presents a 4 service call graph from the abnormal traces in the motivational example. The root cause service is highlighted with a red ’*’ sign. As shown, the root cause service in this case is not highly impactful in propagating the current anomaly, particularly when compared to the ’ts-travel-service’. This explains why MicroRank prioritizes other services based on their structural significance over the true root cause. To tackle these challenges, we focus on the significance of services within interconnected groups, or ”communities,” rather than prioritizing them based solely on their frequency across all traces. By ”communities,” we mean clusters of services that frequently interact, forming tightly-knit functional units within the larger system. Identifying these communities helps distinguish between different contexts and connectivity patterns, significantly reducing the chances of multiple services having the same suspicious score and occupying the same position in the ranked list of candidates. Moreover, by considering the significance of services regarding their community, we can prioritize less frequently observed services when they are important within their own context. This allows for the detection of the root cause even if it is not often invoked in the abnormal traces. Our experiments also demonstrate that it enhances the identification of multiple root causes, as discussed further in Section IV. Additionally, we enhance the root cause identification process by incorporating contextual details from requests or traces. While previous research by Yu et al. [26] emphasizes simpler traces, our approach refines this by balancing the importance of both service significance and trace diversity, regardless of trace length. This provides a more comprehensive and effective method for root cause localization. Table I, last compartments, shows the result of our approach, CARE, applied to the motivational example, ranking the true root cause at the top position in the list of candidates. Fig. 1: Service call graph constructed from abnormal traces collected during the abortion of ts-price-service in TrainTicket III. SYSTEM DESIGN In this paper, we propose CARE, a Context-Aware Root Cause idEntification approach that analyzes various system execution contexts to pinpoint services responsible for performance anomalies. Context refers to the various scopes or groupings in which services interact or influence one another, providing a structured understanding of how anomalies propagate through these groupings. For instance, context can be examined in terms of how a service functions within its community (a group of closely related services) or within a specific trace (a sequence of service calls related to a user request). We formally define context-aware root cause identification as an approach that incorporates multiple contextual scopes—such as service-level, trace-level, and community-level perspectives—into the analysis of anomaly propagation and causal inference. Unlike traditional methods that rely primarily on local metrics or flat topologies, context-aware approaches assess not only which services are anomalous, but also how their importance and influence vary across different contexts. This enables a more accurate and holistic identification of root causes. To the best of our knowledge, such multi-context modeling has been underexplored in the literature, particularly in the domain of root cause analysis for distributed systems. CARE addresses this gap by using multi-source observability data and studying the significance of multiple contexts beyond individual services, including communities of services and traces, to analyze normal and abnormal propagation patterns and enhance the accuracy of root cause identification, particularly in complex, multi-root cause scenarios. Because CARE starts after anomaly detection, we use the tracebased detection method of Li et al. [2], although any off-the-shelf detector could be substituted (see [1], [2], [26]). It is important to note that, following recommendations from prior work [26], subsequent occurrences of the same anomalous state within the time window are not considered separate anomalies. Figure 2 illustrates CARE’s four stages: data collection, weighted service-call-graph construction, contextual analysis, and spectrum analysis. In the data collection phase, CARE gathers both distributed traces and profiling metrics for normal and abnormal executions at the time of an anomaly. This enables a comprehensive understanding of how anomalies propagate through different contexts. In the service call graph construction phase, we build two graphs—one for normal and one for abnormal states—with edges weighted based on their importance in identifying the true root cause. Historical data is used to adjust these weights, helping to differentiate genuine anomalies from performance noise. The contextual analysis phase examines three different contexts—individual services, communities of services, and traces—and prioritizes them based on their significance in anomaly propagation and their potential to reveal the true root cause. This multi-context analysis distinguishes suspicious parts of the service call graphs and requests, improving root cause identification and enhancing the handling of multi-root cause scenarios. After contextual analysis, we apply SBFL. To adapt SBFL for distributed traces, CARE introduces a weighted spectrum analysis technique that prioritizes different system execution contexts based on their significance and contribution to performance anomalies. The output is a ranked list of services based on their probability of being the root cause. We refer to the identified services as candidates or root causes of performance anomalies [2], [26]. Each step is explained in detail in the following subsections. A. Data Collection This step involves collecting distributed traces and profiling metrics from the target microservice application. Various monitoring techniques can be employed to gather this data [8]. For this purpose, we can adopt the data collection architecture proposed in the existing literature [1]. The data collection process consists of two parts: gathering data from the normal execution of the target microservice application, which can be performed as an offline task, and actively collecting data from the production environment. Data from normal execution, referred to as historical data or expected behaviour, is used to quantify the anomaly severity of service invocations in subsequent steps. To ensure this historical data accurately reflects the system’s current expected behaviour, it is periodically updated. For production environment data, the system is continuously monitored, and traces are collected within specified sliding time windows. Unlike historical data, traces collected during these windows may capture both normal and abnormal behaviours of the system. Consistent with the literature [2], [26], we define the size of the sliding time window as five minutes. Given a set of traces collected within a specific time window, denoted as T={T1, T2, ..., Tn}, each trace (Ti) is a trace with Trace ID iand is defined as an ordered sequence of service invocations 5 Fig. 2: Framework of CARE: Context aware Root Cause Identification such as Ti=< Ii1, Ii2, ..., Iim >. Each service invocation Iij , the jth invocation within Ti, is represented as a tuple: Iij = (ssrc ij , sdst ij , mij) Where ssrc ij is the source service initiating the invocation Iij,sdst ij is the destination service being called in invocation Iij, and mij = m(1) ij , m(2) ij , ..., m(k) ij is a vector of kprofiling metrics associated with the invocation Iij . Each profiling metric m(l) ij represents a specific performance metric of the invocation, such as response time, CPU usage, memory consumption, etc. For illustration, consider three traces T1,T2and T3with service calls between services A, B, and C. The structure of our collected data is presented in Table II, under the ”Data collection” section, where T1=< I11, I12 >with two service invocations, T2=< I21 >and T3=< I31 >each has one service invocation. For simplicity, Table II lists service invocations and metrics by their simplified indices. B. Constructing weighted Service Calls Graphs The next steps in CARE are initiated once an anomaly is detected. Upon detection, weighted service call graphs (SCGs) are constructed to represent the system’s behaviour at the time of the anomaly. The following outlines the key tasks for constructing these graphs. 1) Constructing Service Call Graphs: During a time window containing an anomaly, not all requests or traces exhibit abnormal behaviour. As mentioned earlier, we use both normal and abnormal traces to identify potential root causes within the window. In this step, two distinct SCGs are constructed: one for the group of normal traces and another for the abnormal traces identified in the previous step. A service call graph (SCG) is a directed graph that represents service invocations, showing interactions between pairs of microservices [35]. In the graph, identical service invocations are consolidated into edges, while nodes represent the services examined as potential root causes. We enhance the SCGs by adding weights to the edges, indicating the significance of service invocations in the root cause localization process. 2) Quantifying Anomaly Severity in Service Invocations: Once an anomaly is detected within a sliding time window, we quantify the anomaly severity for each service invocation type with respect to all its profiling metrics. This value represents the extent to which the service invocation deviates from the expected behaviour with respect to its affected profiling metric by the anomaly. The overall anomaly severity for a service invocation is determined by multiplying the severity values for its affected profiling metrics. Since profiling metrics may not necessarily represent normal behaviour, the computed anomaly severity for affected profiling metrics may not fall within the typical range of zero to one. Additionally, a service invocation can be associated with multiple affected profiling metrics, yet only a subset of them might exhibit abnormal behaviour. To assess the contribution of each affected profiling metric to the overall anomaly severity of a service invocation, we introduce an adjustment procedure. Specifically, if the anomaly severity value computed for an affected metric is less than or equal to one, we standardize it to one. Values exceeding one remain unchanged. This adjustment ensures that any anomaly severity value falling within the range of zero to one, representing normal behaviour, is standardized to a value of one. Consequently, the service invocation’s anomaly severity reflects the magnitude of the anomaly led by each affected metric. Algorithm 1 provides a detailed explanation of the process we follow to compute the anomaly severity for each service invocation. Algorithm 1 Quantifying Anomaly Severity in Invocations 1: for each service invocation Iiin a time window Wwith an anomaly do 2: M←collect list of affected profiling metrics for Ii 3: αIi= 1 4: for each metric min Mand M=∅do 5: αm←max 1,|valuem−µm| σm 6: αIi=αIi∗αm 7: end for 8: end for In Table II, in the middle section, we provide explanations of quantifying anomaly severity in invocations for the fictive example introduced earlier. We assume that the service invocation A→B is detected as an anomaly in both traces T1, T2, while service invocations B→Care identified as normal. Assuming that the affected profiling metrics for each service invocation correspond to those shown in Table II, the service invocation anomaly severity for each invocation is calculated according to Algorithm 1, shown in the ’Service Invocation Anomaly Severity’ column of Table II. 3) Weighting Service Call Graphs: According to Yu et al. [26], analyzing the frequency of services in collected data offers valuable insights for prioritizing services in root cause localization. For instance, a frequently observed service invocation in abnormal traces is more likely to include a potential candidate. The significance of a service invocation’s frequency can be effectively captured by considering the sum of the number of times that a particular service invocation appears in the collected data. On the other hand, not all service invocations in abnormal traces are necessarily abnormal, and even if they are, they may not exhibit abnormality at the same level. To account for the varying degrees of anomaly affection for each edge, we define the anomaly severity per service invocations. The service invocation anomaly severity quantifies the degree of a service invocation’s influence by the anomaly. Naturally, service invocations including a potential candidate are expected to exhibit higher anomaly severity compared to other service invocations. To encompass both the significance of a service invocation frequency and its affection by the anomaly, we establish the edge weights as the cumulative sum of the anomaly severity computed for each occurrence of that service invocation. In this context, αI denotes the service invocation anomaly severity calculated using Algorithm 1, and the edge weight is defined as follows: Weighta→b=X for each I=a→b αI(3) The final section of table II illustrates the calculation of weights for our example’s service invocations. It is important to note that, as αI 6 TABLE II: An illustrative example of trace data collection, anomaly severity computation for service invocations, and the derived edge weights in the SCG, using three fictive traces. Data Collection Quantifying Anomaly Severity in Invocations SCG’ Edge Weight Computation Trace ID Invocations Metrics Label Affected Profiling Metrics Service Invocation Anomaly Severity Abnormal Normal T1 I1:A→B[m1, m2,...,mK]✗mi, mjα1= max(1,|mi−µmi| σmi )×max(1,|mj−µmj| σmj )T1, T2T3 T1 I2:B→C[m1, m2,...,mK]✓mf, mgα2=max(1,|mf−µmf| σmf )×max(1,|mg−µmg| σmg)A→B:α1+α3B→C:α4 T2 I1:A→B[m1, m2,...,mK]✗mi, mjα3= max(1,|mi−µmi| σmi )×max(1,|mj−µmj| σmj )B→C:α2 T3 I1:B→C[m1, m2,...,mK]✓mf, mgα4= max(1,|mf−µmf| σmf )×max(1,|mg−µmg| σmg) equals one for normal service invocations, the weights assigned to the normal edges in our SCGs are based on the frequency of each edge in the collected data. C. Contextual Analysis In this step, we study the structural significance of different contexts, including service communities, individual services, and traces, in propagating behaviours within SCGs. The objective is to derive importance scores for different contexts in both normal and abnormal scenarios. Therefore, contextual analysis steps are applied to both constructed normal and abnormal SCGs. 1) Prioritize Communities: In network graphs, communities are identified as cohesive groups of nodes densely interconnected within themselves but with fewer connections to nodes outside the group [36]. These communities are influenced by features of the nodes and edges, such as the weight and frequency of the edges. In our SCGs, edges’ weight highlights the significance of service invocations in propagating normal or abnormal behaviours. Consequently, communities within SCGs emerge as pivotal contextual units, specifying significant groups of nodes in propagating a behaviour. As anomalies propagate through the services, identifying the root cause requires understanding the propagation pattern through nodes of SCGs both forward and backward. For example, consider an unexpected latency in service B in a system with three services A, B, and C, where B is called by A and B calls C. If we observe that all B→C invocations are normal while A→B invocations are abnormal, service A is likely causing the abnormal latency in B. In other words, to understand an unexpected latency in B, studying B along with its neighbouring nodes is more efficient compared to studying the single service of B in isolation. On the other hand, not all nodes within SCGs play an equal role in propagating anomalies. Studying significant nodes within their communities and along with other significant nodes not only limits the scope of study but also distinguishes significant groups. Consequently, this approach makes suspicious nodes more distinguishable, resulting in more effective node prioritization. Furthermore, the separation of nodes according to their communities enhances insights in scenarios with multiple root causes, as discussed in Section IV. Different graph community detection algorithms can yield varying results depending on the communities they identify. In this paper, we explore well-known community detection algorithms for large networks including Louvain [37] and Infomap [38], as well as neural network-based machine learning approaches for learning structural information, relationships, and features of services, and a lightweight heuristic graph walk and community detection algorithm, introduced below. To ensure that both forward and backward propagation directions are considered, we convert the edges of our SCG to bidirectional edges for the Louvain and Infomap algorithms. In the GNN-based community detection algorithm and our heuristic algorithm, we explicitly control the traversal of the SCG to include both incoming and outgoing edges. I) Louvain graph community algorithm: The Louvain method [37] is widely recognized for its efficiency and effectiveness in large-scale graphs. It identifies groups of services that are more densely connected internally than with the rest of the network. In an abnormal SCG, where edge weights reflect the severity of anomalies in service interactions, detected communities represent clusters of frequently invoked services exhibiting abnormal behaviour. II) Infomap graph community algorithm: The Louvain algorithm may not be efficient in detecting communities in hierarchical network graphs or when communities differ significantly in density, size, or overlap. Infomap, a multi-level clustering approach based on the Map equation [38], maximizes information flow within communities. Since abnormal SCGs highlight the severity of service invocation anomalies, Infomap often forms communities of densely abnormal services, increasing the likelihood of identifying root causes in high-flow areas. III) Graph Neural Network (GNN)- based community detection algorithm: GNN-based community detection aims to use the power of GNNs to learn and represent the structural information, relationships, and features of services (nodes) within SCGs as node embeddings. These embeddings are then clustered to form communities of nodes with similar characteristics. To tailor the node embedding generation to our specific context, we aim for similar embeddings for nodes with comparable significance, such as those with similar anomaly severity levels in abnormal SCGs. Additionally, to preserve the propagation patterns between nodes, connected nodes must receive similar embeddings to ensure they are clustered in the same community later. The embeddings should also be influenced by the modularity degree between nodes to optimize community detection in subsequent steps. We define the features of services by their node degree in the SCG, representing the significance of the services in the SPGs, along with outbound weight and inbound weight, which reflect the anomaly severity caused by calling the service or being called by it, respectively. These features ensure the preservation of both propagation directions. An unsupervised GraphSAGE model [39] is then used to learn node embeddings based on the services’ propagation pattern and weighted edges in SCGs. The GNN training process involves minimizing a loss function that aims to generate similar embeddings for nodes with similar structural features, importance, or connectivity patterns within the SCG while maximizing the overall modularity in our community detection algorithm. We define this loss function as follows: L=LBCE +LModularity +λreg · LL2 where LBCE is the binary cross-entropy loss. If yij and σ(Sij) represent the true and predicted labels of the similarity between nodes iand j, respectively, with, σdenoting the sigmoid function, LBCE is defined as: LBCE =−1 N N X i=1 N X j=1 hyij log(σ(Sij)) + (1 −yij) log(1 −σ(Sij))i LModularity is the modularity loss, defined as follows, where wi presents the edge weights, Sui,viis the similarity between nodes ui 7 and vi, and mis the sum of all edge weights. γis a hyperparameter controlling the contribution of the modularity loss to the overall loss function: LModularity =−γ1 m |E| X i=1 wiSui,vi−wuiwvi 2m Finally, LL2 is the L2 regularization term, defined as LL2 =∥E∥2 2, where Erepresents the model embeddings. λreg is a hyperparameter that controls the strength of the L2 regularization term LL2 in the overall loss function. Once node embeddings are obtained from training the GNN, these embeddings are used to compute a similarity matrix, which forms the basis for clustering nodes through Spectral Clustering [40]. The similarity matrix is adjusted to ensure that tightly connected nodes have similar embeddings, increasing the likelihood of grouping them into the same community. To determine the optimal number of clusters, we use a clustering validity metric such as the silhouette score [41] to ensure that the resulting clusters are both well-defined and meaningful. IV) Heuristic community detection algorithm: Our experiments revealed that it is beneficial to identify communities with a high information flow, as these represent significant groups of nodes that collectively propagate anomalies and are likely to include the root cause. Rather than focusing on refining network structures or optimizing modularity through algorithms like Louvain or Infomap, we prioritize community detection aimed at identifying groups of frequently occurring abnormal services. This approach avoids the time-intensive complexity often associated with general-purpose community refinement based on overall graph patterns. To accomplish this, we propose a heuristic community detection method outlined in Algorithm 2. Algorithm 2 identifies service communities within an SCG using a weight-based approach. Each node’s weight, initialized as the sum of its outgoing edge weights, prioritizes services likely to propagate anomalies. The algorithm traverses both successors and predecessors of each node to capture bidirectional anomaly propagation. Starting with the highest-weight node, it iteratively forms communities by adding nodes with edge weights exceeding a predefined threshold (e.g., threshold = 1, corresponding to a single normal service invocation). Nodes with weights below the threshold terminate the current community. This approach effectively groups interconnected services involved in both forward and backward anomaly propagation. 2) Prioritize Services: After prioritizing communities within SCGs, the next step is to prioritize individual services by quantifying their importance for root cause identification. Prior research [22], [26] suggests using graph-based node rank algorithms such as PageRank to determine the significance of services as nodes within SCGs. In CARE, we calculate a service’s importance score while also considering the community to which the service belongs. To account for the community to which a service belongs, we adjust its importance score by incorporating the importance of its community. In an SCG, each community is treated as a supervertex, with edges between communities defined as the sum of the weights of edges between their constituent nodes. These weighted edges provide a combined measure of both the frequency and the severity of interactions between services in different communities. Similar to services, a graph-based node ranking algorithm such as PageRank can be applied over each community, treating it as a supervertex, to quantify the importance of the community that owns the service. The final importance score of a service is then calculated as a weighted average of both the service’s and its community’s importance score, ensuring that neither dominates unless one is significantly Algorithm 2 Heuristic Community Detection Algorithm Require: SCG, threshold 1: for each node vin SCG:w(v) = sum of weights on v. outgoing edges 2: N←nodes in SCG sorted in ascending order based on their w 3: Initialize communities{nodes :None, score : 0} 4: Initialize current id ←0 5: for each node in Ndo 6: if node /∈communities then 7: communities[current id][score]+= w(node) 8: q←node 9: while qis not empty do 10: n←q.pop(0) 11: if n /∈communities then 12: communities[current id][nodes]←n 13: for any neighbour of ndo 14: if edge weight(n, neighbor)> threshold and neighbour /∈communities then 15: q←neighbour 16: communities[current id][score] += w(neighbour) 17: end if 18: end for 19: end if 20: end while 21: current id ←current id + 1 22: end if 23: end for larger. Our experiments demonstrate that emphasizing community importance enhances the results. For instance, for the graph-based node ranking algorithm PageRank, PR, the node importance score is defined as follows, with th1= 0.2and th2= 0.8based on observations from our experiments. Scorenode(n) = th1∗PR(n) + th2∗P R(community[n∈nodes]) 2(4) In this paper, we explore different graph-based node ranking algorithms, including PageRank, Hyperlink-Induced Topic Search (HITS), and Betweenness Centrality, as they may yield different results. I) PageRank: PageRank is computed through an iterative algorithm [42] that assesses the significance of services based on their interactions with other services. Initially, each service within the SCG is assigned a PageRank value of 1 n, where nis the total number of services in the SCG. These values are iteratively updated until they converge to a stable state. The PageRank for a service nin an SCG Gafter titerations is calculated based on the PageRank of its neighbouring services, defined as follows: PR(n)t=βX (n→n′)∈edges of G PRt−1(n′) out degree(n′)(5) Here, βis a normalization factor for the total rank of all services, and the out degree represents the number of outgoing edges from the neighbouring node n′. II) Hyperlink-Induced Topic Search (HITS): HITS assigns two scores to each node, including a hub score and an authority score, which are computed iteratively based on the structure of the graph [43]. In the context of SCGs, services that call many important services act as hubs, while those frequently called by such hubs act as authorities. Initially, all nodes are assigned a hub and authority score of 1. These values are updated iteratively until convergence. For a service node nin SCG G, the authority and hub scores at 8 iteration tare computed as follows while GHtand GAtdenote the hub and authority score vectors of all nodes in the SCG at iteration t, respectively: A(n)t=X(n′→n)∈edges of GHt−1(n′)(6) H(n)t=X(n→n′)∈edges of GAt−1(n′)(7) After each iteration, the scores are typically normalized to prevent unbounded growth. The final scores indicate a node’s role as either a hub or an authority in propagating or receiving influence within the graph structure. This enables the prioritization of both initiators and targets of anomalous behavior. We examine three variants of the HITS algorithm in which both services and communities in Equation 4 are prioritized based on: (i) their hub scores, (ii) their authority scores, and (iii) the average of the two. We refer to these variants as HITS (Hub), HITS (Authority), and HITS (Avg), respectively. III) Betweenness Centrality: Betweenness Centrality quantifies the importance of a service based on the number of shortest paths between all other services that pass through it [44]. A high betweenness centrality score indicates that a service frequently acts as an intermediary in communication or fault propagation paths. For a service node nin graph G, betweenness centrality BC(n)is defined as: BC(n) = X s=n=t∈V σst(n) σst (8) Here, σst is the total number of shortest paths between nodes sand t, and σst(n)is the number of those paths that pass through node n. The summation is taken over all pairs of distinct nodes sand tin the graph. Since standard Betweenness Centrality prioritizes shorter paths (i.e., low-weight paths), we invert the edge weights in the SCG to prioritize critical nodes involved in fault propagation or bottlenecks. Our experiments, discussed in Section V-B, show that PageRank produces more consistent and accurate results. Therefore, unless otherwise specified in the experimental design, all reported results are based on PageRank. 3) Prioritize Traces: In this step, we focus on prioritizing execution paths or traces considering their effectiveness in uncovering a root cause. According to Yu et al. [26], less diverse traces expedite root-cause localization. This is because more similar traces indicate a narrower scope of difference, simplifying the pinpointing of the root cause. However, Yu et al. measure trace diversity using the count of operations covered in traces, which makes it dependent on trace size. Consequently, shorter traces with less important services may overshadow longer ones with more critical services. In our approach, we prioritize traces by considering both their diversity and the significance of the services they cover, regardless of the number of services involved. To this end, we adopt the approach proposed by Chen et al. [45] for prioritizing regression test cases. Since traces frequently occur within a time window, we first cluster both normal and abnormal collected traces based on their request type, i.e., the services they cover and the order of service invocations. This ensures that we study traces based on their types regardless of their frequency of occurrence. Then, for each request-type cluster, we calculate a score based on the importance of the covered services and the diversity. This importance score is calculated based on node scores, Scorenode(s), obtained from the equation 4 in the previous task. The rank score of a cluster clibased on the importance of services that it covers is measured as follows, while function L(X)denotes the position of score Xwithin the ordered list of ascending node scores within the SCG, and |SCG|represents the number of SCG’s nodes (services). For abnormal request-type clusters, SCG refers to abnormal SCG and Scorenode(s)are scores of all services computed from abnormal SCG. The same is applied to normal requesttype clusters. Rank(cli) =L(max(Scorenode(s∈cli)) −1) |SCG| +Mean(Scorenode(s∈cli)) |SCG|P(Scorenode(s∈SCG)) (9) Next, we adjust the rank score of clusters based on the diversity between request-type clusters, measured by the Jaccard distance [46]. To prioritize a request-type cluster with high-score nodes and less diversity compared to all other request-type clusters, we first normalize the calculated scores from equation 9 to make them comparable with the diversity scores. Then, we employ an adapted heuristic search algorithm [45] to iteratively find the next cluster with the highest Rank(cli)score while minimizing diversity compared to the previously selected cluster. This search algorithm returns an ordered list of request type clusters. In addition to considering the importance and diversity of services covered by a trace, each abnormal trace, regardless of its request type, exhibits a distinct level of anomaly severity. Abnormal traces with higher anomaly severity are more likely to include the root cause. We measure the trace anomaly severity for each trace using the average anomaly severity of its service invocations, i.e., PI∈trace αI num(I). Using the average anomaly severity of a trace’s service invocations ensures that the trace anomaly severity is independent of the length of the trace. As explained in section III-B, normal service invocations have an anomaly severity equal to one. Therefore, trace anomaly severity highlights the amount of anomaly severity of abnormal service invocations. Finally, the total score for a trace, scoretrace, is calculated by summing its anomaly severity and the ordered result returned by the heuristic search algorithm for its corresponding cluster request type. D. Spectrum Analysis After analyzing the importance of different contexts, we use the measured importance scores to modify the statistics and define a weighted spectrum analysis approach. In this weighted spectrum analysis approach, we extend the SBFL statistics beyond simply counting how often a service is covered or not covered by normal and abnormal traces during an incident. We also take into account the importance of the service itself—including its community significance—and the significance of each trace in that includes or excludes the service. Accordingly, the statistics described in Equation 1 are modified to reflect this contextual weighting as follows for each service siand sets of collected normal, N, and abnormal traces, AN. Note that Oef , Onf uses the scores calculated over the abnormal SCG and abnormal traces, while Oep, Onp uses scores based on the normal SCG and traces. Oef and Oep are defined as follows, where T=AN for Oef and T=Nfor Oep : Oef (si) = Oep(si) = scorenode(si)×X si∈T scoretrace(T)(10) Additionally, Onf and Onp are defined as follows, where T=AN for Onf and T=Nfor Onp Onf (si) = Onp(si) = scorenode(si)×X si/∈T scoretrace(T)(11) As defined in Section II, spectrum-based approaches use risk evaluation factors to compute a suspiciousness score for each component based on collected spectrum statistics [25], [26], [31]–[33]. This score reflects the likelihood of a component being faulty. A wide range of risk evaluation factors have been proposed, and studies have shown that their effectiveness varies depending on the dataset’s context, size, label distribution, and noise level [47], [48]. As a result, it is generally recommended to choose risk evaluation factors 9 suited to the specific analysis setting. However, some risk evaluation factors have been more frequently adopted in the literature. In this study, we began by identifying risk evaluation factors that are both widely used and frequently recommended in the literature. We then filtered these to focus on those that are more applicable within the scope of spectrum-based approaches for trace analysis [25], [26]. Finally, we selected four factors based on their demonstrated performance—whether high or low—in prior studies, enabling us to use them as representative baselines in our evaluation. These four factors serve as reference points for comparing CARE with the related methods used as baselines. Similarly to typical spectrum-based approaches, we use risk evaluation factors to compute each service’s suspicious score. In this paper, we employ various risk evaluation factors introduced in Table III. TABLE III: Risk Evaluation Factors used in the experiments Ochiai: Oef √(Oef +Onf )(Oef +Oep)M2: O2 ef (Oef +Onf )(Oef +Oep) DStar2: O2 ef Oep+(Oef +Onf )−Oef RusselRao: Oef Oef +Onf +Oep+Onp To illustrate how CARE works in practice, Figure 3 presents a representative case study selected from the second dataset used in this paper. In this scenario, the root cause of the anomaly is the service docker 003. Figure 3-A shows the abnormal SCG constructed from 14,193 collected abnormal traces at the time of the incident. On the right-hand side of Figure 3-A, nodes are ranked using PageRank scores in descending order, highlighting their relative importance in the graph. As shown, the true root cause is not necessarily the most significant node based on structure alone. When we applied standard spectrum analysis to these traces, docker 003 was ranked only 8th among all nodes—since it is not a central node in the SCG and does not appear frequently enough in the abnormal traces for SBFL to prioritize it. Figure 3-B shows the next CARE’s step, identifying and prioritizing communities within the abnormal SCG. In total, six communities are identified, each represented with a unique color. The right-hand side of Figure 3-B lists the services belonging to each community. Figure 3-C illustrates the following step of contextual analysis, in which service prioritization considers both the node-level and community-level significance. CARE first constructs a community graph, where each node represents a group of services belonging to the same community, and then computes the importance score for each community using a graph-based ranking algorithm. The right-hand side of Figure 3-C shows the sorted PageRank scores of these communities. Then, each service’s final score is calculated by combining its own importance with that of its community, as defined in Equation 4. The ranked list of services based on this final score is also shown in Figure 3-C. The next contextual analysis step involves prioritizing traces. First, CARE clusters the abnormal traces based on their request type (i.e., unique invocation sequences). In this case, 14,193 abnormal traces are grouped into 36 distinct clusters. Each cluster is assigned a score based on the importance of the services it covers and their structural diversity, as described in Section III-C3. Next, CARE finalizes the significance score of each trace by incorporating its anomaly severity. Figure 3-D presents a partial view of these steps. Finally, CARE computes the weighted SBFL statistics and the Ochiai score for each component, using both the normal and abnormal SCGs, along with the computed service and trace scores from both normal and abnormal data. Figure 3E presents the results of this analysis. As highlighted in the figure, the true root cause, docker 003, is successfully identified, achieving the highest Ochiai score following the complete contextual analysis process. IV. EXPERIMENTAL SETUP In this section, we explain the design of our experiments, which aim to evaluate CARE’s effectiveness in improving root cause analysis in both single root cause scenarios and more complex situations involving multiple root causes. To validate the effectiveness of CARE in addressing limitations of existing techniques, we compare it against several state-of-the-art root cause analysis approaches. Since CARE is a weighted SBFL method for distributed trace analysis, we include MicroRank [26], a weighted SBFL approach for traces leveraging PageRank, as a primary baseline. In line with prior literature [26], we also incorporate a regular SBFL method for traces suggested by Ye et al. [25]. Furthermore, we compare CARE against two recent advanced approaches that are not SBFL-based: TraceRCA [2] and HeMiRCA [49]. TraceRCA is included because CARE adopts its anomaly detection mechanism, and comparing the full pipelines provides a fair and relevant evaluation. HeMiRCA is selected due to its strong performance and its use of the same input modalities, which makes it a suitable and meaningful baseline. Regular spectrum analysis performs the standard statistical definition [25] on the passed and failed test cases. In this paper, for regular spectrum analysis, we categorize normal and abnormal traces using their HTTP status codes to simulate passed and failed executions. In cases where HTTP status codes are absent, we classify normal and abnormal traces based on the outcome of the anomaly detection step on the collected traces within a time window. To ensure comparability, we use the same anomaly detection method suggested by Li et al. [2] for all approaches. Based on the scope of MicroRank, we adjusted the anomaly detection to identify latency anomalies and then define normal and abnormal traces for evaluating MicroRank. Additionally, we evaluate CARE’s efficiency in terms of time complexity and resource usage to determine its practicality for deployment in production environments. To ensure reproducibility, we utilized widely adopted open-source libraries and frameworks. All experiments were conducted on a machine with 6 CPU cores, 12 logical processors, and 20GB of RAM. The implementation, including detailed instructions and code, is publicly available at the CARE1. Our evaluation framework is structured around research questions specifically designed to address key gaps in the literature: RQ1. How effective is CARE in identifying true root causes? RQ2. How effective is CARE in identifying multiple root causes? RQ3. How efficient is CARE in terms of resource usage? A. Data Sets To evaluate our approach, we selected two open-source datasets2from widely-used microservice benchmark systems: TrainTicket [28] and a real-world production microservice system [29]. These benchmarks are frequently referenced in the literature [1], [2], [21], [50]. To the best of our knowledge, TrainTicket is the largest open-source microservice benchmark available for academic use, while the real-world system provides anonymized data from an actual production environment. The datasets collected from these benchmarks were originally published alongside one of our baselines, TraceRCA [2], which facilitates reproducibility for that baseline. Moreover, since TraceRCA provides tuned hyperparameters specific to these datasets for calculating anomaly severity, it enables us to consistently derive anomaly severity per edge of service call graphs without introducing additional variability or requiring further tuning. These datasets include traces and profiling metrics captured over five-minute windows during anomaly periods, with labeled root causes, as well as corresponding historical data collected during normal operation. Additionally, the TrainTicket dataset is, to the best of 1https://github.com/M-panahandeh/CARE-Context-Aware-Root-CauseIdentification-Using-Distributed-Traces-and-Profiling-Metrics 2https://github.com/NetManAIOps/TraceRCA 16 Fig. 5: Left: CARE’s performance across various noise levels, evaluated using different risk evaluation factors. Right: Performance comparison across noise levels between CARE and baseline approaches, each evaluated using its own optimal risk evaluation factor. TABLE X: Comparison of CARE’s performance when using different graph-based ranking algorithms for the first dataset, TrainTicket Metric HITS (Hub) HITS (Authority) HITS (Avg) Betweenness R@1 (%) R@3 (%) R@5 (%) ES MAR ASP R@1 (%) R@3 (%) R@5 (%) ES MAR ASP R@1 (%) R@3 (%) R@5 (%) ES MAR ASP R@1 (%) R@3 (%) R@5 (%) ES MAR ASP Ochiai 72 92 95 0.24 1.77 0.04 79 94 98 0 1.42 0.02 86 96 98 0.45 1.32 0.03 38 50 59 1.87 6.04 6.09 Mˆ2 79 95 97 0.16 1.48 0.03 82 96 97 0.13 1.42 0.02 85 96 96 0.19 1.43 0.01 37 49 58 1.95 6.17 6.08 Dstar2 54 80 84 0.77 2.67 0.01 56 81 86 0.72 2.63 0 59 82 84 0.80 2.58 0 23 42 53 2.21 6.77 6.08 RussellRao 77 94 97 0.16 1.53 0.02 83 94 97 0.13 1.46 0.02 84 94 96 0.21 1.49 0.03 37 49 58 1.95 6.19 6.08 TABLE XI: Comparison of CARE’s performance when using different graph-based ranking algorithms for the second dataset, Real-world case Metric HITS (Hub) HITS (Authority) HITS (Avg) Betweenness R@1 (%) R@3 (%) R@5 (%) ES MAR ASP R@1 (%) R@3 (%) R@5 (%) ES MAR ASP R@1 (%) R@3 (%) R@5 (%) ES MAR ASP R@1 (%) R@3 (%) R@5 (%) ES MAR ASP Ochiai 24 76 84 0.80 2.80 0 44 80 84 0.80 2.80 0 36 76 84 0.80 3.0 0 28 52 84 0.80 3.28 0.84 Mˆ2 16 76 88 0.60 2.72 0 44 80 84 0.80 2.72 0 32 76 84 0.80 2.96 0 28 48 84 0.80 3.44 0.84 Dstar2 72 84 96 0.20 1.88 0 72 84 88 0.60 2.08 0 72 84 84 0.80 2.16 0 16 32 84 0.80 4.04 0.84 RussellRao 16 76 88 0.60 2.72 0 40 80 84 0.80 2.76 0 32 76 84 0.80 2.92 0 28 44 84 0.80 3.56 0.84 TABLE XII: Comparison of CARE’s performance when using different community detection algorithms Metric Louvain Info-map GNN-based Heuristic R@1 (%) R@3 (%) R@5 (%) ES MAR R@1 (%) R@3 (%) R@5 (%) ES MAR R@1 (%) R@3 (%) R@5 (%) ES MAR R@1 (%) R@3 (%) R@5 (%) ES MAR Ochiai 52 76 84 0.8 2.72 48 68 84 0.8 3.12 40 64 84 0.8 3.4 72 84 84 0.8 2.56 M2 44 72 88 0.6 2.8 44 60 80 1 3.56 44 68 88 0.6 3.04 72 84 84 0.8 2.6 Dstar2 12 64 72 1.4 3.84 32 56 80 1 3.96 24 56 72 1.4 4.04 68 80 84 0.8 2.32 RussellRao 40 64 80 1 3.48 44 60 80 1 3.72 36 56 68 1.6 3.92 72 84 84 0.8 2.6 TABLE XIII: Comparison of the execution overhead incurred by different community detection algorithms Metrics Louvain Info-map GNN-based Heuristic Execution time(Sec.) 0.84 0.89 4.82 0.85 Memory Usage(MB) 167.03 167.17 379.69 166.0 CPU usage(%) 7.9 13.8 20.2 9.6 undetected up to top-5 with node prioritization alone. However, Top1 accuracy decreases with the addition of the trace prioritization module. A closer analysis reveals that the new root causes identified at top-5 differ from those missed at top-1, reflected in a decline in ES. Similarly, applying trace prioritization over service prioritization added new scenarios to top-5 but shifted some scenarios from top-1 to top-3, impacting Top-1 accuracy. Incorporating the community detection module increased the number of correctly identified scenarios at both top-1 and top-3. Specifically, 12% of scenarios previously undetected at top-1 were correctly identified at top-1 after adding this module. Additionally, it improved the ranking of the root cause from top-5 to top-3 for some scenarios. As shown by the MAR metric, the overall average rank decreased when all modules were used together. E. What are the limitations of our approach? Although our Weighted Spectrum Analysis approach, CARE, addresses several limitations of SBFL and adapts it for distributed traces, it still faces certain constraints, which we discuss in this section. Specifically, CARE mitigates known issues in SBFL such as assigning identical suspicious scores to multiple candidates [56], Fig. 6: Root cause localization performance as CARE’s contextual analysis modules are progressively added the lack of contextual analysis [57], [58], the inability to identify multiple root causes [59], [60], and the absence of an interpretable model [61], by integrating SBFL with contextual analysis and leveraging multi-source observability data. However, there remain scenarios where CARE is unable to accurately identify root causes. We aim to analyze these cases and determine the contributing factors. Our observations show that CARE effectively identifies root causes when anomalies are clearly reflected in profiling metrics or when the true root cause is represented by a balanced number of traces 17 relative to other services. However, challenges arise when a nonroot cause component appears in many propagation paths. This issue is exacerbated when the profiling metrics of these components are influenced by anomalies or noise, causing them to be mistakenly prioritized as significant nodes over the true root cause. An extension of this challenge—which we did not encounter in our studied target system but is possible in microservice architectures—is the presence of resilient patterns. For example, the presence of circuit breakers [62] can alter service correlations by masking the true root cause downstream. Circuit breakers achieve this by turning off requests toward the faulty service, thereby shifting the failure signals upstream to neighboring services that experience failures or abnormal response times. Some existing works [63], [64] address this issue by fist detecting such resilient patterns in traces and then adjusting profiling metrics. However, resolving this problem is beyond the scope of CARE. The second category of undetected root causes arises in scenarios with a high incidence of false positive or false negative labeled traces. Our spectrum-based approach relies on accurate anomaly detection to correctly differentiate between failed and successful executions. If abnormal traces are not detected, or false positives are introduced, the suspicious scores assigned by CARE may be inaccurately skewed. This dependency means that any inaccuracies in anomaly detection can directly impact CARE’s ability to localize faults, potentially leading to incorrect root cause identification. Lastly, undetected root causes can arise when the true root cause is absent from all collected traces within the sliding time window. This typically occurs when the root cause is not a frequently invoked service. For example, in our experiments, one scenario out of 200 in the TrainTicket dataset faced this issue: the ‘user’ service, where the anomaly was injected, was not involved in any traces during the five-minute collection window. This limitation parallels SBFL’s challenge with unreachable code, where unexecuted sections remain unanalyzed, potentially concealing faults [65]. When the true fault does not appear in any trace, CARE cannot identify it, leaving some faults undetected. VI. REPRODUCIBILITY AND IMPLEMENTATION DETAILS To ensure the reproducibility of our results, we used widely adopted open-source libraries and frameworks. Our experiments were run on a machine with 6 CPU cores, 12 logical processors, and 20GB of RAM. Key computational tasks—such as data processing, graph construction, and model training—were parallelized using Python’s multiprocessing and concurrent libraries for optimized performance. For data manipulation, we utilized standard Python libraries like Pandas and NumPy, while graph analysis was performed using networkx and infomap. Visualization was done with Matplotlib. Machine learning tasks, including clustering and model evaluation, were handled with scikit-learn, and deep learning models were implemented using PyTorch and PyTorch Geometric. Community detection algorithms, such as the Louvain method, were applied using the community-louvain package. The implementation supports both CARE and the reproduced baseline approaches, making it easy for future researchers to adapt or extend our methods. Detailed code, dependencies, and instructions are available at the public repository CARE, ensuring ease of use and reproducibility. To deploy CARE in a real-world microservice environment, it is designed to be integrated into the monitoring stage of the CI/CD (continuous integration and continuous delivery/deployment) pipeline, functioning as an observability tool. CARE operates as an online system that runs on demand, triggered upon the detection of anomalous behavior. The first requirement for deploying CARE is establishing an infrastructure for data collection. The target microservice must be continuously monitored. As explained in Section III, any monitoring approach can be used to provide traces and profiling metrics from the system under test for CARE. CARE is also compatible with any anomaly detection approach that provides labels at the trace level. CARE can be deployed as a containerized service, making it suitable for cloud-native architectures, or as a root cause localization agent within an agent-based pipeline, working alongside existing observability agents. CARE is agnostic to the underlying software architecture and requires no retraining or adaptation as the system evolves. Since it relies solely on realtime runtime data, without assumptions about the internal structure of the system under test, it remains robust and reusable across software updates or deployment changes. Scalability concerns related to deploying CARE in operational environments are addressed in RQ3, Section IV-E. Our findings in this research question can help developers make informed trade-offs between CARE’s localization accuracy and the resource constraints they may face by adjusting the number of contextual analysis modules used in deployment. VII. RELATED WORK Root cause analysis is vital for ensuring microservice reliability, with various approaches leveraging different observability data. The first category relies on execution sequences such as logs and traces. Zhou et al. [21] propose MEPFL, a supervised multilayer perceptron model that uses traces to learn service dependencies and latencies. However, its dependence on supervised learning, requiring extensive coverage of propagation paths and anomaly types, limits its applicability in real-world scenarios. Liu et al. [18] introduce TraceAnomaly, an unsupervised deep Bayesian network that learns service dependencies from traces. However, TraceAnomaly only considers unidirectional propagation and focuses on the longest abnormal trace, limiting its scope to root causes at the individual request level. Statistical methods are also common for their efficiency in production environments [66]. For instance, Lin et al. [66] use support and confidence metrics for rule mining and identify critical incidents in log data. Similarly, Li et al. [2] extend this approach in TraceRCA by identifying service sets with high support and confidence, using the Jaccard Index (JI) [67] to prioritize suspicious sets. TraceRCA accounts for forward and backward propagation patterns, but its reliance on tracing frequency and its scoring mechanism, focused on abnormalities in either incoming or outgoing invocations, may miss complex relationships in systems with multiple root causes or anomaly chains. Notably, TraceRCA is the only approach tested in multi-root-cause scenarios, though it is not specifically designed for such cases. Spectrum-based fault localization (SBFL) techniques have also been applied in this domain [68]. For instance, Ye et al. [25] introduce TRank, a real-time root cause analysis method that uses SBFL to rank services by their likelihood of being root causes. However, TRank does not account for service dependencies. To address this, Yu et al. [10] propose TraceRank, integrating SBFL scores with a PageRank score computed through a random walk on a service dependency graph weighted by the Pearson correlation of service processing times. Nonetheless, both TraceRank and TRank fail to adapt SBFL effectively for microservice traces, which often exhibit unbalanced coverage across execution paths. To improve this, Yu et al. [26] develop MicroRank, which combines SBFL with a personalized PageRank algorithm to prioritize services and traces, emphasizing frequently observed services and less common traces with lower service diversity. However, as discussed in SectionII, focusing on individual services alone may overlook root causes in infrequently observed abnormal traces. Additionally, MicroRank’s trace prioritization may undervalue long, significant traces in favor of shorter ones. To address these challenges, Panahandeh et al. [23] introduce a weighted spectrum analysis approach that integrates network analysis with SBFL. This method identifies key services in anomaly propagation by considering their roles within their communities and prioritizes traces based on the importance and diversity 18 of the services they encompass. While their approach enhances root cause identification by incorporating trace prioritization and studying communities to assign more distinct suspicious scores to candidates, it remains limited in its use of profiling metrics for anomaly propagation analysis. Furthermore, it focuses primarily on the Louvain algorithm for community detection, and the experimental evaluation is still preliminary. In this paper, we extend our prior work [23] by incorporating profiling metrics and conducting a more comprehensive study of contextual analysis to address these limitations. Another category of studies focuses on root cause analysis using profiling metrics. These approaches analyze component dependencies, such as network-level interactions, without relying on endto-end execution sequences or detailed log data. Wu et al. [22] introduce MicroRCA, which constructs an attributed graph to represent anomaly propagation by linking application performance symptoms to system resources during anomalies. This graph is then used to rank system components and identify root causes. Similarly, Wu et al. [19] present MicroDiag, which collects profiling metrics at the network level and builds a metric causality graph weighted by metric correlations. Root causes are identified using the PageRank algorithm applied to this graph. The graph is constructed by reversing component connections to infer anomaly propagation paths, using techniques such as the non-Gaussian linear model, DirectLiNGAM [69], and Granger causality tests [70], [71] to establish causality among components like resource and service metrics. However, MicroDiag’s dependency inference is limited to adjacent services and assumes a linear relationship between metrics and their causes. Ma et al. [72] propose Automap, which constructs an anomaly behaviour graph to represent service correlations based on metric variations. The graph is traversed to identify services most correlated with anomalies, prioritizing those connected by multiple paths as likely root causes. Although Automap considers both forward and backward propagation patterns, its invocationbased approach limits its effectiveness to adjacent microservices with abnormal invocations. The third category of studies combines analysis of execution sequences and profiling metrics for root cause identification. Lin et al. [17] propose Microscope, which constructs a causality graph from log data and Service Level Objective (SLO) values using the causal Markov condition [73]. During anomalies, Microscope traverses the graph in reverse, collecting abnormal nodes as candidates. However, it does not handle dependency cycles and only captures anomaly propagation in one direction. Yu et al. [74] introduce Nezha, which constructs event graphs for each request within a time window, representing both normal and abnormal system execution using logs, traces, and profiling metrics. Faultfree and fault-suffering patterns are extracted by traversing these graphs in parallel, excluding infrequent patterns or those with low support. Root causes are prioritized at the request level based on deviations from historical patterns. However, Nezha’s integration of logs and traces requires invasive configuration, which may not be feasible for all systems. Lee et al. [24] propose Eadro, which models log event occurrences using the Hawkes process [75] and a fully connected layer, temporal dependencies, and inter-series associations within KPIs, alongside significant fluctuations in trace latency using dilated causal convolution using dilated causal convolutions [76]. Eadro fuses these representations with a graph attention network (GAT) to learn topological relationships from historical service invocations. A supervised classifier applied over the GAT detects anomalies and estimates the likelihood of services being root causes. However, Eadro’s supervised approach poses challenges for production deployment. Moreover, the black-box nature of GAT limits its interpretability for troubleshooting. Finally, Eadro does not account for the dynamic behaviour of services during anomalies, unlike other studies [2], [26] that utilize both normal and abnormal traces. Zhu et al. propose HeMiRCA [49] , a correlationbased approach that combines Pearson correlation analysis with machine learning for root cause analysis across distributed traces and profiling metrics. Their method operates in three stages. First, it extracts latency span vectors from individual traces; second, it computes time series anomaly scores over these vectors; and third, it calculates Pearson correlations between the profiling metrics of each service at runtime and the computed anomaly scores to identify root causes. To capture dependency and temporal patterns, HeMiRCA employs a Variational Autoencoder (VAE) model trained on historical data. However, HeMiRCA shares several limitations common to existing approaches: it focuses exclusively on single root causes and relies on the assumption that faulty microservices exhibit monotonic correlations between their metric trends and trace-based anomaly scores. This assumption may break down when anomaly scores—particularly those based solely on latency—fail to effectively separate normal and abnormal traces. Overall, two main challenges persist across various root cause analysis approaches, regardless of the observability data sources used. First, many methods are supervised and rely on labeled data for different types of anomalies across possible propagation paths [20], [21], [24]. Second, the study of propagation paths is often limited to one direction [17], [18], adjacent service dependencies [19], [72], or assumptions about the data or production environment that may not always hold, reducing effectiveness in complex scenarios [2], [17], [22], [26], [74]. CARE differentiates itself by using multi-source observability data, analyzing both normal and abnormal traces during anomalies, being unsupervised, and studying propagation patterns in both forward and backward directions. It also goes beyond studying individual services and invocations, visualizing suspicious contexts to aid further investigation. VIII. THREATS TO VALIDITY Internal Threats: One of the internal threats arises from the nature of SBFL techniques, particularly when adapting SBFL to traces. Since traces are not designed to cover all components in a balanced manner, it can skew the suspiciousness scores and lead to misleading results. To mitigate this threat, as suggested in prior studies [2], [10], [26], we monitor the target system using a sliding time window during an anomaly. The time window is defined as β×δt, where δt represents the time unit (set to one minute), which controls the volume of traces analyzed at any given time. This time unit can be adjusted depending on the system’s workload. The parameter βensures that requests not completed in the previous window can be carried over to the next window [10]. In this study, following the suggestions from the literature, we set δt to 1 minute and βto 5, resulting in a 5-minute sliding time window. Next, variations in distributed traces and profiling metrics can impact our approach’s outcome. For instance, adjusting the sliding time window size for anomaly monitoring may change the collected data and results. Additionally, dataset inconsistencies or mislabeling could affect evaluation reliability. The validity of our findings also hinges on the accuracy of fault injections and label correctness in benchmark datasets. To minimize this risk, we use publicly available datasets, such as TrainTicket and China Mobile’s production system, which have pre-labeled root causes. We also address potential errors in CARE’s implementation by thoroughly testing it on small examples and providing scripts and datasets for public verification and reproducibility. External Threats: The datasets used, while widely referenced, may not fully capture the diversity of real-world production systems. To address this, we chose two distinct datasets: one from the TrainTicket benchmark, the largest academic microservice dataset, and another from a real-world microservice system. Additionally, we compared CARE against established baselines, such as MicroRank and TraceRCA, using the same datasets to ensure a fair 19 evaluation of its performance. While the datasets used in our experiments do not encompass all possible fault types, they include a diverse range such as latency-induced faults, resource exhaustion, and configuration errors. Nevertheless, there is a potential threat to external validity, as the results may not generalize to fault types not represented in the data (e.g., storage faults or logic bugs). Despite this limitation, the consistent performance of our method across multiple real-world datasets supports its internal validity and practical applicability. Moreover, we acknowledge that the scalability of CARE—particularly in terms of SCG construction and contextual analysis during online operation—may not be fully reflected by these two datasets alone. To mitigate this limitation, we conducted an in-depth exploration of CARE’s overhead and resource usage across its different modules (see RQ3), and we examined the effect of each module in Section V-D. These insights aim to guide practitioners in adjusting CARE’s configuration based on their operational constraints when deploying it in production environments. Construct Threats: While Recall@K (R@K) and Full Recall@K (FR@K) are commonly used metrics, they focus on ranking root causes and may not fully capture the practical utility in real-world troubleshooting. To address this, we also used Error Score (ES) and Mean Average Rank (MAR) to assess false positives and the rank of true positives. Additionally, we introduced the ASP metric to evaluate the impact of identical suspicious scores, a limitation of SBFL approaches. We also compared CARE’s scalability with other methods for a more thorough evaluation. IX. CONCLUSIONS AND FUTURE PLAN This study presents CARE, a novel context-aware approach for root cause localization in distributed systems. Our methodology emphasizes the importance of service communities, individual services, and trace scope in accurately identifying system anomalies. Through extensive experiments on 224 scenarios from two benchmarks—TrainTicket, the largest open-source microservice benchmark, and a real-world production system from an Internet service provider—CARE delivers notable results. In single root-cause scenarios, it achieves top-1 accuracy rates of 72% to 89% and top5 accuracy between 84% and 99%, outperforming baselines by 29-43% on TrainTicket and 8-12% on the real-world dataset. For scenarios with two root causes, CARE identifies both with top-2 accuracy in 55% of cases (a 46% improvement over baselines) and top-5 accuracy in 82% of cases (an 18% improvement). Additionally, CARE demonstrates resource efficiency, achieving competitive execution times, memory usage, and CPU consumption compared to baselines. Future research offers several promising directions. First, we aim to integrate attention mechanisms with graph neural networks (GNNs) to capture both explicit and implicit anomaly propagation patterns between services. Using GNN embeddings, we plan to fuse offline-learned patterns with real-time anomaly insights, potentially improving accuracy further. Another avenue involves refining network analysis techniques tailored to distributed traces. Customizing community detection algorithms and other networkbased strategies could enhance anomaly identification and adapt to diverse system architectures and trace datasets, increasing CARE’s robustness across real-world environments. CARE currently employs a fixed sliding time window for trace collection. Adopting adaptive time windows that dynamically adjust based on workload and anomaly severity could improve its ability to capture relevant traces during periods of high activity or unique anomaly conditions, further enhancing localization accuracy. A particularly exciting future direction involves replacing the SCG with the hidden states or embeddings of Large Language Models (LLMs). These models could extract temporal and interdependency patterns from logs, traces, and profiling metrics. Integrating LLM embeddings with CARE’s modules could improve root cause identification and allow results to be presented in natural language rather than graphs. This approach offers a flexible and user-friendly format, transforming anomaly detection in distributed systems. Another future direction is to integrate CARE with more advanced anomaly detection techniques that enhance root cause identification—particularly those designed to account for the dynamic behavior of microservice systems. The current anomaly detection component used in this work, TraceRCA [2], addresses some aspects of change by periodically updating the distribution of service invocations. It also adopts a twofold historical reference strategy, leveraging both the immediate previous time slot and the same time slot from an earlier period to help distinguish true anomalies from transient noise. However, recent studies [77] emphasize the importance of scaling-aware anomaly detection in microservice environments. Dynamic changes such as autoscaling can introduce significant variability in service behavior, often masking true anomalies or generating false positives. To address this challenge, resource behavior modeling [78] can be employed to identify common patterns of service behavior during scaling events. Integrating such modeling techniques with anomaly detection components may allow CARE to more accurately differentiate genuine performance anomalies from expected fluctuations caused by infrastructure adaptations. Another gap in current anomaly detection approaches is their limited ability to detect resilient patterns, as noted in prior work [63], [64]. These patterns can obscure true service correlations and hinder accurate identification of propagation paths. To address this, CARE can be extended with an anomaly detection technique that detects the presence of such resilient patterns during anomalies. Once identified, the collected observability data can be adjusted accordingly. One potential strategy is correlation calibration [63], where original service metrics are replaced or augmented with values derived from their in-neighbor and out-neighbor services. This adjustment allows the system to update correlation paths more accurately by accounting for masking effects introduced by resilient patterns. Incorporating such mechanisms into CARE would improve its ability to correctly identify anomaly propagation paths even in complex, masked scenarios. REFERENCES [1] M. Panahandeh, A. Hamou-Lhadj, M. Hamdaqa, and J. Miller, “Serviceanomaly: An anomaly detection approach in microservices using distributed traces and profiling metrics,” Journal of Systems and Software, vol. 209, p. 111917, 2024. [2] Z. Li, J. Chen, R. Jiao, N. Zhao, Z. Wang, S. Zhang, Y. Wu, L. Jiang, L. Yan, Z. Wang et al., “Practical root cause localization for microservice systems via trace analysis,” in 2021 IEEE/ACM 29th International Symposium on Quality of Service (IWQOS). IEEE, 2021, pp. 1–10. [3] M. Camilli and B. Russo, “Modeling performance of microservices systems with growth theory,” Empirical Software Engineering, vol. 27, no. 2, p. 39, 2022. [4] J. Soldani and A. Brogi, “Anomaly detection and failure root cause analysis in (micro) service-based cloud applications: A survey,” ACM Computing Surveys (CSUR), vol. 55, no. 3, pp. 1–39, 2022. [5] I. Kohyarnejadfard, D. Aloise, S. V. Azhari, and M. R. Dagenais, “Anomaly detection in microservice environments using distributed tracing data analysis and nlp,” Journal of Cloud Computing, vol. 11, no. 1, p. 25, 2022. [6] A. Al-Said Ahmad, L. F. Al-Qora’n, and A. Zayed, “Exploring the impact of chaos engineering with various user loads on cloud native applications: an exploratory empirical study,” Computing, vol. 106, no. 7, pp. 2389– 2425, 2024. [7] X. Zhou, X. Peng, T. Xie, J. Sun, C. Ji, W. Li, and D. Ding, “Fault analysis and debugging of microservice systems: Industrial survey, benchmark system, and empirical study,” IEEE Transactions on Software Engineering, vol. 47, no. 2, pp. 243–260, 2021. 20 [8] B. Li, X. Peng, Q. Xiang, H. Wang, T. Xie, J. Sun, and X. Liu, “Enjoy your observability: an industrial survey of microservice tracing and analysis,” Empirical Software Engineering, vol. 27, pp. 1–28, 2022. [9] K. Aktas¸ and H. H. Kilinc, “Interaction prediction and anomaly detection in a microservices-based telecommunication platform,” ser. ICSSP ’24. New York, NY, USA: Association for Computing Machinery, 2024, p. 56–65. [Online]. Available: https://doi.org/10.1145/3666015.3666017 [10] G. Yu, Z. Huang, and P. Chen, “Tracerank: Abnormal service localization with dis-aggregated end-to-end tracing data in cloud native systems,” Journal of Software: Evolution and Process, p. e2413, 2021. [11] D. Liu, C. He, X. Peng, F. Lin, C. Zhang, S. Gong, Z. Li, J. Ou, and Z. Wu, “Microhecl: High-efficient root cause localization in large-scale microservice systems,” in 2021 IEEE/ACM 43rd International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP), 2021, pp. 338–347. [12] L. Wang, C. Zhang, R. Ding, Y. Xu, Q. Chen, W. Zou, Q. Chen, M. Zhang, X. Gao, H. Fan, S. Rajmohan, Q. Lin, and D. Zhang, “Root cause analysis for microservice systems via hierarchical reinforcement learning from human feedback,” in Proceedings of the 29th ACM SIGKDD Conference on Knowledge Discovery and Data Mining, ser. KDD ’23. New York, NY, USA: Association for Computing Machinery, 2023, p. 5116–5125. [Online]. Available: https://doi.org/10.1145/3580305.3599934 [13] L. Pham, H. Ha, and H. Zhang, “Root cause analysis for microservice system based on causal inference: How far are we?” in Proceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering, ser. ASE ’24. New York, NY, USA: Association for Computing Machinery, 2024, p. 706–715. [Online]. Available: https://doi.org/10.1145/3691620.3695065 [14] M. Kim, R. Sumbaly, and S. Shah, “Root cause detection in a serviceoriented architecture,” ACM SIGMETRICS Performance Evaluation Review, vol. 41, no. 1, pp. 93–104, 2013. [15] J. Weng, J. H. Wang, J. Yang, and Y. Yang, “Root cause analysis of anomalies of multitier services in public clouds,” IEEE/ACM Transactions on Networking, vol. 26, no. 4, pp. 1646–1659, 2018. [16] J. Thalheim, A. Rodrigues, I. E. Akkus, P. Bhatotia, R. Chen, B. Viswanath, L. Jiao, and C. Fetzer, “Sieve: Actionable insights from monitored metrics in distributed systems,” in Proceedings of the 18th ACM/IFIP/USENIX Middleware Conference, 2017, pp. 14–27. [17] J. Lin, P. Chen, and Z. Zheng, “Microscope: Pinpoint performance issues with causal graphs in micro-service environments,” in Service-Oriented Computing: 16th International Conference, ICSOC 2018, Hangzhou, China, November 12-15, 2018, Proceedings 16. Springer, 2018, pp. 3–20. [18] P. Liu, H. Xu, Q. Ouyang, R. Jiao, Z. Chen, S. Zhang, J. Yang, L. Mo, J. Zeng, W. Xue et al., “Unsupervised detection of microservice trace anomalies through service-level deep bayesian networks,” in 2020 IEEE 31st International Symposium on Software Reliability Engineering (ISSRE). IEEE, 2020, pp. 48–58. [19] L. Wu, J. Tordsson, J. Bogatinovski, E. Elmroth, and O. Kao, “Microdiag: Fine-grained performance diagnosis for microservice systems,” in 2021 IEEE/ACM International Workshop on Cloud Intelligence (CloudIntelligence), 2021, pp. 31–36. [20] Z. Li, N. Zhao, M. Li, X. Lu, L. Wang, D. Chang, X. Nie, L. Cao, W. Zhang, K. Sui et al., “Actionable and interpretable fault localization for recurring failures in online service systems,” in Proceedings of the 30th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering, 2022, pp. 996–1008. [21] X. Zhou, X. Peng, T. Xie, J. Sun, C. Ji, D. Liu, Q. Xiang, and C. He, “Latent error prediction and fault localization for microservice applications by learning from system trace logs,” in Proceedings of the 2019 27th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering, ser. ESEC/FSE 2019. New York, NY, USA: Association for Computing Machinery, 2019, p. 683–694. [Online]. Available: https://doi.org/10.1145/3338906.3338961 [22] L. Wu, J. Tordsson, E. Elmroth, and O. Kao, “Microrca: Root cause localization of performance issues in microservices,” in NOMS 2020-2020 IEEE/IFIP Network Operations and Management Symposium. IEEE, 2020, pp. 1–9. [23] M. Panahandeh, N. Ezzati-Jivan, A. Hamou-Lhadj, and J. Miller, “Context-aware root cause localization in distributed traces using social network analysis (work in progress paper),” in Companion of the 15th ACM/SPEC International Conference on Performance Engineering, 2024, pp. 1–6. [24] C. Lee, T. Yang, Z. Chen, Y. Su, and M. R. Lyu, “Eadro: An end-to-end troubleshooting framework for microservices on multi-source data,” in 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE). IEEE, 2023, pp. 1750–1762. [25] Z. Ye, P. Chen, and G. Yu, “T-rank:a lightweight spectrum based fault localization approach for microservice systems,” in 2021 IEEE/ACM 21st International Symposium on Cluster, Cloud and Internet Computing (CCGrid), 2021, pp. 416–425. [26] G. Yu, P. Chen, H. Chen, Z. Guan, Z. Huang, L. Jing, T. Weng, X. Sun, and X. Li, “Microrank: End-to-end latency issue localization with extended spectrum analysis in microservice environments,” in Proceedings of the Web Conference 2021, ser. WWW ’21. New York, NY, USA: Association for Computing Machinery, 2021, p. 3087–3098. [Online]. Available: https://doi.org/10.1145/3442381.3449905 [27] M. Panahandeh, N. Ezzati-Jivan, A. Hamou-Lhadj, and J. Miller, “Efficient unsupervised latency culprit ranking in distributed traces with gnn and critical path analysis,” in Companion of the 15th ACM/SPEC International Conference on Performance Engineering, 2024, pp. 62–66. [28] X. Zhou, X. Peng, T. Xie, J. Sun, C. Ji, W. Li, and D. Ding, “Fault analysis and debugging of microservice systems: Industrial survey, benchmark system, and empirical study,” IEEE Transactions on Software Engineering, vol. 47, no. 2, pp. 243–260, 2021. [29] Z. Li, N. Zhao, S. Zhang, Y. Sun, P. Chen, X. Wen, M. Ma, and D. Pei, “Constructing large-scale real-world benchmark datasets for aiops,” arXiv preprint arXiv:2208.03938, 2022. [30] O. Contributors, “Opentracing specification,” 2024, accessed: 2024-08-08. [Online]. Available: https://opentracing.io/specification/ [31] J. A. Jones, M. J. Harrold, and J. Stasko, “Visualization of test information to assist fault localization,” in Proceedings of the 24th international conference on Software engineering, 2002, pp. 467–477. [32] L. Naish, H. J. Lee, and K. Ramamohanarao, “A model for spectrabased software diagnosis,” ACM Transactions on software engineering and methodology (TOSEM), vol. 20, no. 3, pp. 1–32, 2011. [33] X. Li, W. Li, Y. Zhang, and L. Zhang, “Deepfl: Integrating multiple fault diagnosis dimensions for deep fault localization,” in Proceedings of the 28th ACM SIGSOFT international symposium on software testing and analysis, 2019, pp. 169–180. [34] B. Bischl, M. Binder, M. Lang, T. Pielok, J. Richter, S. Coors, J. Thomas, T. Ullmann, M. Becker, A.-L. Boulesteix et al., “Hyperparameter optimization: Foundations, algorithms, best practices, and open challenges,” Wiley Interdisciplinary Reviews: Data Mining and Knowledge Discovery, vol. 13, no. 2, p. e1484, 2023. [35] S. Luo, H. Xu, C. Lu, K. Ye, G. Xu, L. Zhang, Y. Ding, J. He, and C. Xu, “Characterizing microservice dependency and performance: Alibaba trace analysis,” in Proceedings of the ACM Symposium on Cloud Computing, 2021, pp. 412–426. [36] D. Easley, J. Kleinberg et al.,Networks, crowds, and markets: Reasoning about a highly connected world. Cambridge university press Cambridge, 2010, vol. 1. [37] V. D. Blondel, J.-L. Guillaume, R. Lambiotte, and E. Lefebvre, “Fast unfolding of communities in large networks,” Journal of statistical mechanics: theory and experiment, vol. 2008, no. 10, p. P10008, 2008. [38] M. Rosvall and C. T. Bergstrom, “Maps of random walks on complex networks reveal community structure,” Proceedings of the national academy of sciences, vol. 105, no. 4, pp. 1118–1123, 2008. [39] W. Hamilton, Z. Ying, and J. Leskovec, “Inductive representation learning on large graphs,” in Advances in Neural Information Processing Systems, vol. 30. Curran Associates, Inc., 2017. [40] A. Ng, M. Jordan, and Y. Weiss, “On spectral clustering: Analysis and an algorithm,” Advances in neural information processing systems, vol. 14, 2001. [41] P. J. Rousseeuw, “Silhouettes: a graphical aid to the interpretation and validation of cluster analysis,” Journal of computational and applied mathematics, vol. 20, pp. 53–65, 1987. [42] W. Xing and A. Ghorbani, “Weighted pagerank algorithm,” in Proceedings. Second Annual Conference on Communication Networks and Services Research, 2004., 2004, pp. 305–314. [43] J. M. Kleinberg, “Authoritative sources in a hyperlinked environment,” Journal of the ACM (JACM), vol. 46, no. 5, pp. 604–632, 1999. [44] L. C. Freeman, “A set of measures of centrality based on betweenness,” Sociometry, pp. 35–41, 1977. 21 [45] L. Chen, J. Wu, H. Yang, and K. Zhang, “Does pagerank apply to service ranking in microservice regression testing?” Software Quality Journal, vol. 30, no. 3, pp. 757–779, 2022. [46] J. A. P. Lima and S. R. Vergilio, “Test case prioritization in continuous integration environments: A systematic mapping study,” Information and Software Technology, vol. 121, p. 106268, 2020. [47] R. Abreu, P. Zoeteweij, R. Golsteijn, and A. J. Van Gemund, “A practical evaluation of spectrum-based fault localization,” Journal of Systems and Software, vol. 82, no. 11, pp. 1780–1792, 2009. [48] A. Arrieta, S. Segura, U. Markiegi, G. Sagardui, and L. Etxeberria, “Spectrum-based fault localization in software product lines,” Information and Software Technology, vol. 100, pp. 18–31, 2018. [Online]. Available: https://www.sciencedirect.com/science/article/pii/S095058491730188X [49] Z. Zhu, C. Lee, X. Tang, and P. He, “Hemirca: Fine-grained root cause analysis for microservices with heterogeneous data sources,” ACM Trans. Softw. Eng. Methodol., vol. 33, no. 8, Nov. 2024. [Online]. Available: https://doi.org/10.1145/3674726 [50] J. Chen, F. Liu, J. Jiang, G. Zhong, D. Xu, Z. Tan, and S. Shi, “Tracegra: A trace-based anomaly detection for microservice using graph deep learning,” Computer Communications, vol. 204, pp. 109–117, 2023. [51] P. M, H.-L. W, H. M, and M. J, “Serviceanomaly: An anomaly detection approach in microservices using distributed traces and profiling metrics,” 2023, available at SSRN: https://ssrn.com/abstract=4415639 or http://dx.doi.org/10.2139/ssrn.4415639. [52] P. S. Kochhar, X. Xia, D. Lo, and S. Li, “Practitioners’ expectations on automated fault localization,” in Proceedings of the 25th international symposium on software testing and analysis, 2016, pp. 165–176. [53] J. Jiang, R. Wang, Y. Xiong, X. Chen, and L. Zhang, “Combining spectrum-based fault localization and statistical debugging: An empirical study,” in 2019 34th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 2019, pp. 502–514. [54] E. Wong, T. Wei, Y. Qi, and L. Zhao, “A crosstab-based statistical method for effective fault localization,” in 2008 1st international conference on software testing, verification, and validation. IEEE, 2008, pp. 42–51. [55] S. Pearson, J. Campos, R. Just, G. Fraser, R. Abreu, M. D. Ernst, D. Pang, and B. Keller, “Evaluating and improving fault localization,” in 2017 IEEE/ACM 39th International Conference on Software Engineering (ICSE). IEEE, 2017, pp. 609–620. [56] A. Ajibode, T. Shu, K. Said, and Z. Ding, “A fault localization method based on metrics combination,” Mathematics, vol. 10, no. 14, p. 2425, 2022. [57] H. A. de Souza, D. Mutti, M. L. Chaim, and F. Kon, “Contextualizing spectrum-based fault localization,” Information and software technology, vol. 94, pp. 245–261, 2018. [58] Q. I. Sarhan and ´ A. Besz´ edes, “Effective spectrum based fault localization using contextual based importance weight,” in International Conference on the Quality of Information and Communications Technology. Springer, 2022, pp. 93–107. [59] D. Callaghan and B. Fischer, “Improving spectrum-based localization of multiple faults by iterative test suite reduction,” in Proceedings of the 32nd ACM SIGSOFT International Symposium on Software Testing and Analysis, 2023, pp. 1445–1457. [60] G. Zhao, H. He, and Y. Huang, “Fault centrality: boosting spectrum-based fault localization via local influence calculation,” Applied Intelligence, pp. 1–23, 2022. [61] Q. I. Sarhan and ´ A. Besz´ edes, “A survey of challenges in spectrum-based software fault localization,” IEEE Access, vol. 10, pp. 10 618–10 639, 2022. [62] V. Heorhiadi, S. Rajagopalan, H. Jamjoom, M. K. Reiter, and V. Sekar, “Gremlin: Systematic resilience testing of microservices,” in 2016 IEEE 36th International Conference on Distributed Computing Systems (ICDCS), 2016, pp. 57–66. [63] M. Ma, W. Lin, D. Pan, and P. Wang, “Servicerank: Root cause identification of anomaly in large-scale microservice architectures,” IEEE Transactions on Dependable and Secure Computing, vol. 19, no. 5, pp. 3087–3100, 2022. [64] W. Tian, H. Zhang, N. Yang, and Y. Zhang, “Graph-based root cause localization in microservice systems with protection mechanisms,” International Journal of Software Engineering and Knowledge Engineering, vol. 33, no. 08, pp. 1211–1238, 2023. [65] M. Christakis, M. Heizmann, M. N. Mansur, C. Schilling, and V. W¨ ustholz, “Semantic fault localization and suspiciousness ranking,” in Tools and Algorithms for the Construction and Analysis of Systems: 25th International Conference, TACAS 2019, Held as Part of the European Joint Conferences on Theory and Practice of Software, ETAPS 2019, Prague, Czech Republic, April 6–11, 2019, Proceedings, Part I 25. Springer, 2019, pp. 226–243. [66] F. Lin, K. Muzumdar, N. P. Laptev, M.-V. Curelea, S. Lee, and S. Sankar, “Fast dimensional analysis for root cause investigation in a large-scale service environment,” Proc. ACM Meas. Anal. Comput. Syst., vol. 4, no. 2, jun 2020. [Online]. Available: https://doi.org/10.1145/3392149 [67] M. Zhang, Y. Li, X. Li, L. Chen, Y. Zhang, L. Zhang, and S. Khurshid, “An empirical study of boosting spectrum-based fault localization via pagerank,” IEEE Transactions on Software Engineering, vol. 47, no. 6, pp. 1089–1113, 2019. [68] R. Abreu, P. Zoeteweij, and A. J. Van Gemund, “On the accuracy of spectrum-based fault localization,” in Testing: Academic and industrial conference practice and research techniques-MUTATION (TAICPARTMUTATION 2007). IEEE, 2007, pp. 89–98. [69] S. Shimizu, T. Inazumi, Y. Sogawa, A. Hyvarinen, Y. Kawahara, T. Washio, P. O. Hoyer, K. Bollen, and P. Hoyer, “Directlingam: A direct method for learning a linear non-gaussian structural equation model,” Journal of Machine Learning Research-JMLR, vol. 12, no. Apr, pp. 1225– 1248, 2011. [70] C. W. Granger, “Investigating causal relations by econometric models and cross-spectral methods,” Econometrica: journal of the Econometric Society, pp. 424–438, 1969. [71] A. Arnold, Y. Liu, and N. Abe, “Temporal causal modeling with graphical granger methods,” in Proceedings of the 13th ACM SIGKDD international conference on Knowledge discovery and data mining, 2007, pp. 66–75. [72] M. Ma, J. Xu, Y. Wang, P. Chen, Z. Zhang, and P. Wang, “Automap: Diagnose your microservice-based web applications automatically,” in Proceedings of The Web Conference 2020, 2020, pp. 246–258. [73] P. Spirtes, C. Glymour, and R. Scheines, Causation, prediction, and search. MIT press, 2001. [74] G. Yu, P. Chen, Y. Li, H. Chen, X. Li, and Z. Zheng, “Nezha: Interpretable fine-grained root causes analysis for microservices on multi-modal observability data,” in Proceedings of the 31st ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering, 2023, pp. 553–565. [75] A. G. Hawkes, “Markov processes in apl,” ACM SIGAPL APL Quote Quad, vol. 20, no. 4, pp. 173–185, 1990. [76] C. Lea, R. Vidal, A. Reiter, and G. D. Hager, “Temporal convolutional networks: A unified approach to action segmentation,” in Computer Vision–ECCV 2016 Workshops: Amsterdam, The Netherlands, October 8-10 and 15-16, 2016, Proceedings, Part III 14. Springer, 2016, pp. 47–54. [77] Y. Matsuo and D. Ikegami, “Performance analysis of anomaly detection methods for application system on kubernetes with auto-scaling and selfhealing,” in 2021 17th International Conference on Network and Service Management (CNSM), 2021, pp. 464–472. [78] R. Ravichandiran, H. Bannazadeh, and A. Leon-Garcia, “Anomaly detection using resource behaviour analysis for autoscaling systems,” in 2018 4th IEEE Conference on Network Softwarization and Workshops (NetSoft), 2018, pp. 192–196.