Pith. sign in

REVIEW 5 major objections 8 minor 38 references

BSODiag: A Global Diagnosis Framework for Batch Servers Outage in Large-scale Cloud Infrastructure Systems

T0 review · 5 major / 8 minor · reviewed 2026-08-09 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read BSODiag claims that batch-server outages can be diagnosed by merging coarse-grained alerts, incidents, and changes into a single event cause graph, scoring 87.5% top-3 root-cause recall and 46.3% propagation-path coverage on a two-year…

desk verdict Credible industrial-system paper with a real year-split evaluation, but the undisclosed ground-truth labeling makes the headline path-coverage numbers hard to interpret without more transparency. read the letter →

arxiv 2502.15728 v1 pith:PGYPDK4G submitted 2025-01-31 cs.DC

Tao Duan , Runqing Chen , Pinghui Wang , Junzhou Zhao , Jiongzhou Liu , Shujie Han , Yi Liu , Fan Xu This is my paper · ORCID
classification cs.DC
keywords batchserversoutagecloudinfrastructurerootcauseanalysisfailurepropagationpathmulti-sourcemonitoringdatacorrelationeventgraphunsuperviseddiagnosis
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Batch-server outages—whole clusters of servers failing at once—are the most severe failure class in cloud infrastructure because they make every upstream service unavailable, and today's diagnosis relies on engineers manually reconciling alerts, incident tickets, and change records. The paper tries to establish that this diagnosis can be automated end-to-end without labels: detect failures genuinely related to the outage from all three coarse-grained streams, merge them into events, build a single event cause graph that combines historical failure co-occurrence with current device connectivity, and rank both the root cause and the failure propagation path. On a two-year dataset from a large production cloud, BSODiag reports 87.5% root-cause-in-top-three and 46.3% propagation-path coverage, beating the strongest compared baseline by 10.2 and 3.7 percentage points respectively. If that holds, infrastructure teams gain a lightweight, interpretable alternative to a slow, multi-specialty manual investigation.

What carries the argument

The central object is the event cause graph $G_e$: a directed graph whose nodes are the outage-related events detected from alerts, incidents, and changes, and whose edges are candidate trigger links. The paper assigns each edge a causal strength $w_{ij} = \exp(p_{ij}.conf) \cdot \mathrm{dist}(e_i, e_j)$, where $p_{ij}.conf$ is the confidence of the failure pair mined from historical data by an Apriori-based algorithm and filtered by an expert hierarchy tree, and $\mathrm{dist}(e_i, e_j)$ is the fraction of $e_i$'s devices that are physically connected to or shared with $e_j$ in the configuration management database (CMDB). This single formula carries the global-perspective argument: it fuses historical failure knowledge with current device dependencies. A customized multi-attribute random walk (MAPR) over $G_e$, seeded by each event's time before the outage and its connectivity to the outage node, produces the root-cause ranking; then a propagation-probability inference (PPI) selects the path from the top-ranked root cause to the outage node with the largest product of node scores.

What would settle it

Compare BSODiag's predicted cause-effect edges against engineer-confirmed repair histories on the 95 collected outage cases: if pairs with high confidence and high device overlap are frequently common effects of a third failure or co-located coincidences, the edge weights are not measuring propagation. A sharper test is to replace the expert hierarchy filter with pure temporal ordering, so that earlier events cause later ones, and see whether PR@3 and PCR hold; equal performance would show the causal signal does not depend on the claimed expert mechanism.

Watch

Extended reading notes

Core claim

