# Containerised Application Profiling and Classification Using Benchmarks
## 3 Application Profiling System Architecture  
The application profiling system is developed by using the Node RED flow-based programming framework ([[https://nodered.org/](https://nodered.org/)]([https://nodered.org/](https://nodered.org/)), accessed on 15 November 2022). This framework has a great variety of different nodes which help with the communication of different components in order to obtain the functionality needed. In addition, given the heterogeneity of hardware and APIs of the cloud-edge environments, it provides the necessary communication nodes for data exchange and manipulation of external resources. Application profiling system can function with different container environments (Docker, Kubernetes), but for research work conducted for this paper the container environment used is Docker. Containerised environments are proven to produce little to no overhead in the performance of the applications [21], thus minimising the interferences produced by the operating system used. Furthermore, the internal tools provided by the container environment engine are consistent and precise, reducing the usage of other external tools for metric collection. The application profiling system has two major components in order to work--the profiling component and the model trainer component. The profiling component is responsible for the creation of the multidimensional vector that represents the profile of the resource usage of a benchmark or application. As far as the profiling component is concerned, there are three main processes in the form of Node RED flows (as depicted in Figure 2) that are performed in order to create the profile, and these flows have the following functions. Metric endpoint configuration: In order to communicate with the appropriate Docker command line interface (CLI) and collect the Docker metrics for the container that runs a benchmark or an application, the appropriate configuration must be performed. The information needed for a new profile to start is the endpoint of the Docker machine and the container ID. In the case of benchmark profiling, the name of the benchmark as well as the workload are also needed in order to store the profile for training the model. In the case of application profiling, no extra information is needed. 2. Raw data collection and storage: After the successful communication with the Docker CLI, the application profiler collects the metrics for the resource usage of the specific container (Docker produces these metrics and delivers them to the users using the Docker stats service). These metrics are stored temporarily in a collection in the database. Some of the temporarily stored metrics will be used without any other computation, directly for the profile creations; others are stored in order to produce metrics that require more computations, such as mean values and deviations of specific metrics. 3. Profile creation and storage: When the metric extraction is finalised, then the temporarily stored metrics are retrieved in order to compute all the features of the profile (vector). In the case the profile created is from an execution of a benchmark; then it is stored in a specific collection in the database in order to be used for the model training and evaluation. If the profile is extracted from a running application, then it is sent to the classification model to be classified. The model trainer component is responsible for creating the classification model for the applications. All the stored benchmark profiles are fed to the classifier trainer. A subset of these data will be used for training, and the other subset will be used for evaluating the accuracy of the produced model. This component also has three main processes that created the component's functionality; these flows, as shown in Figure 3, perform the following functions. 1. Data preparation: This process is in charge of all the first steps for data preparation and transformation.