Core Components of the Monitoring Framework Sample Clauses

Core Components of the Monitoring Framework. ‌ The monitoring system collects and stores data that is used as input to the Digital Twin (DT) with the quality of the data being critical to the performance of the DECICE scheduler which uses the data from the DT. The monitoring framework needs to collect and aggregate metrics about the current system state from a variety of devices such as Internet of Things devices, cloud worker nodes, and high performance computing nodes. This can be achieved by accessing the underlying platforms through their interfaces such as the Kubernetes API on the cloud or KubeAPI on edge. Here we present a PoC setup for the monitoring framework outlining the main tools and technologies employed. In section 7.2 a more detailed description of the architecture and deployment model will be given. Prometheus [1] is a time-series-based metric collection system that plays a central role in our monitoring framework. It monitors and collects metrics from various targets, such as applications, services, and infrastructure components in a highly scalable and efficient manner. It operates based on a client-server architecture where the Prometheus server periodically retrieves metrics from client components if it knows how to reach them. Figure 3 below introduces how Xxxxxxxxxx works. The following paragraphs introduce the most important components of Prometheus. Figure 1: Architecture of Prometheus [1]. Exporters are small processes responsible for exposing specific metrics from applications or systems. They can be thought of as the client in the client-server model (with Prometheus being the server). They can be categorized into standalone exporters e.g. a commonly used exporter is the Node Exporter for various server metrics. And application exporters e.g. an exporter for a database like Elasticseach [3] or an API like FastAPI [9]. Prometheus pull mode. Xxxxxxxxxx uses a pull-based model for data collection, meaning that it periodically scrapes metrics from configured targets over HTTP. This monitoring method contrasts with the push model used in many other monitoring systems. In the push model paradigm application code is commonly modified to send metrics to the server periodically. The advantage of the pull model is that it does not require the systems or applications that are being monitored to be aware of the Prometheus server, so it can be added to a monitoring system without making changes to the application code. Furthermore, the pull model only collects metrics when they are nee...