Resource Exposer (RE) in Cloud-Edge Orchestration
- Resource Exposer (RE) is a lightweight, technology-agnostic data-acquisition module that quickly discovers, registers, and exposes node telemetry for cold-start predictive orchestration in the Cloud-Edge Continuum.
- It employs a plugin-based, gRPC communication framework to integrate with diverse telemetry sources, using brokers for short-term caching and normalized data exposure.
- By merging sparse local telemetry with high-resolution datasets like TimeTrack and leveraging Neural Architecture Search, RE facilitates fast, accurate forecasting for proactive autoscaling and preemptive migration.
Resource Exposer (RE) is a lightweight, technology-agnostic data-acquisition module in a zero-touch predictive orchestration pipeline for the Cloud-Edge Continuum (CEC). Its function is to discover newly available or changing nodes, register what each node can expose, and immediately collect localized telemetry that can be mixed with the high-resolution TimeTrack dataset to bootstrap accurate time-series models without waiting for long local histories. In the formulation introduced for cloud-edge predictive orchestration, RE supplies the local calibration signal, TimeTrack supplies the structural signal, and a Neural Architecture Search (NAS) engine uses the mixed data to generate deployment-ready predictors for proactive autoscaling and preemptive migration (Meliani et al., 8 Jun 2026).
1. Role in cloud-edge predictive orchestration
In the CEC, edge and far-edge nodes churn, move, sleep, and wake quickly, and their behaviors vary by hardware, microservices, and workloads. The operational consequence is a severe cold-start problem for forecasting-driven orchestration: newly discovered nodes do not yet have enough historical telemetry to support localized models, while models trained elsewhere generalize poorly to node-specific behavior. RE addresses this by discovering nodes dynamically and sensing them immediately, exposing localized telemetry such as CPU, memory, disk throughput, network latency and jitter, interface errors, energy or thermal indicators, and microservice metrics (Meliani et al., 8 Jun 2026).
RE is therefore positioned upstream of forecasting rather than inside the orchestrator itself. The orchestrator consumes forecasts such as CPU or memory demand to drive proactive autoscaling or migration logic, but RE is responsible for making volatile infrastructure observable in a forecasting-ready form. This separation is explicit: exposure and orchestration are distinct concerns, allowing RE to operate with Kubernetes, K3s, bare-metal clusters, or bespoke edge stacks. A common misconception is to treat RE as a monitoring backend or orchestration engine; in the zero-touch pipeline it is neither. It is the sensing and short-term exposure layer that enables the downstream modeling pipeline to operate under churn.
The cold-start mitigation strategy depends on data mixing. Sparse local samples collected by RE are merged with TimeTrack, a publicly available dataset collected at 45-second intervals on seven physical machines. The evaluation uses the standard forecasting metrics
and
This suggests that RE is best understood as the calibration interface between a newly observed node and a forecasting stack that otherwise lacks enough local evidence to specialize.
2. Architectural organization
The architectural design goals are technology-agnostic operation, a plugin-based structure, minimal footprint on constrained edge devices, a unified schema for heterogeneous metrics, fast northbound API responses, and resilience to node churn. RE uses a gRPC plugin-based architecture so that it can communicate with Prometheus exporters, Nagios agents, GPU exporters, and other local sources without hardwiring to a single monitoring stack (Meliani et al., 8 Jun 2026).
| Component | Function | Notes |
|---|---|---|
| Discovery Module | Tracks nodes and capabilities | Uses Local DNS self-registration |
| Collector | Pulls metrics from plugins | Writes to short-term broker cache |
| Broker | Buffers recent windows | Redis Stack in evaluation; RabbitMQ/Kafka/Redis supported |
| Northbound API | Serves normalized telemetry | Unified schema across sources |
The architecture is split into control and data planes. The control plane handles node discovery, registration, capability advertisement, health, and topology updates under churn; this plane is decentralized via Local DNS self-registration. The data plane performs periodic collection from local sources, temporary buffering in the broker, and on-demand exposure to the modeling pipeline. Telemetry is pulled both internally and externally, with short-term caching intended to mimic near-real-time access.
The interface boundaries are equally important. Downstream, the NAS engine consumes the mixed dataset and searches over LSTM, GRU, CNN, TCN, Transformer, MLP, and RNN families with tunables including units, layers, dropout, activations, learning rate, window, batch size, epochs, kernel size, and attention heads. The orchestrator consumes the resulting forecasts for proactive actions and can also query RE directly, for example to corroborate anomalies. This layered organization allows RE to remain a low-footprint exposure mechanism rather than a monolithic telemetry-and-control platform.
3. Discovery, telemetry, and state management
The operational lifecycle begins when a new node powers up. RE starts, self-registers via Local DNS with the Discovery Module, and advertises identity and metric capabilities. The Collector then pulls telemetry from local exporters through gRPC plugins on a configurable interval, samples are normalized and written to the broker for short-term caching, and the central pipeline requests data from the northbound API. RE reads from the broker and exposes fresh telemetry to the preprocessing and mixing stage; forecasts derived downstream then drive orchestration decisions while RE continues collecting and caching telemetry (Meliani et al., 8 Jun 2026).
Node discovery is designed for churn. On registration, RE provides a node identifier and capability metadata such as CPU cores, memory, GPU presence, available metric domains like energy or thermal, and interface lists. When nodes go offline or change capabilities, the Discovery Module updates the directory so that queries target active REs only. This decentralized Local DNS workflow avoids a centralized heavyweight registry and is described as inherently scalable and resilient to churn.
Telemetry domains span compute, storage, network, and infrastructure sensing. The exposed metrics include CPU percentage, per-core utilization, memory used or available, disk read or write throughput, disk usage, RTT min/max/avg/mdev, jitter, interface Rx/Tx throughput, drops, errors, and, when exporters are present, energy and thermal metrics. Microservice-level metrics can be captured through Prometheus or Nagios exporters or custom plugins. Units are normalized as ratios or percentages for CPU, bytes or percentages for memory, MB/s for disk throughput, milliseconds for RTT, jitter, and mdev, Mb/s for interface throughput, and packet counts for drops and errors.
Sampling is configurable. RE collection was profiled from 20 seconds down to 1 second, and these local streams are later aligned with TimeTrack’s 45-second cadence in the mixing stage. The normalized JSON schema includes fields such as node_id, timestamp, a metrics array with name, value, and unit, and optional labels. A per-metric CSV form is also described with aligned timestamps. Sample endpoints are GET /v1/metrics?node_id={id}&window={seconds}, GET /v1/nodes, and GET /v1/health. The broker is automatically purged when the API is idle so that memory usage remains extremely low on far-edge devices. This operational detail is central: RE behaves as a short-window exposure cache, not as a long-term TSDB.
4. Data mixing and NAS-driven model generation
The predictive pipeline centers on combining sparse local telemetry from RE with high-resolution structural data from TimeTrack. Local streams are aligned to TimeTrack’s 45-second cadence, using nearest-neighbor or linear interpolation when local intervals differ. Misaligned or missing points are minimally imputed to avoid biasing bursts, and all metrics are normalized into a common schema and scale so that cross-node ingestion does not require manual cleaning (Meliani et al., 8 Jun 2026).
The mixing protocol used in experiments composes datasets from 1,000 structural samples plus up to 500 localized samples, for a maximum of 1,500 samples. No explicit weighting function is defined; the mixture is formed as a unified training set under the same preprocessing. TimeTrack contributes CPU percentage, memory, disk read and write throughput, per-core CPU utilization, RTT latency statistics, jitter, and interface drops, errors, and throughput, all sampled at 45-second intervals on physical machines. High-resolution temporal structure is thus paired with node-specific local calibration.
The resulting training sets are processed by Microsoft NNI-based NAS. Search strategies include Grid, Random, TPE, Evolutionary, and Simulated Annealing, and the objective is to minimize MAPE, MAE, and MSE. Window sizes are part of the NAS search, with examples in the range of 2 to 30 steps. In zero-touch deployment, a newly registered node initiates the pipeline; once minimal local samples are available and aligned, NAS runs on CPU-only hardware within tight time budgets of 5 to 30 minutes in evaluation.
A key significance of RE emerges here: local data are not treated as sufficient training material, but as a calibration stream that anchors a structural prior derived from TimeTrack. This is why RE is described as essential to cold-start forecasting. Without RE, the system must rely on generic, coarse datasets; without TimeTrack, RE alone may require substantially more local accumulation before a stable model can be produced.
5. Empirical characteristics and performance
The evaluation attributes several performance properties directly to RE-enabled collection and short-term exposure. On a Raspberry Pi 4 with Broadcom BCM2711, quad-core Cortex-A72, 8 GB RAM, Ubuntu 22.04, and containerd, even at a 1-second collection interval, RE plus broker consumed less than 0.04 CPU cores; broker memory peaked at approximately 8.51 MB, while exposer memory remained stable across intervals. This establishes RE as a low-footprint far-edge component rather than a heavyweight observability stack (Meliani et al., 8 Jun 2026).
Query performance also benefits from the broker cache. The northbound API was reported as approximately twice as fast as Prometheus under concurrent loads, with reduced query tail latencies due to short-term caching. This result is operationally important because RE is intended to serve the forecasting pipeline under churn and intermittent connectivity, not merely collect telemetry passively.
The predictive results emphasize the value of RE’s local calibration signal when paired with high-resolution structural data. Coarse baselines alone, specifically Alibaba v2018 and Materna GWA-13 at 5-minute intervals, produced poor accuracy, with MAPE often above 30%; one reported case is Alibaba-only at 57.49% MAPE under Grid at 300 seconds, with MSE 0.002849. TimeTrack-only at 45-second resolution stabilized around approximately 22% MAPE with TPE or Annealing. Local-only training reached approximately 22.04% MAPE at 1200 seconds under Evolution but required more local samples. The best mixed-data results were obtained with local plus TimeTrack: 19.04% MAPE under Simulated Annealing at 1800 seconds, MAE 0.000994, and MSE 0.000163 under Random Search.
Sensitivity analysis reinforces the cold-start claim. With only 10 local samples, local-only models struggled, with Grid around 34.47% MAPE and best Random around 24.72%. By contrast, local plus TimeTrack with 10 local and 1,000 structural samples reached approximately 23.23% with TPE and approximately 24.38% with Random, matching or surpassing local-only models trained with 500 local samples. Coarse mixes such as local plus Alibaba or local plus Materna never broke the approximately 20% barrier even at 500 local samples. Multi-step forecasting showed the same pattern: local plus TimeTrack remained superior out to 5 steps ahead, with 19.04% at horizon 1 and approximately 20.45% at horizon 5, while standalone coarse datasets degraded to approximately 26% or worse at horizon 5, and Grid could spike to approximately 58% MAPE on ali_only.
These results support two technical conclusions. First, RE is valuable because it supplies just enough localized data to adapt a structural baseline to a specific node. Second, the temporal resolution of the structural dataset matters: high-frequency pairing with TimeTrack is reported as necessary, whereas coarse public datasets do not provide the same cold-start benefit.
6. Operational considerations, limitations, and terminological context
Operationally, RE is configured per node according to resource headroom and desired telemetry granularity. A 20-second collection interval is described as typical, though 1-second collection can be used if needed; the mixing stage later resamples to 45 seconds for TimeTrack compatibility. Operators are advised to enable NTP or an equivalent time-synchronization mechanism for aligned timestamps, register plugins per domain, and enable broker purge with an inactivity timeout to cap memory on far-edge nodes. Historical storage, if required, should be offloaded to a separate backend or central pipeline layer rather than implemented inside RE itself (Meliani et al., 8 Jun 2026).
Production security is not the main focus of the predictive orchestration paper, but the stated deployment guidance is explicit: TLS or mTLS should protect the northbound API and gRPC channels, and broker access should be authenticated. This delineates a practical boundary between the evaluated prototype and a hardened deployment. RE is intentionally lightweight and short-lived in its state handling; resilience to transient disconnections comes from the broker’s short-term cache and from churn-aware discovery rather than from persistent local storage.
Two limitations are identified. The framework does not yet automatically compute the optimal number of local samples needed to reach a target accuracy under time constraints, and feature selection is not automated. Future work is described as adding an optimization layer to bound required local telemetry volume per metric, horizon, and SLA, and adding correlation-driven selection of predictive columns from the metrics exposed by RE.
The term “Resource Exposer” is not unique across the literature. In distributed systems, a related but distinct use appears in the RRT runtime, which dynamically exposes arbitrary live application components as Web Services and adds remote references through RAFDA-IORs to support both pass-by-value and pass-by-reference semantics (Walker et al., 2010). In large reasoning model safety, “RE” refers to Recursive Entropy, a metric used by the RECUR attack to expose loop-prone reflective reasoning and associated resource exhaustion rather than a telemetry component (Wang et al., 9 Feb 2026). In digital libraries and eScience, OAI-ORE provides a resource-centric mechanism for exposing bounded aggregations of Web resources through Resource Maps, HTTP URIs, and RDF relations such as ore:describes and ore:aggregates (0804.2273). These usages share the broad idea of making otherwise opaque resources externally accessible, but they refer to different architectural objects, protocols, and problem domains.
Within the CEC forecasting literature, however, RE has a precise meaning: a low-footprint sensing and exposure layer that turns newly discovered, heterogeneous nodes into machine-readable telemetry sources quickly enough for cold-start predictive orchestration to become practical.