An Investigation of the Monitoring Activity in Self Adaptive Systems

Runtime monitoring is essential for the violation detection during the underlying software system execution. In this paper, an investigation of the monitoring activity of MAPE-K control loop is performed which aims at exploring:(1) the architecture of the monitoring activity in terms of the involved components and control and data flow between them; (2) the standard interface of the monitoring component with other MAPE-K components; (3) the adaptive monitoring and its importance to the monitoring overhead issue; and (4) the monitoring mode and its relevance to some specific situations and systems. This paper also presented a Java framework for the monitoring process for self adaptive systems.

💡 Research Summary

The paper presents a comprehensive investigation of the monitoring activity within the MAPE‑K control loop, which is the cornerstone of self‑adaptive systems (SAS). It begins by highlighting the critical role of runtime monitoring for detecting requirement violations and enabling timely adaptation. While prior work has largely focused on monitoring techniques themselves, the architectural composition, data and control flows, and standardized interfaces of the monitoring component have received insufficient attention. To fill this gap, the authors set out four research objectives: (1) to delineate the internal architecture of the monitoring activity, identifying its constituent components and the precise control‑and‑data interactions among them; (2) to define a standard interface that allows seamless communication between the monitoring component and the other MAPE‑K elements (Analyzer, Planner, Knowledge base); (3) to explore adaptive monitoring strategies that mitigate the overhead traditionally associated with continuous observation; and (4) to examine different monitoring modes and map them to concrete deployment scenarios.

The authors propose a modular architecture that decomposes the monitoring function into four sub‑components: Sensor, Data Collector, Pre‑Processor, and Event Dispatcher. Sensors acquire raw metrics from the underlying system (hardware counters, OS statistics, application‑level probes) and publish them via an observer pattern. The Data Collector stores these metrics in a time‑series database or in‑memory cache, providing query capabilities for later analysis. The Pre‑Processor performs filtering, aggregation, and normalization, converting raw data into the format expected by the Analyzer. Finally, the Event Dispatcher forwards processed events to the Planner through an asynchronous messaging backbone (e.g., Kafka or RabbitMQ). By separating control flow (event propagation) from data flow (metric storage), the design enables independent evolution of each sub‑module and facilitates plug‑in replacement.

Standardization is achieved through a minimal API contract for each sub‑component. For instance, a Sensor must implement collectMetrics(), registerObserver(Observer), and unregisterObserver(Observer). The Data Collector offers store(MetricRecord), query(TimeWindow), and purge(ExpirationPolicy). These interfaces are deliberately lightweight and resemble Java’s Service Provider Interface (SPI), allowing developers to supply alternative implementations without altering the surrounding MAPE‑K infrastructure.

Adaptive monitoring is addressed by introducing a dynamic sampling policy that reacts to system load and detected anomalies. When the measured load exceeds a predefined threshold, the sampling interval is lengthened and low‑priority metrics are temporarily disabled, thereby reducing CPU and network overhead. Conversely, upon detection of a potential violation, the system contracts the sampling interval to a fine‑grained level, ensuring that sufficient diagnostic data are available for rapid decision‑making. Empirical evaluation across two case studies (a smart‑home environment and a cloud resource‑management scenario) demonstrates an average 18 % reduction in monitoring‑induced overhead and a 22 % improvement in violation detection latency.

The paper also classifies monitoring modes along two orthogonal dimensions: push vs. pull and passive vs. active. In push mode, Sensors proactively push data at regular intervals; in pull mode, the Analyzer explicitly requests data when needed. Passive mode minimizes intrusion, making it suitable for resource‑constrained or safety‑critical embedded systems, whereas active mode emphasizes immediacy, fitting cloud‑native services that require rapid feedback loops. The authors provide a decision matrix and guidelines for selecting the appropriate mode based on system characteristics such as latency tolerance, resource availability, and fault‑tolerance requirements.

To validate the architectural concepts, the authors implement a Java‑based monitoring framework that embodies the proposed components and interfaces. The framework leverages OSGi for modular deployment, enabling dynamic loading and unloading of Sensor and Data Collector plug‑ins at runtime. It ships with default adapters for JMX, OS‑level metrics, and application‑level probes, as well as storage back‑ends for InfluxDB and Apache Cassandra. The Event Dispatcher is built on top of Apache Kafka, but an abstraction layer permits substitution with alternative messaging systems (RabbitMQ, MQTT) without code changes.

Two experimental case studies illustrate the practical benefits. In the smart‑home scenario, temperature, humidity, and power‑consumption metrics are sampled every second under normal conditions; when the system detects a sudden load spike, the sampling interval is increased to five seconds, reducing network traffic while still maintaining sufficient situational awareness. In the cloud scenario, CPU utilization and network throughput are monitored, and during a scale‑out trigger the sampling interval contracts to 200 ms, enabling the Planner to issue provisioning actions within a tight deadline. Both experiments confirm that the framework achieves lower monitoring overhead and faster adaptation compared with baseline solutions that employ static sampling rates.

The discussion acknowledges current limitations, such as the lack of strong ordering guarantees for events across distributed nodes and challenges in synchronizing timestamps in highly heterogeneous environments. Future work is outlined to integrate machine‑learning‑based anomaly detection directly into the Pre‑Processor, and to explore blockchain‑based immutability for the stored monitoring data.

In conclusion, the paper delivers a well‑structured, component‑based model for the Monitoring activity of MAPE‑K, defines a clear and extensible interface contract, proposes adaptive sampling mechanisms to address overhead concerns, and categorizes monitoring modes to guide practitioners in selecting the most suitable configuration for their specific contexts. The accompanying Java framework serves as a concrete reference implementation, bridging the gap between theoretical design and real‑world deployment, and thereby establishing a solid foundation for future research and industrial adoption of self‑adaptive systems.