# AnoMod: A Dataset for Anomaly Detection and Root Cause Analysis in Microservice Systems
**Authors**: Ke Ping, Hamza Bin Mazhar, Yuqing Wang, Ying Song, Mika V. Mäntylä
> 0009-0009-5433-4771Department of Computer ScienceUniversity of HelsinkiHelsinkiFinlandke.ping@helsinki.fi
> 0009-0009-6352-9810Department of Computer ScienceUniversity of HelsinkiHelsinkiFinlandhamza.mazhar@helsinki.fi
> 0000-0003-0175-005XDepartment of Computer ScienceUniversity of HelsinkiHelsinkiFinlandyuqing.wang@helsinki.fi
> 0000-0001-9791-1879Department of Computer ScienceUniversity of HelsinkiHelsinkiFinlandying.song@helsinki.fi
> 0000-0002-2841-5879Department of Computer ScienceUniversity of HelsinkiHelsinkiFinlandmika.mantyla@helsinki.fi
\setcctype
by
(2026)
Abstract.
Microservice systems (MSS) have become a predominant architectural style for cloud services. Yet the community still lacks high-quality, publicly available datasets for anomaly detection (AD) and root cause analysis (RCA) in MSS. Most benchmarks emphasize performance-related faults and provide only one or two monitoring modalities, limiting research on broader failure modes and cross-modal methods. To address these gaps, we introduce a new multimodal anomaly dataset built on two open-source microservice systems: SocialNetwork and TrainTicket. We design and inject four categories of anomalies (Ano): performance-level, service-level, database-level, and code-level, to emulate realistic anomaly modes. For each scenario, we collect five modalities (Mod): logs, metrics, distributed traces, API responses, and code coverage reports, offering a richer, end-to-end view of system state and inter-service interactions. We name our dataset, reflecting its unique properties, as AnoMod. This dataset enables (1) evaluation of cross-modal anomaly detection and fusion/ablation strategies, and (2) fine-grained RCA studies across service and code regions, supporting end-to-end troubleshooting pipelines that jointly consider detection and localization.
Microservices, Anomaly Detection, Multimodal Dataset, AIOps journalyear: 2026 copyright: cc conference: 23rd International Conference on Mining Software Repositories; April 13–14, 2026; Rio de Janeiro, Brazil booktitle: 23rd International Conference on Mining Software Repositories (MSR ’26), April 13–14, 2026, Rio de Janeiro, Brazil doi: 10.1145/3793302.3793324 isbn: 979-8-4007-2474-9/2026/04 ccs: Software and its engineering Software reliability ccs: Software and its engineering Software performance ccs: Software and its engineering Cloud computing
1. Introduction
Nowadays, microservice architectures are popular in modern software development (Amoroso d’Aragona et al., 2024). However, it also poses a significant challenge for Site Reliability Engineers (SREs) to maintain system stability, as anomalies are inevitable given the system’s complexity and distributed characteristics. Thereby, Artificial Intelligence for IT Operations (AIOps) emerged, aiming to automate anomaly detection and root cause analysis (RCA) to help SREs manage these systems effectively. Progress in AIOps research, however, is often hindered by the lack of high-quality, publicly available datasets that reflect real-world conditions (Wang et al., 2025a, b; Zhang et al., 2025).
Existing open-source multimodal datasets of MSS for anomaly detection and root cause analysis are summarized in Table 1. We found that these datasets have two main limitations. First, they cover only a limited range of anomaly types. Most datasets focus on performance-related anomalies such as resource contention and network latency, though a few also include other anomaly types such as code defects, API errors, and configuration issues. However, real-world MSS environments involve many more types of anomalies beyond these. For example, common anomalies occur at the database level (e.g., connection pool exhaustion (Steidl et al., 2024)), the service level (e.g., service response failure (Soldani and Brogi, 2022)), and the code level (e.g., logic errors or unhandled exceptions (Zhou et al., 2021)). Second, existing datasets (Yu et al., 2023; Lee et al., 2023; Zhang et al., 2022) simulate user requests but lack any measurement or reporting of service-level or API endpoint coverage. Consequently, it remains unclear whether the critical services or common endpoints are invoked during the simulated user requests, which may affect the representativeness of the resulting datasets.
Our work extends prior work and makes novel contributions in three aspects. First, we designed a taxonomy of anomaly cases across four levels to replicate common failure scenarios of MSS, following (Amazon Web Services, 2024; Microsoft Azure, 2024a, b; Verica, Inc., 2024). Second, guided by this taxonomy, we collect two additional data modalities: Code Coverage Report (CCR) and API Response (API Res). CCR shows which code statements and branches actually ran, while API Res reflect user-visible availability; together, they connect internal cause with external symptoms to support anomaly diagnosis. Third, when selecting anomaly injection targets, we prioritize services with the widest impact based on system dependency relationships, whereas prior works typically use random or predefined injection targets. In the mean time, by improving the API specification for EvoMaster, we achieve broader endpoint coverage and richer test interactions. The complete dataset is publicly available on Zenodo (DOI: 10.5281/zenodo.18342898), and the collection scripts are available at https://github.com/EvoTestOps/AnoMod.
Table 1. Comparison of AnoMod dataset against Existing Monitoring Datasets for Microservice Systems
2. Dataset Construction
2.1. Target System
We build our dataset on two widely used open-source MSS: SocialNetwork (Gan et al., 2019) and TrainTicket (Zhou et al., 2021). Both systems have well-documented architectures and service interactions, allowing us to map each anomaly case to specific system components and thus inject anomalies systematically. SocialNetwork is a social media application that consists of 21 services. TrainTicket is a larger and more complex railway ticketing system with 41 microservices.
2.2. Anomaly Design
To ensure our dataset reflects real-world failure scenarios, our anomaly design is grounded in industry practice (Verica, Inc., 2024; Amazon Web Services, 2024; Microsoft Azure, 2024a, b). According to large scale incident studies and cloud reliability guidance, production failures are not only related to resource exhaustion but also to service dependency interactions, data store behavior, network partitions, and application logic errors (Verica, Inc., 2024; Steidl et al., 2024; Soldani and Brogi, 2022; Zhou et al., 2021). Focusing on performance injection would miss these important failure modes.
Motivated by these insights, we design anomaly cases organized into four levels that systematically cover the system stack: For instance, Database-level cases such as Connection Pool Exhaustion represent capacity- and constraint-driven resource exhaustion scenarios (e.g., limits on concurrent database connections) discussed in reliability best practices (Amazon Web Services, 2024). Meanwhile, Service-level cases such as Response Failures emulate dependency-related degradations where client-side timeouts are necessary to prevent prolonged waiting and cascading impact in synchronous interactions (Amazon Web Services, 2024; Microsoft Azure, 2024a). We further follow cloud testing guidance that advocates inducing real-world faults during workloads to validate recovery paths and system behavior under both graceful and ungraceful faults (Microsoft Azure, 2024b). We organized these validated scenarios into four levels: (1) Performance level anomalies capture resource related issues; (2) Service level anomalies arise during inter-service communication or request handling; (3) Database level anomalies include data layer disruptions, reflecting the dependency failures often observed in production environments where data stores become system bottlenecks; (4) Code level anomalies target logic or implementation related defects within microservices, thereby emulating software defects that are difficult to expose through infrastructure-level testing.
2.3. Collected Multimodal Data
Our dataset captures multimodal data and provides a multi-view of system behavior to give a deep understanding of normal and anomaly. We structure these modalities into categories: monitoring data common in modern microservice systems, and behavior data offering deeper insights into code execution and external interactions.
2.3.1. Monitoring Data
Logs are collected from application containers, providing timestamped records of execution flows, errors, and context for debugging and postmortem analysis. Metrics are time-series data collected via Prometheus (Prometheus Authors, 2025), covering node-level (resources), application-level (request counts), and process-level indicators. They aggregate system health and performance trends to support anomaly detection. Traces, captured using Jaeger (Jaeger Authors, 2025) and SkyWalking (Apache SkyWalking, 2025), track request propagation across microservices. They expose dependencies, latency, and call-chain structure, essential for diagnosing distributed performance issues.
2.3.2. Behavior Data
To enrich the dataset beyond standard monitoring, we introduce two additional modalities that bridge runtime behavior with code execution and user visible outcomes. Code coverage reports generated using language appropriate instrumentation (Gcov (Free Software Foundation, 2024) for C++; JaCoCo (The JaCoCo Team, 2025) for Java). This modality reflects runtime activity directly to source code lines, branches, or functions. Its primary value lies in identifying which specific code path, including error handlers and rarely executed logic, is activated during normal operation versus anomaly cases. It may be of high value in testing environments and debugging as it provides direct evidence for code level root cause analysis process. API Responses capture the direct outcomes of client-service interactions, providing a crucial black-box perspective on system behavior. Collected through client side observation during workload execution, these records include essential details, namely, HTTP status codes, end-to-end latency, and response context (headers and body content). API Res directly reflect user visible symptoms. They serve as an important link between low level system telemetry and the overall service reliability experienced by users, offering high level indicators for anomaly detection.
Data from these five modalities, collected synchronously during controlled experiments, provide a rich, multiple perspective dataset. The monitoring data offers runtime visibility, while the behavior data supplements crucial context about internal code execution and external service outcomes, enabling more comprehensive multimodal correlation for anomaly detection and root cause analysis.
2.4. Data Collection Pipeline
Our data collection pipeline contains three phases, as illustrated in Figure 1. It systematically generates workloads, injects anomalies, and captures multimodal data. We describe each phase in detail below.
<details>
<summary>Pipeline.png Details</summary>
### Visual Description
# Technical Document Extraction: Automated Testing and Anomaly Injection Workflow
This document describes a three-phase technical workflow for generating workloads, designing anomalies, and executing automated data collection in a microservice environment.
## 1. High-Level Structure
The process is divided into three distinct horizontal phases, followed by a feedback loop for continuous data packaging.
* **Phase 1: Workload Generation** (Color-coded: Light Green)
* **Phase 2: Anomaly Design** (Color-coded: Orange)
* **Phase 3: Automated Execution & Collection** (Color-coded: Teal/Blue)
---
## 2. Phase 1: Workload Generation
This phase focuses on creating the baseline operational traffic for the system.
| Step | Component Name | Description/Details |
| :--- | :--- | :--- |
| 1.1 | **API Specification** | Uses Swagger/OpenAPI as the source. |
| 1.2 | **EvoMaster Test Generation** | Automated tool used to generate test cases based on the API spec. |
| 1.3 | **Workload (Success Tests)** | The final output of Phase 1, consisting of successful test scenarios. |
**Flow:** 1.1 $\rightarrow$ 1.2 $\rightarrow$ 1.3. The output of 1.3 feeds directly into the "Execute Workload" step in Phase 3.
---
## 3. Phase 2: Anomaly Design
This phase defines the faults that will be introduced into the system.
| Step | Component Name | Description/Details |
| :--- | :--- | :--- |
| 2.1 | **Fault Taxonomy** | Based on Industry Practice. |
| 2.2 | **Define Anomaly Case** | The process of specifying the parameters of the fault. |
| 2.3 | **Anomaly Library** | The final output of Phase 2, stored as YAML/Scripts. |
**Flow:** 2.1 $\rightarrow$ 2.2 $\rightarrow$ 2.3. The output of 2.3 feeds into the "Inject Anomaly" step in Phase 3.
---
## 4. Phase 3: Automated Execution & Collection
This phase represents the runtime environment where tests are executed and data is gathered.
### Linear Setup Sequence:
1. **System Reset & Cleanup:** Prepares the environment.
2. **Deploy Microservice system:** Initial deployment of the target architecture.
3. **Wait for pod/container stabilization:** Ensures the environment is ready before testing begins.
### Decision Logic and Execution:
Following stabilization, the process enters a decision diamond: **"Inject Anomaly?"**
* **If "Yes":**
* Proceeds to **Inject Anomaly** (utilizing the Anomaly Library from Phase 2).
* Then proceeds to **Execute Workload** (utilizing the Workload from Phase 1).
* **If "No":**
* Proceeds directly to **Execute Workload** (representing a "clean" or baseline run).
### Post-Execution and Data Collection:
After the workload is executed, the following steps occur in sequence:
1. **Collect 5 Modalities:** Gathering multi-dimensional system data.
2. **Terminate Anomaly & cleanup:** Returning the system to a neutral state.
3. **Package & Label Data:** Finalizing the dataset for analysis.
---
## 5. Feedback Loop and Iteration
* **Data Loop:** A dashed arrow points from "Package & Label Data" back to "System Reset & Cleanup," indicating an automated, iterative cycle for generating large datasets.
* **External Inputs:** The diagram shows that Phase 1 (Workload) and Phase 2 (Anomaly Library) provide the necessary "ingredients" that are injected into the Phase 3 runtime loop at specific execution points.
## 6. Component Summary
* **Total Phases:** 3
* **Decision Points:** 1 (Inject Anomaly?)
* **Data Modalities Collected:** 5
* **Primary Tools Mentioned:** Swagger/OpenAPI, EvoMaster, YAML/Scripts.
</details>
Figure 1. The three-phase automated data collection pipeline.
Phase 1. We create system workloads that invoke service endpoints to simulate realistic user requests through automated black-box testing using EvoMaster. EvoMaster (Arcuri et al., 2025) is a popular open-source tool for automated black-box testing of RESTful and web services. It generates automated test suites based on API specifications (Swagger 2.0/OpenAPI 3.0) and uses evolutionary search and fuzzing algorithms to maximize API endpoint coverage. To support EvoMaster’s black-box testing, we generate API specifications for the target MSS. These specifications are parsed by EvoMaster to produce automated test suites. For data collection, we only utilize the “success tests” produced by EvoMaster. The fault tests and EvoMaster generated reports are used for specification diagnostics, hardening, and evolution. Anomalies are injected in the next phase of the collection pipeline, independently under controlled experimental conditions.
Phase 2. This phase prepares for and manages the controlled injection of anomalies, based on our four-level anomaly taxonomy (Table 2). We predefine each anomaly case as a reusable configuration file or script, forming an Anomaly Library. We injected Performance, Service, Database level anomalies using ChaosMesh (Chaos Mesh Authors, 2025) via Kubernetes Custom Resource Definitions (CRDs) to orchestrate pod failures, network latency, and packet loss via the Linux kernel’s traffic control (tc) subsystem. For Code-level anomalies, we leverages JVM sandbox technology from ChaosBlade (ChaosBlade Authors, 2025) to perform dynamic bytecode instrumentation at runtime. This allows to inject exceptions and delays into specific Java methods without modifying the source code or redeploying different binaries, reproducing logic defects in production artifacts. These baseline parameters are widely used in industrial anomaly injection testing and ensure a balance between observability of system degradation and safe recovery after each experiment. Before executing the workload in Phase 3, the pipeline selects the appropriate anomaly case from this library based on the experiment plan. Importantly, the pipeline logic ensures the anomaly case is activated precisely before the workload starts and is terminated immediately upon workload completion. This strict timing provides clear temporal boundaries, isolating the anomaly’s effects within the collected data for accurate analysis.
Phase 3. We create a master script to ensure that each anomaly case run is isolated and starts from a clean system state via system reset and cleanup. To achieve this, the script redeploys a fresh instance of the MSS for each anomaly case run and waits until all components are fully initialized and stable. Since the original system logs only contained startup events, we inserted info-level normal logs into each microservice of SocialNetwork, with the aim of tracking the request processing flow and key operation results of each service during operation. Based on the experimental plan (input parameter), the script decides whether to inject an anomaly from the library (Phase 2). Subsequently, it executes the pre-generated workload (Phase 1) while concurrently capturing all five multimodal data through specific collectors. Upon workload completion, any active anomaly is terminated, the data collected for each case is saved in a folder named after the anomaly.
3. Data Description
The dataset primarily supports AIOps work on MSS, enabling researchers and practitioners to develop and evaluate AD & RCA analysis techniques. The main contributions are the five correlated data modalities, including novel code coverage and API Res data, enabling the study of multimodal fusion and fine-grained analyses that track symptoms back to code execution and forward to user impact. The four level anomaly taxonomy also supports targeted evaluation across diverse, realistic anomaly types rather than only performance issues. Table 2 provides a detailed overview of the 24 anomaly cases, categorized by level, that we designed and injected across the SocialNetwork and TrainTicket systems.
Table 2. Taxonomy of Injected Anomaly Cases.
| Level | Anomaly Cases | Description |
| --- | --- | --- |
| Performance | CPU Contention | High processor load on services or system wide. |
| Network Performance Degradation | Unstable network conditions such as packet loss or high latency. | |
| Disk I/O Stress | Storage bottlenecks affecting data read/write operations. | |
| Service | Service Instance Failure | Unexpected service crashes, terminations. |
| Service Communication Failure | Services cannot reach their dependencies due to failed service discovery. | |
| Service Response Failure | Service responding incorrectly. | |
| Database | Cache Pressure | Memory pressure specifically targeting database caches. |
| Connection Pool Exhaustion | All database connections are occupied (via injected network delay). | |
| Transaction Issues | Problems within database operations. | |
| Code | Manipulating Method Return Values | Forcing specific Java methods in the application to return predefined values. |
| Method Execution Delay | Adding artificial delays to specific Java method calls. | |
| Injecting Exceptions | Throwing specified exceptions during the execution of targeted Java methods. | |
For SocialNetwork, we selected 5 services with 6 API paths for their deterministic, stateless benchmarking behavior and structured JSON responses. We excluded endpoints due to interactive workflows, session state, non-JSON media, or side effects. Dynamic analysis confirmed that automated clients target these selected endpoints. For TrainTicket, we targeted 34 services with 172 paths, excluding those with incomplete specifications, missing routes, or infrastructure roles.
Table 3. Scale and Composition of the Dataset
| System | Log Lines (K) | Log Templates | Traces | Metrics Collected | API Requests | Average CCR |
| --- | --- | --- | --- | --- | --- | --- |
| TrainTicket | 444.6 | 831 | 63,975 | 33 | 98,073 | 0.417 |
| SocialNetwork | 3958.5 | 29 | 2,635 | 29 | 1,950 | 0.682 |
We summarize our dataset in Table 3, reporting its scale and composition across modalities. “Log Lines” count the total number of lines produced after workload execution. “Log Templates” denote structural patterns mined from raw logs (He et al., 2017). The “Traces” column shows the total number of collected traces. “Metrics Collected” count the number of unique Prometheus metrics. “API Requests” count total requests across all EvoMaster runs for the system. “Average CCR” denotes the mean code coverage rate computed over all coverage reports.
4. Conclusion
We introduced a new multimodal benchmark dataset for AD & RCA in MSS. We added two novel modalities: API Res, which provides more user-facing information, and CCR, which enables fine-grained root cause analysis for software developers. We believe this dataset will benefit the development and evaluation of advanced AIOps techniques. The dataset is publicly available to foster further research in building more resilient MSS.
The limitations are that only two open-source systems were studied and that anomalies were injected solely using chaos engineering tools, which may not fully mimic the complexity of all production environments. Additionally, the workload is only generated by EvoMaster’s black-box testing. In the future, we may use different workload generation tools and white-box testing approaches.
5. Acknowledgment
This work has been supported by FAST, the Finnish Software Engineering Doctoral Research Network, funded by the Ministry of Education and Culture, Finland. This work is also funded by the EuroHPC Joint Undertaking and its members including top-up funding by the Ministry of Education and Culture of Finland. The authors acknowledge CSC-IT Center for Science, Finland, for providing computing resources. This work is also supported by the Research Council of Finland (grant id: 359861, the MuFAno project).
References
- Amazon Web Services (2024) Reliability pillar - aws well-architected framework. Note: Publication date: 2024-11-06; Accessed: 2025-10-15 External Links: Link Cited by: §1, §2.2, §2.2.
- D. Amoroso d’Aragona, A. Bakhtin, X. Li, R. Su, L. Adams, E. Aponte, F. Boyle, P. Boyle, R. Koerner, J. Lee, F. Tian, Y. Wang, J. Nyyssölä, E. Quevedo, S. M. Rahaman, A. S. Abdelfattah, M. Mäntylä, T. Cerny, and D. Taibi (2024) A dataset of microservices-based open-source projects. In Proceedings of the 21st International Conference on Mining Software Repositories, MSR ’24, New York, NY, USA, pp. 504–509. External Links: ISBN 9798400705878, Link, Document Cited by: §1.
- Apache SkyWalking (2025) Apache skywalking: apm and observability platform. External Links: Link Cited by: §2.3.1.
- A. Arcuri, M. Zhang, S. Seran, A. Belhadi, J. P. Galeotti, Bogdan, A. Golmohammadi, O. Duman, A. Aldasoro, Philip, Ö. Şahin, A. M. López, H. Ghianni, M. T. Shalmani, M. Rodriguez, IvaK, A. Panichella, K. Niemeyer, and M. Maugeri (2025) WebFuzzing/evomaster: v4.0.0 External Links: Document, Link Cited by: §2.4.
- A. Bakhtin, J. Nyyssölä, Y. Wang, N. Ahmad, K. Ping, M. Esposito, M. Mäntylä, and D. Taibi (2025) LO2: microservice api anomaly dataset of logs and metrics. In Proceedings of the 21st International Conference on Predictive Models and Data Analytics in Software Engineering, PROMISE ’25, New York, NY, USA, pp. 1–10. External Links: ISBN 9798400715945, Link, Document Cited by: Table 1.
- Chaos Mesh Authors (2025) Chaos mesh: a chaos engineering platform for kubernetes. External Links: Link Cited by: §2.4.
- ChaosBlade Authors (2025) ChaosBlade: cloud-native chaos engineering toolkit. External Links: Link Cited by: §2.4.
- Free Software Foundation (2024) Gcov—a test coverage program. Note: Accessed: 2025-10-20 External Links: Link Cited by: §2.3.2.
- Y. Gan, Y. Zhang, D. Cheng, A. Shetty, P. Rathi, N. Katarki, A. Bruno, J. Hu, B. Ritchken, B. Jackson, K. Hu, M. Pancholi, Y. He, B. Clancy, C. Colen, F. Wen, C. Leung, S. Wang, L. Zaruvinsky, M. Espinosa, R. Lin, Z. Liu, J. Padilla, and C. Delimitrou (2019) An open-source benchmark suite for microservices and their hardware-software implications for cloud & edge systems. In Proceedings of the Twenty-Fourth International Conference on Architectural Support for Programming Languages and Operating Systems, ASPLOS ’19, New York, NY, USA, pp. 3–18. External Links: ISBN 9781450362405, Link, Document Cited by: §2.1.
- P. He, J. Zhu, Z. Zheng, and M. R. Lyu (2017) Drain: an online log parsing approach with fixed depth tree. In 2017 IEEE International Conference on Web Services (ICWS), Vol. , pp. 33–40. External Links: Document Cited by: §3.
- Jaeger Authors (2025) Jaeger: open source distributed tracing platform. External Links: Link Cited by: §2.3.1.
- C. Lee, T. Yang, Z. Chen, Y. Su, and M. R. Lyu (2023) Eadro: an end-to-end troubleshooting framework for microservices on multi-source data. In 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE), Vol. , pp. 1750–1762. External Links: Document Cited by: Table 1, §1.
- Z. Li, N. Zhao, S. Zhang, Y. Sun, P. Chen, X. Wen, M. Ma, and D. Pei (2022) Constructing large-scale real-world benchmark datasets for aiops. arXiv preprint arXiv:2208.03938. Cited by: Table 1.
- Microsoft Azure (2024a) Architecture strategies for performing failure mode analysis. Note: Accessed: 2025-10-15 External Links: Link Cited by: §1, §2.2, §2.2.
- Microsoft Azure (2024b) Simulate failures in azure microservices (service fabric testability). Note: Accessed: 2025-10-15 External Links: Link Cited by: §1, §2.2, §2.2.
- S. Nedelkoski, J. Bogatinovski, A. K. Mandapati, S. Becker, J. Cardoso, and O. Kao (2020) Multi-source distributed system data for ai-powered analytics. In Service-Oriented and Cloud Computing, A. Brogi, W. Zimmermann, and K. Kritikos (Eds.), Cham, pp. 161–176. External Links: ISBN 978-3-030-44769-4 Cited by: Table 1.
- L. Pham, H. Zhang, H. Ha, F. Salim, and X. Zhang (2025) RCAEval: a benchmark for root cause analysis of microservice systems with telemetry data. In Companion Proceedings of the ACM on Web Conference 2025, WWW ’25, New York, NY, USA, pp. 777–780. External Links: ISBN 9798400713316, Link, Document Cited by: Table 1.
- Prometheus Authors (2025) Prometheus: monitoring system & time series database. External Links: Link Cited by: §2.3.1.
- J. Soldani and A. Brogi (2022) Anomaly detection and failure root cause analysis in (micro) service-based cloud applications: a survey. ACM Comput. Surv. 55 (3). External Links: ISSN 0360-0300, Link, Document Cited by: §1, §2.2.
- M. Steidl, B. Dornauer, M. Felderer, R. Ramler, M. Racasan, and M. Gattringer (2024) How industry tackles anomalies during runtime: approaches and key monitoring parameters. In 2024 50th Euromicro Conference on Software Engineering and Advanced Applications (SEAA), Vol. , pp. 364–372. External Links: Document Cited by: §1, §2.2.
- The JaCoCo Team (2025) JaCoCo – java code coverage library. Note: Accessed: 2025-10-20 External Links: Link Cited by: §2.3.2.
- Verica, Inc. (2024) The verica open incident database (void) report 2024. Note: Accessed: 2025-10-15 External Links: Document, Link Cited by: §1, §2.2.
- Y. Wang, M. V. Mäntylä, S. Demeyer, M. Beyazıt, J. Kisaakye, and J. Nyyssölä (2025a) Cross-system categorization of abnormal traces in microservice-based systems via meta-learning. Proc. ACM Softw. Eng. 2 (FSE). External Links: Link, Document Cited by: §1.
- Y. Wang, M. V. Mäntylä, J. Nyyssölä, K. Ping, and L. Wang (2025b) Cross-system software log-based anomaly detection using meta-learning. In 2025 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER), Vol. , pp. 454–464. External Links: Document Cited by: §1.
- G. Yu, P. Chen, Y. Li, H. Chen, X. Li, and Z. Zheng (2023) 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, ESEC/FSE 2023, New York, NY, USA, pp. 553–565. External Links: ISBN 9798400703270, Link, Document Cited by: Table 1, §1.
- C. Zhang, X. Peng, C. Sha, K. Zhang, Z. Fu, X. Wu, Q. Lin, and D. Zhang (2022) DeepTraLog: trace-log combined microservice anomaly detection through graph-based deep learning. In Proceedings of the 44th International Conference on Software Engineering, ICSE ’22, New York, NY, USA, pp. 623–634. External Links: ISBN 9781450392211, Link, Document Cited by: Table 1, §1.
- S. Zhang, S. Xia, W. Fan, B. Shi, X. Xiong, Z. Zhong, M. Ma, Y. Sun, and D. Pei (2025) Failure diagnosis in microservice systems: a comprehensive survey and analysis. ACM Trans. Softw. Eng. Methodol.. Note: Just Accepted External Links: ISSN 1049-331X, Link, Document Cited by: §1.
- X. Zhou, X. Peng, T. Xie, J. Sun, C. Ji, W. Li, and D. Ding (2021) Fault analysis and debugging of microservice systems: industrial survey, benchmark system, and empirical study. IEEE Transactions on Software Engineering 47 (2), pp. 243–260. External Links: Document Cited by: §1, §2.1, §2.2.