Prior works have noted that existing public traces on anomaly detection and bottleneck localization in microservices applications only contain single, severe bottlenecks that are not representative of real-world scenarios. When such a bottleneck is introduced, the resulting latency increases by an order of magnitude (100x), making it trivial to detect that single bottleneck using a simple grid search or threshold-based approaches.

To create a more realistic dataset that includes traces with multiple bottlenecks at different intensities, we carefully benchmarked the social networking application under different interference intensities and duration of interference. We chose intensities and duration values that degrade the application performance but do not cause any faults or errors that can be trivially detected. We induced interference on different VMs at different times and also simultaneously. A single VM could be induced with different types of interference (e.g., CPU and memory), resulting in the hosted microservices experiencing a mixture of interference patterns. The resulting dataset consists of around 40 million request traces along with corresponding time series of CPU, memory, I/O, and network metrics. The dataset also includes application, VM, and Kubernetes logs.

A detailed description of the files is provided in the Data Explorer section. Please reach out to gagan at cs dot stonybrook dot edu if you have any questions or concerns.

If you find the dataset useful, please cite our WWW'24 paper "GAMMA: Graph Neural Network-Based Multi-Bottleneck Localization for Microservices Applications." Citation format (bibtex):

author = {Somashekar, Gagan and Dutt, Anurag and Adak, Mainak and Lorido Botran, Tania and Gandhi, Anshul},
title = {GAMMA: Graph Neural Network-Based Multi-Bottleneck Localization for Microservices Applications.},
year = {2024},
publisher = {Association for Computing Machinery},
address = {New York, NY, USA},
url = {https://doi.org/10.1145/3589334.3645665},
doi = {10.1145/3589334.3645665},
booktitle = {Proceedings of the ACM Web Conference 2024},
location = {Singapore},
series = {WWW '24}
}```

This is a microservices dataset. For an exclusive explanation, please take a look at the paper and at the online appendix: https://github.com/darioamorosodaragona-tuni/Microservices-DatasetIn particular, this file contains all the projects labeled as:- Is it a microservices?: Yes | Uknown- Archived: Yes | NoCopyright:Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for third-party components of this work must be honored. For all other uses, contact the owner/author(s). MSR ’24, April 15–16, 2024, Lisbon, Portugal © 2024 Copyright held by the owner/author(s). ACM ISBN 979-8-4007-0587-8/24/04 https://doi.org/10.1145/3643991.3644890

The dataset titled "Greedy Multi-Cloud Selection Approach to Deploy an Application Based on Microservices" consists of 400,000 rows and 11 columns, capturing various parameters essential for deploying microservices-based applications across multiple cloud environments. This dataset is designed to simulate and analyze the deployment decisions and outcomes when using a greedy algorithm approach for cloud provider selection.

Columns Overview: Application ID: Unique identifier for each application instance. Microservice Name: Name of the microservice within the application. Cloud Provider: Chosen cloud provider for deploying the microservice (e.g., AWS, Azure, Google Cloud, IBM Cloud). Region: Geographic region where the cloud provider's data center is located (e.g., US-East, EU-West, Asia-Pacific). Resource Utilization (%): Percentage of allocated resources utilized by the microservice. Latency (ms): Average latency experienced by the microservice in milliseconds. Cost ($): Deployment cost in US dollars incurred by the microservice. Deployment Time (hrs): Time taken to deploy the microservice in hours. Success Rate (%): Percentage of successful deployments for the microservice. Data Transfer (GB): Amount of data transferred by the microservice in gigabytes. Environment: Deployment environment phase (e.g., Development, Testing, Production). Dataset Usage: This dataset facilitates research and analysis into the efficacy of a greedy algorithm for selecting optimal cloud providers based on various performance and cost metrics. Researchers and practitioners can use this dataset to:

Evaluate the impact of cloud provider choice on resource utilization and deployment costs. Analyze latency variations across different geographic regions and cloud providers. Assess the success rate of deployments and its correlation with selected cloud providers and deployment environments. Model and optimize deployment strategies for microservices-based applications in diverse cloud environments. Data Characteristics: The data ranges were simulated to reflect realistic scenarios encountered in multi-cloud deployments, ensuring variability in cloud provider performance and deployment outcomes. Random generation methods such as uniform distributions for costs and deployment times, normal distributions for latency, and categorical choices for cloud providers and deployment environments provide a diverse yet controlled dataset suitable for comprehensive analysis.

Potential Applications: This dataset is valuable for researchers, data scientists, and cloud architects involved in optimizing cloud resource utilization, minimizing deployment costs, and enhancing application performance through effective cloud provider selection strategies. It can also serve as a benchmark for comparing different algorithms and methodologies in the field of multi-cloud deployment and management.

The work contains ten datasets containing monitoring data (logs, Jaeger Traces and Prometheus KPI data). The datasets contain monitoring data from train-ticket, a benchmark system for microservices. The dataset includes a short description with explanations of identified anomalies.

The structure of the folder is as follows:

Each folder stores the respective data:

1. Logs:
   • original log file: LOGS_
   • parsed log files required for Loglizer (anomaly detection technique):
     • LOGS_
     • LOGS_
2. KPI Data: Monitoring_
3. Traces: Traces_

Welcome to Microservices and Distributed Systems - one of the most in-demand courses on the platform and for a good reason, microservices are quickly becoming the dominant framework in the field and a critical skill for a professional Java developer. The course will be a lot of hands-on, building a distributed application and learning the exact technology stack that makes a microservice tick. Join me today and master microservices with:​ •20-chapter roadmap made up of over 10 hours of video content: From fundamentals of the architecture to application deployment. •156 lessons: A step-by-step practical guide through every technology. •Microservices Application building: A comprehensive guide to give you all the knowledge needed to deploy components yourself. •Dedicated Discord Channel: Where you will be able to find answers to all your questions and chat with me and the students.

This is the dataset for replicability for the article "Detection Strategies for Microservice Security Tactics." It provides the code needed to replicate the study in the article and the model data set of 10 system models and 20 variants of those models.

The abstract of the article is:

Microservice architectures are widely used today to implement distributed systems. Securing microservice architectures is challenging because of their polyglot nature, continuous evolution, and various security concerns relevant to such architectures. This article proposes a novel, model-based approach providing detection strategies to address the automated detection of security tactics (or patterns and best practices) in a given microservice architecture decomposition model. Our novel detection strategies are metrics-based rules that decide conformance to a security recommendation based on a statistical predictor. The proposed approach models this recommendation using Architectural Design Decisions (ADDs). We apply our approach for four different security-related ADDs on access management, traffic control, and avoiding plaintext sensitive data in the context of microservice systems. We then apply our approach to a model data set of 10 open-source microservice systems and 20 variants of those systems. Our results are detection strategies showing a very low bias, a very high correlation, and a low prediction error in our model data set.

The dataset is based on a dataset from a previous article: https://zenodo.org/record/6424722

Dataset

This dataset was created by temp123$

Contents

This repository contains two datasets used for anomaly detection in microservices-based systems. The datasets are summarized versions of several CSV files containing data from normal and anomalous instances. The two datasets provided here are representative of service and application anomalies. For more detailed information, please refer to the README file included in the repository.

We are releasing the tracing dataset of four microservice benchmarks deployed on our dedicated Kubernetes cluster consisting of 15 heterogeneous nodes. The dataset is not sampled and is from selected types of requests in each benchmark, i.e., compose-posts in the social network application, compose-reviews in the media service application, book-rooms in the hotel reservation application, and reserve-tickets in the train ticket booking application. The four microservice applications come from DeathStarBench and Train-Ticket. The performance anomaly injector is from FIRM. The dataset was preprocessed from the raw data generated in FIRM's tracing system. The dataset is separated by on which microservice component is the performance anomaly located (as the file name suggests). Each dataset is in CSV format and fields are separated by commas. Each line consists of the tracing ID and the duration (in 10^(-3) ms) of each component. Execution paths are specified in execution_paths.txt in each directory.

A dataset containing system and service performance metrics

The Cloud Microservices Market Report is Segmented by Component (Platform, and Services), Enterprise Size (Small and Medium Enterprises, and Large Enterprises), End-User Industry (BFSI, Retail and E-Commerce, Manufacturing, IT and Telecom, Healthcare and Life Sciences, and More), Cloud Type (Public Cloud, Private Cloud, and Hybrid and Multi-Cloud), and Geography. The Market Forecasts are Provided in Terms of Value (USD).

In 2022, ** percent of respondents currently using microservices state that it is extremely important for organizational operations. This was followed by majority of the respondents at ** percent agreeing that it is very important in the same year.

Unlock the potential of microservices! Explore the booming microservice architecture market, its key drivers, challenges, and regional trends. Discover leading companies and investment opportunities in this rapidly expanding sector. Learn more about the projected market size and CAGR through 2033.

Dataset used by the paper MADE: Learning to Detect and Explain Chaos in Microservice Architectures

Include the raw dataset of 10 chaos

This is the Bibliographic Dataset on Microservices and Security of the paper: Microservice Security: A Systematic Literature Review

This dataset contains scraped data from 11 open-source repositories that implement microservices architecture. The data includes issues, commits, and pull requests, providing insights into the collaborative development processes, version control activities, and maintenance efforts in microservices-based projects. The dataset is intended for research purposes in software engineering, repository mining, and data analysis.

This dataset accompanies an anonymized manuscript on AI-driven microservice deployment.It contains the screened study list, inclusion/exclusion flags, quality scores, and RQ mappings. Personal identifiers were removed from files and metadata.

Microservices is a popular architectural style for the development of distributed software, with an emphasis on modularity, scalability, and flexibility. Indeed, in microservice systems, functionalities are provided by loosely coupled, small services, each focusing on a specific business capability. Building a system according to the microservices architectural style brings a number of challenges, mainly related to how the different microservices are deployed and coordinated and how they interact. In this paper, we provide a survey about how techniques in the area of Artificial Intelligence have been used to tackle these challenges.

This is part of the runtime traces of anomaly detection and replica prediction.

• MicroserviceData.csv relates to containerized microservices CPU and memory requirements as well as a number of replicas.
• DeviceData.csv provides CORE utilization trace data within 1440 hours.

Microservices are an architectural style for software which currently receives a lot of attention in both industry and academia. Several companies employ microservice architectures with great success, and there is a wealth of blog posts praising their advantages. Especially so-called Internet-scale systems use them to satisfy their enormous scalability requirements and to rapidly deliver new features to their users. However, microservices are not only popular with large, Internet-scale systems. Many traditional companies are also considering whether microservices are a viable option for their applications. However, these companies may have other motivations to employ microservices, and see other barriers which may prevent them from adopting microservices. Furthermore, these drivers and barriers may differ among industry sectors. This dataset contains the questions and results of a survey on drivers and barriers for microservice adoption among professionals in the German software industry. In addition to overall drivers and barriers, we particularly focused on the use of microservices to modernize existing software, with special emphasis on implications for runtime performance and transactionality.