Pith. sign in

REVIEW 4 major objections 7 minor 53 references

AnomalyGen: An Automated Semantic Log Sequence Generation Framework with LLM for Anomaly Detection

T0 review · 4 major / 7 minor · reviewed 2026-08-16 · deepseek-v4-flash

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

Pith's one-line read AnomalyGen shows that LLM-guided static analysis can synthesize log datasets with 38–95 times more event types than current benchmarks, lifting anomaly-detection F1 by up to 3.7 points.

desk verdict A genuinely new combination of static analysis and LLM reasoning for log generation, but the headline coverage metric rests on a self-defined denominator and the downstream gain is thin; deserves a serious referee, not acceptance yet. read the letter →

arxiv 2504.12250 v1 pith:4JTQXYO5 submitted 2025-04-16 cs.SE

Xinyu Li , Yingtong Huo , Chenxi Mao , Shiwen Shan , Yuxin Su , Dan Li , Zibin Zheng This is my paper · ORCID
classification cs.SE
keywords loganomalydetectionsequencegenerationlargelanguagemodelschain-of-thoughtstaticprogramanalysiscontrolflowgraphsynthetictrainingdata
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

The paper argues that the scarcity and narrowness of public log datasets can be solved by generating synthetic log sequences without executing the target system. It presents AnomalyGen, a four-phase pipeline that prunes a program's call graph to logging-related code, builds fine-grained control-flow graphs with help from a large language model, recursively merges per-method log sequences under chain-of-thought verification, and labels anomalies using explicit and implicit rules. On two widely used distributed systems, the framework generates logs covering 38 to 95 times more log event types than the existing benchmark datasets, with an average reported coverage of 97.48% of all log events in the code. Adding these generated logs to the benchmarks' training data improves F1 scores across three anomaly detection architectures, with an average gain of 1.8 percentage points and a maximum of 3.7. The significance, if the claims hold, is a low-cost path to richer and more realistic training data for log-based anomaly detection.

What carries the argument

The load-bearing mechanism is the enhanced control-flow graph (Enhanced_CFG), a per-method graph built from the ternary tuple $\langle\text{Source Code}, \text{Call Path}, \text{Log-Oriented CFG}\rangle$. An LLM refines it through five verification steps: call matching and completion, exception-path augmentation, log-flow association, path-constraint handling, and execution-log consistency checking. The second load-bearing component is the chain-of-thought recursive merge, which joins child-method sequences into parent sequences bottom-up while checking control-flow consistency, data-flow integrity, and call-point correlation at each merge. This pairing of a code-grounded graph with LLM reasoning is what allows realistic log sequences to be produced without executing the system.

What would settle it

A direct check is to independently enumerate all reachable logging statements in the same two system versions—for example, by instrumenting the systems and comparing runtime log events with the paper's totals of 9,662 and 2,889—and recompute coverage; if the independently established totals are substantially lower, the coverage claims fail. A second test is to train a detector on generated data alone and measure its F1 on held-out real production logs; if it drops sharply, the simulated parameter distributions are not representative.

Watch

Extended reading notes

Core claim

The central discovery is that the blind spots of static analysis can be filled by a large language model without giving up the structural guarantees of a call graph: the model supplies dynamic dispatch, exception paths, and runtime parameter values, while the graph structure keeps the generated sequences tied to real code layout. AnomalyGen computes, for each logging-related method, an enhanced control-flow graph from a ternary of source code, call path, and log-oriented control-flow graph; it then simulates a call stack from the bottom up, asking the LLM to verify control-flow consistency, data-flow integrity, and call-point correlation at every merge. The paper reports that this execution-free process covers 97.48% of the log events it identifies in the code, expands event-type coverage 38-fold to 95-fold over the baselines, and, when added to benchmark training sets, improves F1 by up to 3.7 points (average 1.8) across LSTM, Transformer, and CNN detectors.

Load-bearing premise

The coverage figures rest on the paper's own count of how many log events exist in each system's source code; if that total is inflated, the claimed 38–95x coverage improvements shrink.

Editorial extensions