BSODiag's central claim is that batch-server outages are diagnosable from the coarse-grained data a large cloud already records, provided the analysis is global rather than per-stream. Alerts alone flood and carry false positives; incidents alone omit minor failures; changes alone are optional high-risk actions—so the paper argues that genuine outage-related failures emerge only when all three are detected separately and then merged into events. The root cause, in turn, is not a single point but the head of a propagation process: the paper constructs an event cause graph whose directed edges encode how likely one event is to trigger another, combining the historical confidence mined from co-occurring failure pairs with the physical device-overlap ratio measured in the current outage, and then ranks nodes with a multi-attribute random walk. The same graph supports a propagation-probability search that returns the most likely path from the root cause to the outage node, which is what engineers actually inspect. The reported result is that this unsupervised pipeline outperforms rule-based, supervised, and prior failure-graph baselines across both root-cause localization and path inference.

Load-bearing premise

The load-bearing premise is that a failure pair observed together in the same data center on the same day, kept only when it fits an expert-ranked hierarchy of failure types, and scaled by how much the devices overlap physically, is a true cause-effect relation rather than a coincidence or a shared external cause.

Editorial extensions

If this is right

  • Because no single monitoring stream is sufficient, dropping alert, incident, or change fusion should degrade root-cause recall; the framework's gains over single-stream baselines are a direct test of this claim.
  • Historical failure co-occurrence filtered by an expert hierarchy tree plus current device overlap is enough to estimate causal strength without labeled outage data, so the method can be deployed in environments where labeled diagnoses are scarce.
  • Root-cause ranking and propagation-path inference come from one graph, so engineers can move directly from what broke to which sequence of devices to inspect and repair.
  • The framework's lightweight design enables a single diagnosis in 24.5 seconds in the reported deployment, compared with roughly 30 minutes for manual analysis, which changes how quickly an outage response can start.
  • As historical failure data accumulate, the failure knowledge graph improves and diagnostic performance rises to a plateau, implying the system gets better with deployment time.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Editorial extension: the edge-weight formula is not tied to any particular failure type, so the same event cause graph could be applied to other coarse-grained failure classes such as network partitions or power-chain faults by supplying the appropriate expert hierarchy tree and CMDB connectivity relation.
  • Editorial extension: because causal direction is only constrained by the expert tree rather than by temporal precedence within the outage window, a natural stress test is to reverse the hierarchy filter or add lag-correlation checks; the sensitivity of PR@3 would reveal how much of the causal claim is statistical versus expert-supplied.
  • Editorial extension: the headline accuracy figures come from one production environment with its own change whitelist, hierarchy tree, and support threshold, so porting BSODiag to another cloud would require re-tuning those components and the reported margins may not transfer unchanged.
  • Editorial extension: a stronger operational validation would track whether following the inferred propagation path actually prevents follow-on failures during repair, an outcome the paper mentions as motivation but does not measure.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

5 major / 8 minor

Summary. The paper proposes BSODiag, an unsupervised framework for diagnosing batch server outages in large-scale cloud infrastructure. It integrates multi-source monitoring data (alerts, incidents, and changes), detects outage-related failures, mines historical failure correlations using Apriori with an expert-provided failure rule tree, and combines this historical knowledge with current CMDB connectivity to build an event cause graph. A multi-attribute random walk (MAPR) localizes root causes, and a propagation-probability-based path inference (PPI) reconstructs failure propagation paths. The method is evaluated on Alibaba Cloud data with a 2022 training/2023 testing split, reporting PR@3=87.5% and PCR=46.3%, exceeding several baselines. The core claim is that global spatio-temporal modeling of failures improves both root cause localization and path inference.

Significance. If the reported results are valid, BSODiag is a practically valuable contribution to cloud infrastructure diagnosis: it operates on coarse-grained operational data, provides interpretable root cause and propagation path outputs, and is reported to be efficient. The temporal split between the failure knowledge graph construction (2022) and evaluation (2023) is a genuine strength, reducing the risk of self-fit. The paper uses real industrial data and compares against a reasonable set of baselines. However, the evaluation has critical gaps that currently prevent the central empirical claim from being accepted: the ground-truth labeling process is not described, no statistical uncertainty is reported, and the path inference formula is not a proper propagation probability. These issues are load-bearing because the headline claims are empirical superiority numbers.

