# Anomaly Detection in Microservice-Based Systems
## 2 Data and Materials
### Load Testing and Anomaly Creation  
After the system was installed, it was simulated to mimic a real-world system. For this, a load-testing framework, Locust ([[https://locust.io/](https://locust.io/)]([https://locust.io/](https://locust.io/))(accessed on 1 May 2023)), was used. The load-testing scripts were written in Python and simulated normal user usage of an e-commerce system, such as creating users, authenticating users, searching for products, browsing the product catalog, purchasing products. With this, these scripts will simulate the expected behavior of users of this system. This study creates an anomaly generation module, generating anomalies at both the application and service levels. Application-level anomalies refer to anomalous behavior that occurs at the level of the entire application. In order to generate this type of anomaly, stress was simulated on the CPU, disk, and memory using _Stress-ng_ ([[https://wiki.ubuntu.com/Kernel/Reference/stress-ng](https://wiki.ubuntu.com/Kernel/Reference/stress-ng)]([https://wiki.ubuntu.com/Kernel/Reference/stress-ng](https://wiki.ubuntu.com/Kernel/Reference/stress-ng))(accessed on 1 May 2023)) software. Increased latency and packet loss on the  
Figure 1: General architecture of the microservices system used with the integration of observability components (Prometheus, Grafana) used to create the dataset for training and model validation. network were also generated with _tc_ ([[https://man7.org/linux/man-pages/man8/tc.8.html](https://man7.org/linux/man-pages/man8/tc.8.html)]([https://man7.org/linux/man-pages/man8/tc.8.html](https://man7.org/linux/man-pages/man8/tc.8.html))(accessed on 1 May 2023)) software. As the application is contained in a Kubernetes environment, the anomalies were injected at the server, _Pod_ ([[https://kubernetes.io/docs/concepts/workloads/pods/](https://kubernetes.io/docs/concepts/workloads/pods/)]([https://kubernetes.io/docs/concepts/workloads/pods/](https://kubernetes.io/docs/concepts/workloads/pods/))(accessed on 1 May 2023)), and _DaemonSet_ ([[https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/)]([https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/))(accessed on 1 May 2023)) levels. The service-level anomalies were generated by changing the source code of Orders and Carts to change the normal behavior of the respective services. For this, the _Hystrix_ ([[https://github.com/Netflix/Hystrix](https://github.com/Netflix/Hystrix)]([https://github.com/Netflix/Hystrix](https://github.com/Netflix/Hystrix))(accessed on 1 May 2023)) framework was used, which helps to control the interaction between services to inject anomalies. In order to simulate real-world data, performance and functional anomalies are injected at the service level. Performance anomalies refer to deviations from expected performance metrics, such as request response time. On the other hand, functional anomalies refer to deviations from the expected behavior of the service in terms of its intended functionality or purpose. As illustrated in Algorithm 1, to inject artificial performance anomalies, a procedure was created that injects unspecified waiting time into the processing of each request by the respective services. Consequently, the response time of the respective service will increase, thus creating an artificial performance anomaly. To inject functional anomalies, as seen in the procedure _GenerateFunctionalAnomaly_, an additional procedure that throws an unexpected artificial exception was implemented, so the request is not processed and returns an error, thus creating a functional anomaly. The two types of anomalies were executed in the Orders and Carts services of the created application and, thus, being able to identify in the dataset which services are anomalous.