If this is right

  • Training anomaly detectors on benchmark data augmented with AnomalyGen logs improves F1 scores on the HDFS anomaly detection task: LSTM rises from 0.917 to 0.954, Transformer from 0.852 to 0.867, and CNN from 0.969 to 0.971.
  • The generated datasets provide 38–95 times more log event types than the existing benchmarks, which should let detectors train on a wider variety of anomaly-prone paths and reduce failures on unseen log events.
  • Because each generated sequence carries its execution context and annotated anomaly label, the dataset supports root-cause tracing; the paper reports that matching a log to its control flow takes less than one-fifth of the time it took with manually reconstructed mappings.
  • The framework needs no system execution, only source code and a call graph, so it can be applied to other Java systems with manageable configuration effort.

Reading between the lines

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

  • The coverage ratios are computed against a denominator the paper derives from its own static analysis; an independent enumeration of reachable logging statements could yield a smaller 'total log events' count and lower the reported 38–95x improvements.
  • Because the LLM simulates runtime parameters instead of observing them, generated datasets may carry distributional biases; a testable extension would be to measure how well a detector trained solely on AnomalyGen logs transfers to real production logs.
  • The same chain-of-thought verified recursive merge could be applied beyond logging, for instance to synthesize API call traces or event sequences for testing, whenever source code and a call graph are available.
  • The rule-based anomaly annotation is tied to explicit keywords and error codes; extending it with patterns mined from past incident reports would likely capture more implicit anomaly types than the current hand-crafted rules.
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

4 major / 7 minor

Summary. The paper presents AnomalyGen, a four-phase automated log synthesis framework that combines static call-graph analysis with LLM chain-of-thought reasoning to generate log sequences and anomaly labels for Hadoop and HDFS without executing the system. The claimed contributions are (i) a 38x-95x increase in log event coverage over existing datasets, (ii) more realistic log sequences than static-analysis-only tools, (iii) retention of execution-context semantics, and (iv) F1-score improvements of up to 3.7 percentage points (average 1.8) when augmenting LSTM, Transformer, and CNN anomaly detectors. The evaluation is based on two systems and three detectors, with the quantitative claims appearing in Tables 2 and 3.

Significance. The problem is relevant and timely: public log datasets are scarce, and LLM-assisted generation is an active research direction. If the coverage and realism claims were rigorously supported, AnomalyGen would be a useful contribution, and the authors' decision to release artifacts is commendable. However, the headline coverage claim depends on a self-defined denominator, and the detection gain rests on what appears to be a single unseeded run; these issues must be addressed before the quantitative claims can be accepted. The paper combines established program-analysis techniques with LLM reasoning in a plausible architecture, but the current evidence does not yet substantiate the magnitude of the reported improvements.

major comments (4)
  1. [Section 5.1 / Table 2] The coverage metric uses Total_Log_Event = 9,662 (Hadoop) and 2,889 (HDFS), obtained from AnomalyGen's own static analysis of Hadoop 3.3.6, while the comparison datasets (R-Hadoop, R-HDFS, LHub-Hadoop, LHub-HDFS) originate from different source versions and workloads; the paper itself admits version-related filtering in Section 5.2. Because the denominator is self-constructed and version-mismatched, the reported 38x-95x increment may reflect enumeration choices rather than a genuine deficiency of existing datasets, and the R-coverage validation against LogHub events checks recall on the small observed event set but does not validate the denominator. Please provide an independent, version-matched enumeration of the expected log event vocabulary, or explicitly restrict all coverage claims to the ratio between generated and existing event counts and rephrase the headline accordingly.
  2. [Table 3 / Section 5.5] The anomaly-detection gain is reported from what appears to be a single run on HDFS with no error bars, no random seeds, and no statistical significance tests; the observed improvements (average 1.8 percentage points, maximum 3.7 points) are small relative to typical run-to-run variance of LSTM, Transformer, and CNN models on this benchmark. The claim that AnomalyGen benefits anomaly detection requires multiple independent runs with statistical testing, and the authors should either report results on the Hadoop dataset as well or justify the single-system scope.
  3. [Section 5.3 / RQ2] The realism claim is supported primarily by qualitative code examples (Figures 8-10) and an informal statement in Section 5.4 that practitioners "save more than 5 times" the time, with no measurement procedure, sample size, or quantitative metric described. Without an operational definition of realism (e.g., a controlled user study, comparison of generated parameter distributions against runtime traces, or downstream performance on injected real anomalies), the claim that AnomalyGen produces "more realistic log sequences" than AutoLog and other static-analysis tools is not substantiated.
  4. [Section 6 / Phase III] The paper acknowledges LLM reasoning uncertainty and randomness in Section 6 but supplies no evaluation of the CoT verification's false-acceptance or false-rejection rates, nor of the fraction of generated paths that pass manual expert review. Because the LLM is a load-bearing component for path completion, parameter simulation, and anomaly annotation, the framework needs at least a reliability or error analysis on a sample of generated sequences so that the impact of LLM mistakes on the final dataset can be assessed.