major comments (5)
  1. [Section V-A1, V-A3; Section IV-B, IV-C1] The procedure for obtaining the ground-truth root cause rU and propagation path pU is never described. Section V-A1 only states that a 'large-scale testing platform' was built 'for outage data collection and verification,' but no annotation protocol, annotator qualifications, or validation steps are given. This is a serious omission because the method's edges and weights are built from the expert-provided failure rule tree (Section IV-B), historical co-occurrence (Section IV-B), and CMDB connectivity dist(ei, ej) (Section IV-C1). If the ground truth was generated by experts using the same hierarchy and connectivity information, then PR@3 and PCR would partially measure the method's fidelity to its own priors rather than independent diagnostic accuracy. The paper must specify exactly how rU and pU were obtained for each of the 68 outage cases in Dall, what information was available to the labelers, and how labeler disagreements were resolved.
  2. [Tables III and IV; Section V-A3] All reported metrics are point estimates without error bars, confidence intervals, or significance tests. With 68 outage cases in Dall, the claim that BSODiag 'significantly outperforms' baselines is not supported statistically. For example, on Dall the PR@3 margin over COT is 10.2 percentage points, which could be driven by a small number of cases. The authors should report per-case results, bootstrap confidence intervals, or a paired significance test (e.g., Wilcoxon signed-rank) for PR@1, PR@2, PR@3, MAP, and PCR. This is necessary to substantiate the core empirical claim.
  3. [Section IV-C3, PPI equation] The propagation path inference formula is not a valid propagation probability. The paper defines TransPr(pi) as the product of node personalization scores u_j along path pi, but these u_j are the converged random walk node scores, not transition probabilities. A path's propagation probability should be the product of edge weights (e.g., normalized wij) along the path. As written, the selected path maximizes a quantity with no stated probabilistic interpretation. The authors must redefine TransPr in terms of edge weights, or provide a justification for why the product of node personalization scores is a meaningful propagation probability. This is load-bearing because PCR is one of the two headline metrics.
  4. [Section V-A1 and Section IV] The method depends on several free parameters that are set 'based on diagnostic experience' without any sensitivity analysis: support threshold α, time slot length δ, event merge window η, snapshot initial window [−L,−T], diagnosis window [−T,T'], and MAPR iteration count L. Since these parameters are hand-chosen rather than learned, the robustness of the reported gains is unknown. The authors should provide a sensitivity analysis for at least α, δ, and the window sizes, and report how performance varies across reasonable values. Without this, it is unclear whether the claimed improvements are parameter-sensitive.
  5. [Section V-D, Figure 7] The ablation study is underspecified. For each ablation variant ('w/o FKG', 'w/o CMDB', 'w/o MAPR'), the exact modification to the pipeline is not described. For example, does removing FKG mean setting pij.conf to 1, or removing the historical edges entirely? Does removing CMDB mean setting dist(ei, ej) to 1? Does removing MAPR mean replacing the random walk with a simple ranking heuristic? Without these details, the reader cannot interpret the contribution of each component or rule out that the ablations are implemented in a way that unfairly degrades performance. The text should precisely define each ablation.
minor comments (8)
  1. [Algorithm 1, lines 7 and 16] The support threshold is applied as pij.count ≥ |Q2|·α, where |Q2| is the number of candidate pairs. Standard support is a frequency over the number of event groups, not over the number of unique items or pairs. Define the denominator explicitly; as written, the threshold is size-dependent in a way that does not match the support and confidence definitions in Section IV-B.
  2. [Section IV-C2, Eq. for ui] The node personalization score is defined as ui = exp(−t)·dist(ei, eo), but the variable t is not defined. Specify whether t is the time distance to outage, and in which units.
  3. [Figure 6] The y-axis label 'PRC' should be 'PCR' for consistency with the text.
  4. [Section IV-A] There is a typo in the opening paragraph: 'batch serves outage' should be 'batch servers outage'.
  5. [Section IV-B] The expert-provided failure rule tree and the change whitelist are key external inputs but are never described or exemplified. Please provide at least a small example of the rule tree structure and the whitelist criteria, or a reference to where they are defined.
  6. [Section V-E] The efficiency analysis reports an average diagnosis time of 24.5 seconds, but no hardware specifications, software versions, or variance across cases are given. Adding these details will help readers assess the claim of lightweight operation.
  7. [Table II] The sum of outage cases in Didc (19) and Dnet (47) is 66, while Dall has 68. Please clarify whether some outage cases have multi-domain root causes that place them in both subsets, and explain the overlap.
  8. [Section I] The claim of being 'the first to study the batch servers outage diagnosis problem' should be tempered, given prior outage analysis work in large-scale production clouds (e.g., COT [4] and AirAlert [1]). Consider phrasing the novelty more narrowly, e.g., as the first to jointly model root cause and propagation path for batch server outages from multi-source coarse-grained data.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the central evaluation uses a temporal split and external expert/CMDB inputs, not a self-fit.

full rationale

The claimed results are not by construction. The failure knowledge graph is initialized on Dinit (all 2022 monitoring data) and evaluated on 2023 outage cases (Didc, Dnet, Dall), which is a genuine temporal split. The expert-provided failure rule tree, SPOT detector, support threshold α, time windows, and CMDB connectivity are inputs fixed before evaluation, not outputs fitted to the 2023 labels. The MAPR and PPI formulas (wij = exp(pij.conf)·dist(ei,ej); pU = argmax of the product of ¯uj) do not reduce to the evaluation metrics unless the ground-truth paths are generated by the same rule tree and CMDB, which the paper does not state. The absence of any description of how rU and the ground-truth propagation path were labeled is a reproducibility and verification weakness, not a demonstrated circular step; per the hard rules, speculation about label construction cannot justify a circularity score. The only apparent self-citation is background reference [19] and is not load-bearing. Therefore no circular step is flagged and the score is 0.

Assumptions & free parameters 6 free parameters · 5 assumptions · 0 invented entities

The framework depends on a small number of hand-set hyperparameters and on domain assumptions about what co-occurrence, alert pattern change, and device connectivity imply about causality. None of these are fitted to test labels, but several are expert-supplied and could encode the same knowledge that the evaluation uses.

free parameters (6)
  • Support threshold α = 0.001
    Minimum relative frequency for a failure pair to be kept in the failure knowledge graph (Algorithm 1, Section V-A).
  • Time slot length δ = 1 minute
    Granularity of the alert-to-time-series aggregation in Alert2TS (Section V-A).
  • Event merge window η = 5 minutes
    Window used to merge similar failures into events (Section V-A).
  • Snapshot initial window [−L, −T] = [−4, −2] hours
    Assumed normal-alert baseline period, set by diagnostic experience (Section V-A).
  • Diagnosis window [−T, T'] = [−2, 0.25] hours
    The period from which outage-related failures are collected (Section V-A).
  • MAPR iterations L = 100
    Random walk iterations; convergence is asserted but not analyzed (Section V-A).
assumptions (5)
  • domain assumption High-confidence co-occurrence of failure types in the same data center and day implies a causal correlation f_a -> f_b.
    The FCM module treats support and confidence over historical event groups as causal strength, Section IV-B.
  • domain assumption Only upper-level failures in the expert failure rule tree can trigger lower-level failures.
    Algorithm 1 Line 12 prunes all failure pairs that do not respect this hierarchy, Section IV-B.
  • domain assumption Alerts whose pattern changes in the diagnosis window versus the baseline window are outage-related; stable alert patterns are noise.
    Section IV-A1 Failure Detection uses SPOT with initial window [−L, −T] as the normal pattern.
  • domain assumption Only proactive changes can cause failures; passive changes are irrelevant.
    Section IV-A2 Change Filter uses a whitelist to retain only proactive changes.
  • domain assumption The CMDB overlap ratio dist(e_i, e_j) between connected devices measures the probability of failure propagation in the current outage.
    Section IV-C1 edge weight equation w_ij = exp(p_ij.conf) * dist(e_i, e_j).

how reviews work

0 comments
Cite this review

Pith. "Pith review of BSODiag: A Global Diagnosis Framework for Batch Servers Outage in Large-scale Cloud Infrastructure Systems." pith.science (2026). https://pith.science/paper/PGYPDK4G

@misc{pith2026250215728,
  author       = {Pith},
  title        = {Pith review of: BSODiag: A Global Diagnosis Framework for Batch Servers Outage in Large-scale Cloud Infrastructure Systems},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/PGYPDK4G}},
  note         = {Machine review of arXiv:2502.15728}
}
read the original abstract

Cloud infrastructure is the collective term for all physical devices within cloud systems. Failures within the cloud infrastructure system can severely compromise the stability and availability of cloud services. Particularly, batch servers outage, which is the most fatal failure, could result in the complete unavailability of all upstream services. In this work, we focus on the batch servers outage diagnosis problem, aiming to accurately and promptly analyze the root cause of outages to facilitate troubleshooting. However, our empirical study conducted in a real industrial system indicates that it is a challenging task. Firstly, the collected single-modal coarse-grained failure monitoring data (i.e., alert, incident, or change) in the cloud infrastructure system is insufficient for a comprehensive failure profiling. Secondly, due to the intricate dependencies among devices, outages are often the cumulative result of multiple failures, but correlations between failures are difficult to ascertain. To address these problems, we propose BSODiag, an unsupervised and lightweight diagnosis framework for batch servers outage. BSODiag provides a global analytical perspective, thoroughly explores failure information from multi-source monitoring data, models the spatio-temporal correlations among failures, and delivers accurate and interpretable diagnostic results. Experiments conducted on the Alibaba Cloud infrastructure system show that BSODiag achieves 87.5% PR@3 and 46.3% PCR, outperforming baseline methods by 10.2% and 3.7%, respectively.

Figures

Figures reproduced from arXiv: 2502.15728 by the authors.