minor comments (7)
  1. [Table 3] The header contains a typo: "Wtihout/With AG" should be "Without/With AG".
  2. [Section 5.2 / Table 2] The reported coverage increments are inconsistent across the text: the abstract and intro say "38-95x", Section 5.2 says "37 to 94 times" and "95.3 times", and Table 2 lists 38X, 86X, 95X, and 191X; these should be aligned.
  3. [Section 2.3 / Section 3.1] There is duplicated text in Section 3.1 (the overview paragraph appears twice) and similar repetition in the introduction; the writing needs careful editing for conciseness.
  4. [Section 1] The citation to Busse et al. appears as "Busse et al.[? ]" and should be completed with the proper reference key.
  5. [Table 1 and throughout] The paper uses both "D-Hadoop"/"D-HDFS" and "R-Hadoop"/"R-HDFS" for the same benchmark datasets; unify the naming to avoid confusion.
  6. [Section 1 / Section 8] The statement that "All artifacts and datasets have been released" is not accompanied by a URL or repository identifier; please provide this information.
  7. [Figure 2] The caption contains a typo: "Four Satges" should be "Four Stages".

Circularity Check

1 steps flagged · score 2.0 of 10

The 38–95x coverage claim is computed against AnomalyGen's own source-derived event total, making it partly self-referential; the F1-augmentation evaluation is not circular.

  1. self definitional [Table 2 (RQ1), with coverage metric defined in Section 5.1]
    "R-Hadoop 242 2.50%(242/9662) - 38X; AG-Hadoop 9225 95.48%(9225/9662); R-HDFS 30 1.04%(30/2889) - 95X; AG-HDFS 2874 99.48%(2874/2889)"

    Section 5.1 defines coverage as #Log_Event / #Total_Log_Event. The denominator #Total_Log_Event (9,662 for Hadoop, 2,889 for HDFS) is not an externally established ground-truth vocabulary; it is the log-event universe produced by AnomalyGen's own source-code/static-analysis enumeration of Hadoop 3.3.6 and HDFS. The numerator is AnomalyGen's generated event set from the same analysis. Coverage therefore measures internal recall of the pipeline against its own enumerated input, not coverage against an independent benchmark. The headline '38x–95x improvement' is this self-enumerated vocabulary compared to older datasets, so the claimed superiority is partly constructed by the choice of denominator, and the paper's own version-filtering caveat in Section 5.2 further weakens the comparison.

full rationale

AnomalyGen's generation pipeline and its RQ4 evaluation are not circular: the F1 improvement is obtained by training LSTM/Transformer/CNN on the original benchmark with and without AnomalyGen augmentation and testing on the same benchmark test data, so the gain is empirically forced only if the generated data actually helps. The central methodological contribution (CoT-verified recursive merging) is not derived from its own evaluation outcome. The main circularity concern is limited to the coverage headline: Table 2 defines coverage as #Log_Event / #Total_Log_Event, and the denominator is the event vocabulary obtained from AnomalyGen's own static analysis of the target versions, while the baseline datasets come from different workloads and older versions. This makes the 97.48% 'coverage' and the 38x–95x 'improvement' partly self-referential, and the paper itself filters the LogHub reference sets because of version differences. However, the paper also reports an external R-coverage check against LogHub events (93/107 and 14/15), which is not circular, and the anomaly-detection gain is an independent empirical result. Weighing these together, the paper has one self-referential metric at the core of its coverage claim but no definitional equivalence in the generation or detection results, so the circularity score is low.

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

The central claims rest on four domain assumptions: the completeness of static analysis, the accuracy of LLM reasoning in place of execution, the correctness of the hand-defined total log event counts, and the reliability of keyword/expert anomaly labels. None are independently verified in the paper; the threats section acknowledges each of these but does not quantify their impact.