Figure 1
Figure 1. The life cycle of a batch servers outage diagnosis. [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. Different failure monitoring data collected in cloud infrastructure system. [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Analysis of root causes and failure correlations. [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figures from the paper (3 more)
Figure 5
Figure 5. Figure 5: The overview of BSODiag • Outage root cause analysis sub-problem takes E as input, locates the top-k root cause set SU of the outage and infers the failure propagation path pU through a localizer M: E 7→ {er, pU }. IV. METHODOLOGY The empirical observations in Section …
Figure 6
Figure 6. Figure 6: The online deployment performance of BSODiag. [PITH_FULL_IMAGE:figures/full_fig_p009_6.png]
Figure 7
Figure 7. Figure 7: Ablation study 0s 10s 20s 70s 30min Rule-based ML-based AirAlert CoT BSODiag Manual Failure Analysis Failure Location [PITH_FULL_IMAGE:figures/full_fig_p009_7.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

38 extracted references · 36 canonical work pages

  1. [1]

    Outage prediction and diagnosis for cloud service systems,

    C. Chen, X. Yang, Q. Lin, H. Zhang, F. Gao, Z. Xu, Y . Dang, D. Zhang, H. Dong, Y . Xu, H. Li, and Y . Kang, “Outage prediction and diagnosis for cloud service systems,” in ACM WWW, 2019, pp. 2659–2665

    work page 2019

  2. [2]

    Top 10 cloud platform service providers in 2024,

    GeeksforGeeks, “Top 10 cloud platform service providers in 2024,” 2024, https://www.geeksforgeeks.org/top-cloud-platform-service- providers/

    work page 2024

  3. [3]

    Service outage in zone C of the China (Hong Kong) region,

    A. Cloud, “Service outage in zone C of the China (Hong Kong) region,” 2022, https://www.alibabacloud.com/en/notice/066572

    work page 2022

  4. [4]

    Fast outage analysis of large-scale production clouds with service correlation mining,

    Y . Wang, G. Li, Z. Wang, Y . Kang, Y . Zhou, H. Zhang, F. Gao, J. Sun, L. Yang, P. Lee, Z. Xu, P. Zhao, B. Qiao, L. Li, X. Zhang, and Q. Lin, “Fast outage analysis of large-scale production clouds with service correlation mining,” in IEEE/ACM ICSE, 2021

    work page 2021

  5. [5]

    Diagnosing root causes of intermittent slow queries in cloud databases,

    M. Ma, Z. Yin, S. Zhang, S. Wang, C. Zheng, X. Jiang, H. Hu, C. Luo, Y . Li, N. Qiuet al., “Diagnosing root causes of intermittent slow queries in cloud databases,” Proceedings of the VLDB Endowment , vol. 13, pp. 1176–1189, 2020

    work page 2020

  6. [6]

    Root cause analysis of failures in microservices through causal discovery,

    A. Ikram, S. Chakraborty, S. Mitra, S. Saini, S. Bagchi, and M. Ko- caoglu, “Root cause analysis of failures in microservices through causal discovery,”Advances in Neural Information Processing Systems, vol. 35, pp. 31 158–31 170, 2022

    2022

  7. [7]

    Servicerank: Root cause identification of anomaly in large-scale microservice architectures,

    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, pp. 3087–3100, 2021

    work page 2021

  8. [8]

    Actionable and interpretable fault localization for recurring failures in online service systems,

    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 ACM FSE/ESEC , 2022

    work page 2022

Show all 38 references
  1. [9]

    Efficient KPI anomaly detection through transfer learning for large-scale web services,

    S. Zhang, Z. Zhong, D. Li, Q. Fan, Y . Sun, M. Zhu, Y . Zhang, D. Pei, J. Sun, Y . Liu et al., “Efficient KPI anomaly detection through transfer learning for large-scale web services,” IEEE Journal on Selected Areas in Communications, vol. 40, pp. 2440–2455, 2022

    2022

  2. [10]

    Loganomaly: Unsupervised detection of sequential and quantitative anomalies in unstructured logs

    W. Meng, Y . Liu, Y . Zhu, S. Zhang, D. Pei, Y . Liu, Y . Chen, R. Zhang, S. Tao, P. Sunet al., “Loganomaly: Unsupervised detection of sequential and quantitative anomalies in unstructured logs.” in IJCAI, 2019

    2019

  3. [11]

    Unsupervised detection of microservice trace anomalies through service-level deep bayesian networks,

    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 IEEE ISSRE, 2020

    2020

  4. [12]

    Tele-knowledge pre-training for fault analysis,

    Z. Chen, W. Zhang, Y . Huang, M. Chen, Y . Geng, H. Yu, Z. Bi, Y . Zhang, Z. Yao, W. Song et al., “Tele-knowledge pre-training for fault analysis,” in IEEE ICDE, 2023

    2023

  5. [13]

    Understanding and handling alert storm for online service systems,

    N. Zhao, J. Chen, X. Peng, H. Wang, X. Wu, Y . Zhang, Z. Chen, X. Zheng, X. Nie, G. Wang et al. , “Understanding and handling alert storm for online service systems,” in ACM/IEEE ICSE, 2020

    2020

  6. [14]

    Towards intelligent incident management: why we need it and how we make it,

    Z. Chen, Y . Kang, L. Li, X. Zhang, H. Zhang, H. Xu, Y . Zhou, L. Yang, J. Sun, Z. Xu et al., “Towards intelligent incident management: why we need it and how we make it,” in EuroSys, 2020

    2020

  7. [15]

    Identifying root-cause changes for user-reported incidents in online service systems,

    Y . Zhao, L. Jiang, Y . Tao, S. Zhang, C. Wu, T. Jia, X. Huang, Y . Li, and Z. Wu, “Identifying root-cause changes for user-reported incidents in online service systems,” in IEEE ISSRE, 2023

    2023

  8. [16]

    ESRO: Experience assisted service reliability against outages,

    S. Chakraborty, S. Agarwal, S. Garg, A. Sethia, U. N. Pandey, V . Aggar- wal, and S. Saini, “ESRO: Experience assisted service reliability against outages,” in IEEE/ACM ASE, 2023

    2023

  9. [17]

    Groot: An event-graph-based approach for root cause analysis in industrial settings,

    H. Wang, Z. Wu, H. Jiang, Y . Huang, J. Wang, S. Kopru, and T. Xie, “Groot: An event-graph-based approach for root cause analysis in industrial settings,” in IEEE/ACM ASE, 2021

    2021

  10. [18]

    Passive realtime datacenter fault detection and localization,

    A. Roy, H. Zeng, J. Bagga, and A. C. Snoeren, “Passive realtime datacenter fault detection and localization,” in USENIX NSDI, 2017

    2017

  11. [19]

    Automated intelligent healing in cloud-scale data centers,

    R. Li, Z. Cheng, P. P. Lee, P. Wang, Y . Qiang, L. Lan, C. He, J. Lu, M. Wang, and X. Ding, “Automated intelligent healing in cloud-scale data centers,” in SRDS, 2021

    2021

  12. [20]

    Eadro: An end-to-end troubleshooting framework for microservices on multi-source data,

    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 IEEE/ACM ICSE, 2023

    2023

  13. [21]

    Robust multimodal failure detection for microservice systems,

    C. Zhao, M. Ma, Z. Zhong, S. Zhang, Z. Tan, X. Xiong, L. Yu, J. Feng, Y . Sun, Y . Zhang et al. , “Robust multimodal failure detection for microservice systems,” in ACM SIGKDD, 2023

    2023

  14. [22]

    Detecting and localizing end-to-end performance degradation for cellular data services based on tcp loss ratio and round trip time,

    F. Ahmed, J. Erman, Z. Ge, A. X. Liu, J. Wang, and H. Yan, “Detecting and localizing end-to-end performance degradation for cellular data services based on tcp loss ratio and round trip time,” IEEE/ACM Transactions on Networking , vol. 25, pp. 3709–3722, 2017

    2017

  15. [23]

    An improved apriori algorithm for association rules,

    M. Al-Maolegi and B. Arkok, “An improved apriori algorithm for association rules,” arXiv preprint arXiv:1403.3948 , 2014

    2014 arXiv

  16. [24]

    Microhecl: High-efficient root cause localization in large-scale microservice systems,

    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 IEEE/ACM ICSE, 2021

    2021

  17. [25]

    Localizing failure root causes in a microservice through causality inference,

    Y . Meng, S. Zhang, Y . Sun, R. Zhang, Z. Hu, Y . Zhang, C. Jia, Z. Wang, and D. Pei, “Localizing failure root causes in a microservice through causality inference,” in IEEE/ACM IWQoS, 2020

    2020

  18. [26]

    Learning high-dimensional directed acyclic graphs with latent and selection variables,

    D. Colombo, M. H. Maathuis, M. Kalisch, and T. S. Richardson, “Learning high-dimensional directed acyclic graphs with latent and selection variables,” The Annals of Statistics , pp. 294–321, 2012

    2012

  19. [27]

    AutoMAP: Diagnose your microservice-based web applications automatically,

    M. Ma, J. Xu, Y . Wang, P. Chen, Z. Zhang, and P. Wang, “AutoMAP: Diagnose your microservice-based web applications automatically,” in ACM WWW, 2020

    2020

  20. [28]

    Efficient and robust KPI outlier detection for large-scale datacenters,

    Y . Sun, D. Cheng, T. Yang, Y . Ji, S. Zhang, M. Zhu, X. Xiong, Q. Fan, M. Liang, D. Pei et al., “Efficient and robust KPI outlier detection for large-scale datacenters,” IEEE Transactions on Computers , vol. 72, pp. 2858–2871, 2023

    2023

  21. [29]

    Anomaly detec- tion in streams with extreme value theory,

    A. Siffer, P.-A. Fouque, A. Termier, and C. Largouet, “Anomaly detec- tion in streams with extreme value theory,” in ACM SIGKDD, 2017

    2017

  22. [30]

    Deeplog: Anomaly detection and diagnosis from system logs through deep learning,

    M. Du, F. Li, G. Zheng, and V . Srikumar, “Deeplog: Anomaly detection and diagnosis from system logs through deep learning,” in ACM CCS, 2017

    2017

  23. [31]

    Robust and transferable log-based anomaly detection,

    P. Jia, S. Cai, B. C. Ooi, P. Wang, and Y . Xiong, “Robust and transferable log-based anomaly detection,” Proceedings of the ACM on Management of Data, vol. 1, pp. 1–26, 2023

    2023

  24. [32]

    Unsupervised anomaly detection on microservice traces through graph vae,

    Z. Xie, H. Xu, W. Chen, W. Li, H. Jiang, L. Su, H. Wang, and D. Pei, “Unsupervised anomaly detection on microservice traces through graph vae,” in ACM WWW, 2023

    2023

  25. [33]

    Automatic root cause analysis via large language models for cloud incidents,

    Y . Chen, H. Xie, M. Ma, Y . Kang, X. Gao, L. Shi, Y . Cao, X. Gao, H. Fan, M. Wen et al., “Automatic root cause analysis via large language models for cloud incidents,” in EuroSys, 2024

    2024

  26. [34]

    Anomaly detection and failure root cause analysis in (micro) service-based cloud applications: A survey,

    J. Soldani and A. Brogi, “Anomaly detection and failure root cause analysis in (micro) service-based cloud applications: A survey,” ACM Computing Surveys, vol. 55, pp. 1–39, 2022

    2022

  27. [35]

    Hotspot: Anomaly localization for additive kpis with multi-dimensional attributes,

    Y . Sun, Y . Zhao, Y . Su, D. Liu, X. Nie, Y . Meng, S. Cheng, D. Pei, S. Zhang, X. Qu et al. , “Hotspot: Anomaly localization for additive kpis with multi-dimensional attributes,” IEEE Access, vol. 6, pp. 10 909– 10 923, 2018

    2018

  28. [36]

    Graph-based incident aggregation for large-scale online service systems,

    Z. Chen, J. Liu, Y . Su, H. Zhang, X. Wen, X. Ling, Y . Yang, and M. R. Lyu, “Graph-based incident aggregation for large-scale online service systems,” in IEEE/ACM ASE. IEEE, 2021, pp. 430–442

    2021

  29. [37]

    Microrca: Root cause localization of performance issues in microservices,

    L. Wu, J. Tordsson, E. Elmroth, and O. Kao, “Microrca: Root cause localization of performance issues in microservices,” in IEEE/IFIP Network Operations and Management Symposium , 2020

    2020

  30. [38]

    Practical root cause localization for microservice systems via trace analysis,

    Z. Li, J. Chen, R. Jiao, N. Zhao, Z. Wang, S. Zhang, Y . Wu, L. Jiang, L. Yan, Z. Wanget al., “Practical root cause localization for microservice systems via trace analysis,” in IEEE/ACM IWQOS, 2021

    2021

Pith tools

Reviewed August 9, 2026 · model on record in the stance chip above.