free parameters (2)
  • Subgraph extraction thresholds (entry threshold, depth threshold)
    Section 3.3.1 selects subgraphs using an entry threshold and a depth threshold; exact values are not reported and they determine which execution paths the LLM sees, affecting the coverage and content of generated logs.
  • LLM inference parameters (model version, temperature, prompts)
    The pipeline uses GPT-4o and DeepSeek-Chat; sampling settings and CoT prompts are not disclosed, so the generated logs are not reproducible.
assumptions (5)
  • domain assumption Static analysis tools (java-callgraph2, javaparser) correctly extract the full cross-method call graph and control flow of Hadoop 3.3.6.
    Phase I and Phase II rely on these tools; errors or omissions would propagate to all downstream log generation.
  • domain assumption The total log event counts (9,662 for Hadoop, 2,889 for HDFS) are a complete and correct enumeration of all possible logging events in the systems.
    Coverage is defined as the ratio of generated events to these counts; if the enumeration is incomplete, the coverage gains are overstated.
  • domain assumption LLM chain-of-thought reasoning (GPT-4o, DeepSeek-Chat) can correctly infer dynamic calls, exception paths, and path constraints without executing the system.
    Phase III validation substitutes for runtime information; the threats section admits LLM randomness and logical errors, and no verification beyond the model itself is provided.
  • domain assumption The explicit and implicit keyword rules plus expert review correctly label anomalous log sequences.
    Phase IV assumes that terms like 'fail', 'invalid', and error codes are sufficient signals and that three expert reviewers are representative.
  • domain assumption Anomaly detection models are trained and tested on representative splits of the same HDFS benchmark without label leakage from augmented data.
    RQ4's conclusions depend on the integrity of the train/test split, which is not described.

how reviews work

0 comments
Cite this review

Pith. "Pith review of AnomalyGen: An Automated Semantic Log Sequence Generation Framework with LLM for Anomaly Detection." pith.science (2026). https://pith.science/paper/4JTQXYO5

@misc{pith2026250412250,
  author       = {Pith},
  title        = {Pith review of: AnomalyGen: An Automated Semantic Log Sequence Generation Framework with LLM for Anomaly Detection},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/4JTQXYO5}},
  note         = {Machine review of arXiv:2504.12250}
}
read the original abstract

The scarcity of high-quality public log datasets has become a critical bottleneck in advancing log-based anomaly detection techniques. Current datasets exhibit three fundamental limitations: (1) incomplete event coverage, (2) artificial patterns introduced by static analysis-based generation frameworks, and (3) insufficient semantic awareness. To address these challenges, we present AnomalyGen, the first automated log synthesis framework specifically designed for anomaly detection. Our framework introduces a novel four-phase architecture that integrates enhanced program analysis with Chain-of-Thought reasoning (CoT reasoning), enabling iterative log generation and anomaly annotation without requiring physical system execution. Evaluations on Hadoop and HDFS distributed systems demonstrate that AnomalyGen achieves substantially broader log event coverage (38-95 times improvement over existing datasets) while producing more operationally realistic log sequences compared to static analysis-based approaches. When augmenting benchmark datasets with synthesized logs, we observe maximum F1-score improvements of 3.7% (average 1.8% improvement across three state-of-the-art anomaly detection models). This work not only establishes a high-quality benchmarking resource for automated log analysis but also pioneers a new paradigm for applying large language models (LLMs) in software engineering workflows.

Figures

Figures reproduced from arXiv: 2504.12250 by the authors.

Figure 1
Figure 1. Two Code Cases That Are Difficult to Handle with [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. The Four Satges of AnomalyGen Framework. [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. PHASE I: Log-Related Node Labeling and Pruning. [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figures from the paper (7 more)
Figure 4
Figure 4. Figure 4: Log-Oriented Control Flow Graph and Control Chain Generation. [PITH_FULL_IMAGE:figures/full_fig_p006_4.png]
Figure 5
Figure 5. Figure 5: Structured Enhanced_CFG Example. This enhanced CFG provides a more precise representation of execution logic, offering richer contextual insights that improve log sequence reconstruction and anomaly detection. 3.4 PHASE III: Recursive Log Merging with CoT Inference Ver…
Figure 6
Figure 6. Figure 6: PHASE III: Stack-based Bottom-up Recursive Log Merging and CoT Verification Process. [PITH_FULL_IMAGE:figures/full_fig_p007_6.png]
Figure 7
Figure 7. Figure 7: Structured Output Validated by CoT. keywords. To face the above challenges, we explore how to cap￾ture explicit anomalies while identifying more potential anomalies through implicit features and introducing expert validation to en￾sure annotation quality. This strategy…
Figure 8
Figure 8. Figure 8: Example Code with Polymorphic Calls and Excep [PITH_FULL_IMAGE:figures/full_fig_p008_8.png]
Figure 9
Figure 9. Figure 9: CFG Diagram of the Exception Normal Flow for [PITH_FULL_IMAGE:figures/full_fig_p009_9.png]
Figure 10
Figure 10. Figure 10: CFG Diagram of the Exception Control Flow for [PITH_FULL_IMAGE:figures/full_fig_p009_10.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

53 extracted references · 33 canonical work pages

  1. [1]

    Anunay Amar and Peter C Rigby. 2019. Mining historical test logs to predict bugs and localize faults in the test logs. In2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE) . IEEE, 140–151

    work page 2019

  2. [2]

    Frank Busse, Pritam Gharat, Cristian Cadar, and Alastair F Donaldson. 2022. Combining static analysis error traces with dynamic symbolic execution (experi- ence paper). In Proceedings of the 31st ACM SIGSOFT International Symposium on Software Testing and Analysis. 568–579

    work page 2022

  3. [3]

    An Ran Chen, Tse-Hsun Chen, and Shaowei Wang. 2021. Pathidea: Improving information retrieval-based bug localization by re-constructing execution paths using logs. IEEE Transactions on Software Engineering 48, 8 (2021), 2905–2919

    work page 2021

  4. [4]

    Yinfang Chen, Huaibing Xie, Minghua Ma, Yu Kang, Xin Gao, Liu Shi, Yunjie Cao, Xuedong Gao, Hao Fan, Ming Wen, Jun Zeng, Supriyo Ghosh, Xuchao Zhang, Chaoyun Zhang, Qingwei Lin, Saravan Rajmohan, Dongmei Zhang, and Tianyin Xu. 2024. Automatic Root Cause Analysis via Large Language Models for Cloud Incidents (EuroSys ’24). Association for Computing Machine...

    arXiv 2024

  5. [5]

    Marcello Cinque, Domenico Cotroneo, Roberto Natella, and Antonio Pecchia

    work page

  6. [6]

    Zishuo Ding, Heng Li, and Weiyi Shang. 2022. Logentext: Automatically generat- ing logging texts using neural machine translation. In 2022 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER) . IEEE, 349–360

    work page 2022

  7. [7]

    Zishuo Ding, Yiming Tang, Xiaoyu Cheng, Heng Li, and Weiyi Shang. 2023. Logentext-plus: Improving neural machine translation based logging texts gener- ation with syntactic templates. ACM Transactions on Software Engineering and Methodology 33, 2 (2023), 1–45

    work page 2023

  8. [8]

    Min Du, Feifei Li, Guineng Zheng, and Vivek Srikumar. 2017. Deeplog: Anomaly detection and diagnosis from system logs through deep learning. In Proceedings of the 2017 ACM SIGSAC conference on computer and communications security . 1285–1298

    2017

Show all 53 references
  1. [9]

    Jiaqi Gao, Nofel Yaseen, Robert MacDavid, Felipe Vieira Frujeri, Vincent Liu, Ricardo Bianchini, Ramaswamy Aditya, Xiaohang Wang, Henry Lee, David Maltz, Minlan Yu, and Behnaz Arzani. 2020. Scouts: Improving the Diagnosis Process Through Domain-customized Incident Routing (SIG...

    2020 doi

  2. [10]

    Hongcheng Guo, Jian Yang, Jiaheng Liu, Jiaqi Bai, Boyang Wang, Zhoujun Li, Tieqiao Zheng, Bo Zhang, Junran Peng, and Qi Tian. 2024. Logformer: A pre- train and tuning pipeline for log anomaly detection. In Proceedings of the AAAI Conference on Artificial Intelligence, Vol. 38. 135–143

    2024

  3. [11]

    Shilin He, Jieming Zhu, Pinjia He, and Michael R Lyu. 2020. Loghub: A large collection of system log datasets towards automated log analytics. arXiv 2020. arXiv preprint arXiv:2008.06448 (2020)

    2020 arXiv

  4. [12]

    Yintong Huo, Cheryl Lee, Yuxin Su, Shiwen Shan, Jinyang Liu, and Michael R Lyu. 2023. Evlog: Identifying anomalous logs over software evolution. In 2023 IEEE 34th International Symposium on Software Reliability Engineering (ISSRE) . IEEE, 391–402

    2023

  5. [13]

    Yintong Huo, Yichen Li, Yuxin Su, Pinjia He, Zifan Xie, and Michael R Lyu. 2023. Autolog: A log sequence synthesis framework for anomaly detection. In2023 38th IEEE/ACM International Conference on Automated Software Engineering (ASE) . IEEE, 497–509

    2023

  6. [14]

    Yintong Huo, Yuxin Su, Cheryl Lee, and Michael R Lyu. 2023. Semparser: A semantic parser for log analytics. In 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE) . IEEE, 881–893

    2023

  7. [15]

    Zhihan Jiang, Jinyang Liu, Junjie Huang, Yichen Li, Yintong Huo, Jiazhen Gu, Zhuangbin Chen, Jieming Zhu, and Michael R Lyu. 2024. A large-scale evaluation for log parsing techniques: How far are we?. In Proceedings of the 33rd ACM SIGSOFT International Symposium on Software T...

    2024

  8. [16]

    Van-Hoang Le and Hongyu Zhang. 2022. Log-based anomaly detection with deep learning: How far are we?. InProceedings of the 44th international conference on software engineering. 1356–1367

    2022

  9. [17]

    Xiaoyun Li, Pengfei Chen, Linxiao Jing, Zilong He, and Guangba Yu. 2020. Swiss- log: Robust and unified deep learning based log anomaly detection for diverse faults. In 2020 IEEE 31st International Symposium on Software Reliability Engineer- ing (ISSRE). IEEE, 92–103

    2020

  10. [18]

    Xiaoyun Li, Hongyu Zhang, Van-Hoang Le, and Pengfei Chen. 2024. Logshrink: Effective log compression by leveraging commonality and variability of log data. In Proceedings of the 46th IEEE/ACM International Conference on Software Engineering. 1–12

    2024

  11. [19]

    Yichen Li, Yintong Huo, Zhihan Jiang, Renyi Zhong, Pinjia He, Yuxin Su, Lionel C Briand, and Michael R Lyu. 2024. Exploring the effectiveness of llms in automated logging statement generation: An empirical study. IEEE Transactions on Software Engineering (2024). Conference acr...

    2024

  12. [20]

    Yichen Li, Yintong Huo, Renyi Zhong, Zhihan Jiang, Jinyang Liu, Junjie Huang, Jiazhen Gu, Pinjia He, and Michael R Lyu. 2024. Go static: Contextualized logging statement generation. Proceedings of the ACM on Software Engineering 1, FSE (2024), 609–630

    2024

  13. [21]

    Yichen Li, Xu Zhang, Shilin He, Zhuangbin Chen, Yu Kang, Jinyang Liu, Liqun Li, Yingnong Dang, Feng Gao, Zhangwei Xu, et al. 2022. An intelligent framework for timely, accurate, and comprehensive cloud incident detection. ACM SIGOPS Operating Systems Review 56, 1 (2022), 1–7

    2022

  14. [22]

    Zhenhao Li, Tse-Hsun Chen, and Weiyi Shang. 2020. Where shall we log? studying and suggesting logging locations in code blocks. In Proceedings of the 35th IEEE/ACM International Conference on Automated Software Engineering . 361– 372

    2020

  15. [23]

    Zhong Li, Jiayang Shi, and Matthijs Van Leeuwen. 2024. Graph neural networks based log anomaly detection and explanation. InProceedings of the 2024 IEEE/ACM 46th International Conference on Software Engineering: Companion Proceedings . 306–307

    2024

  16. [24]

    Zhengxin Li, Junfeng Zhao, and Jia Kang. 2024. Multi-source Anomaly Detection For Microservice Systems. In Proceedings of the 2024 IEEE/ACM 46th International Conference on Software Engineering: Companion Proceedings . 414–415

    2024

  17. [25]

    Qingwei Lin, Hongyu Zhang, Jian-Guang Lou, Yu Zhang, and Xuewei Chen

  18. [26]

    Jinyang Liu, Junjie Huang, Yintong Huo, Zhihan Jiang, Jiazhen Gu, Zhuangbin Chen, Cong Feng, Minzhi Yan, and Michael R Lyu. 2023. Scalable and adaptive log- based anomaly detection with expert in the loop. arXiv preprint arXiv:2306.05032 (2023)

    2023 arXiv

  19. [27]

    Yilun Liu, Shimin Tao, Weibin Meng, Jingyu Wang, Wenbing Ma, Yuhang Chen, Yanqing Zhao, Hao Yang, and Yanfei Jiang. 2024. Interpretable online log analysis using large language models with prompt strategies. In Proceedings of the 32nd IEEE/ACM International Conference on Progr...

    2024

  20. [28]

    Yilun Liu, Shimin Tao, Weibin Meng, Feiyu Yao, Xiaofeng Zhao, and Hao Yang

  21. [29]

    LOGPAI. [n. d.]. LOGPAI: Log Analytics Powered by AI. https://github.com/logpai. Accessed 2025-03-12

    2025

  22. [30]

    Siyang Lu, BingBing Rao, Xiang Wei, Byungchul Tak, Long Wang, and Liqiang Wang. 2017. Log-based abnormal task detection and root cause analysis for spark. In 2017 IEEE International Conference on Web Services (ICWS) . IEEE, 389–396

    2017

  23. [31]

    Lipeng Ma, Weidong Yang, Bo Xu, Sihang Jiang, Ben Fei, Jiaqing Liang, Mingjie Zhou, and Yanghua Xiao. 2024. Knowlog: Knowledge enhanced pre-trained language model for log understanding. In Proceedings of the 46th ieee/acm inter- national conference on software engineering . 1–13

    2024

  24. [32]

    Antonio Mastropaolo, Luca Pascarella, and Gabriele Bavota. 2022. Using deep learning to generate complete log statements. In Proceedings of the 44th Interna- tional Conference on Software Engineering . 2279–2290

    2022

  25. [33]

    Tsuyoshi Mizouchi, Kazumasa Shimari, Takashi Ishio, and Katsuro Inoue. 2019. PADLA: a dynamic log level adapter using online phase detection. In 2019 IEEE/ACM 27th International Conference on Program Comprehension (ICPC) . IEEE, 135–138

    2019

  26. [34]

    Brian A Nejmeh. 1988. NPATH: A measure of execution path complexity and its applications. Commun. ACM 31, 2 (1988), 188–200

    1988

  27. [35]

    Adam Oliner and Jon Stearley. 2007. What supercomputers say: A study of five system logs. In 37th annual IEEE/IFIP international conference on dependable systems and networks (DSN’07) . IEEE, 575–584

    2007

  28. [36]

    Antonio Pecchia and Stefano Russo. 2012. Detection of software failures through event logs: An experimental study. In 2012 IEEE 23rd International Symposium on Software Reliability Engineering. IEEE, 31–40

    2012

  29. [37]

    Yoli Shavit, Kathy Razmadze, Gary Mataev, Hanan Shteingart, Eitan Zahavi, and Zachi Binshtock. 2024. SemantiLog: Log-based Anomaly Detection with Semantic Similarity. In Proceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering. 2438–2439

    2024

  30. [38]

    SLF4J. 2022. Simple Logging Facade for Java (SLF4J). (2022)

    2022

  31. [39]

    Chengyu Wang, Kui Wu, Tongqing Zhou, Guang Yu, and Zhiping Cai. 2021. Tsagen: synthetic time series generation for kpi anomaly detection. IEEE Trans- actions on Network and Service Management 19, 1 (2021), 130–145

    2021

  32. [40]

    Hanzhang Wang, Zhengkai Wu, Huai Jiang, Yichao Huang, Jiamu Wang, Selcuk Kopru, and Tao Xie. 2021. Groot: An event-graph-based approach for root cause analysis in industrial settings. In 2021 36th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 419–429

    2021

  33. [41]

    Lingzhi Wang, Nengwen Zhao, Junjie Chen, Pinnong Li, Wenchi Zhang, and Kaixin Sui. 2020. Root-cause metric location for microservice systems via log anomaly detection. In 2020 IEEE international conference on web services (ICWS) . IEEE, 142–150

    2020

  34. [42]

    Wenjing Wang, Shida Lu, Jianhui Luo, and Chengrong Wu. 2023. Deepuserlog: Deep anomaly detection on user log using semantic analysis and key-value data. In 2023 IEEE 34th International Symposium on Software Reliability Engineering (ISSRE). IEEE, 172–182

    2023

  35. [43]

    Junjielong Xu, Ziang Cui, Yuan Zhao, Xu Zhang, Shilin He, Pinjia He, Liqun Li, Yu Kang, Qingwei Lin, Yingnong Dang, et al. 2024. Unilog: Automatic logging via llm and in-context learning. In Proceedings of the 46th ieee/acm international conference on software engineering . 1–12

    2024

  36. [44]

    Wei Xu, Ling Huang, Armando Fox, David Patterson, and Michael I Jordan. 2009. Detecting large-scale system problems by mining console logs. In Proceedings of the ACM SIGOPS 22nd symposium on Operating systems principles . 117–132

    2009

  37. [45]

    Lin Yang, Junjie Chen, Shutao Gao, Zhihao Gong, Hongyu Zhang, Yue Kang, and Huaan Li. 2024. Try with Simpler-An Evaluation of Improved Principal Component Analysis in Log-based Anomaly Detection. ACM Transactions on Software Engineering and Methodology 33, 5 (2024), 1–27

    2024

  38. [46]

    Lin Yang, Junjie Chen, Zan Wang, Weijing Wang, Jiajun Jiang, Xuyuan Dong, and Wenbin Zhang. 2021. Plelog: Semi-supervised log-based anomaly detection via probabilistic label estimation. In 2021 IEEE/ACM 43rd International Conference on Software Engineering: Companion Proceedin...

    2021

  39. [47]

    Boxi Yu, Jiayi Yao, Qiuai Fu, Zhiqing Zhong, Haotian Xie, Yaoliang Wu, Yuchi Ma, and Pinjia He. 2024. Deep learning or classical machine learning? an empirical study on log-based anomaly detection. In Proceedings of the 46th IEEE/ACM International Conference on Software Engine...

    2024

  40. [48]

    Ding Yuan, Jing Zheng, Soyeon Park, Yuanyuan Zhou, and Stefan Savage. 2012. Improving software diagnosability via log enhancement. ACM Transactions on Computer Systems (TOCS) 30, 1 (2012), 1–28

    2012

  41. [49]

    Xu Zhao, Kirk Rodrigues, Yu Luo, Michael Stumm, Ding Yuan, and Yuanyuan Zhou. 2017. Log20: Fully automated optimal placement of log printing statements under specified overhead threshold. In Proceedings of the 26th Symposium on Operating Systems Principles. 565–581

    2017

  42. [50]

    Jieming Zhu, Shilin He, Pinjia He, Jinyang Liu, and Michael R Lyu. 2023. Loghub: A large collection of system log datasets for ai-driven log analytics. In 2023 IEEE 34th International Symposium on Software Reliability Engineering (ISSRE) . IEEE, 355–366

    2023

  43. [2010]

    In 2010 IEEE/IFIP International Conference on Dependable Systems & Networks (DSN)

    Assessing and improving the effectiveness of logs for the analysis of software faults. In 2010 IEEE/IFIP International Conference on Dependable Systems & Networks (DSN). IEEE, 457–466

    2010

  44. [2016]

    In Proceedings of the 38th international conference on software engineering companion

    Log clustering based problem identification for online service systems. In Proceedings of the 38th international conference on software engineering companion . 102–111

  45. [2024]

    In Proceedings of the 2024 IEEE/ACM 46th International Conference on Software Engineering: Companion Proceedings

    Logprompt: Prompt engineering towards zero-shot and interpretable log analysis. In Proceedings of the 2024 IEEE/ACM 46th International Conference on Software Engineering: Companion Proceedings . 364–365

    2024

Pith tools

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