Source-linked AI summary
Dynamic Sampling for Telemetry in Microservices: A Reinforcement Learning and Entropy-Based Approach
Renan Martins Alves, Jéferson Campos Nobre, Juliano Araujo Wickboldt
TL;DR
Full trace collection is costly, while static sampling can miss rare events or adapt poorly to changing workloads. RADAR uses reinforcement learning and trace entropy to adjust OpenTelemetry sampling; experiments report large resource reductions while retaining rare trace patterns.
Problem
Full trace collection can overwhelm network bandwidth, consume excessive CPU, and impose prohibitive storage costs, while sampling must preserve information needed for observability as system behavior changes.
Source: §1 · p. 2Method
RADAR combines reinforcement learning with Shannon entropy to adjust OpenTelemetry sampling policies, balancing trace diversity against collection volume.
Source: §4.2 · p. 9, §7 · p. 23Results
97.4% lower bandwidth consumption and 99.0% lower CPU usage than full data collection; RADAR also outperformed fixed 20% sampling in resource efficiency, retained 85.6% of rare trace patterns, and raised stored-data entropy approximately 25%.
Source: §7 · p. 23Takeaways & Limitations
The results validate the feasibility of using entropy to orchestrate telemetry autonomously and efficiently while reducing data volume without sacrificing observability of critical scenarios.
Source: §6.5 · p. 22Evaluation used only the research group’s Minimal Boutique environment, and did not compare against fixed or uniform activation probabilities using the same rule catalog.
Source: §7.2 · pp. 23–24
Abstract
from arXiv · showhide
Microservices architectures are increasingly deployed in cloud-based distributed environments, making application development and maintenance more dynamic, but also increasing the complexity of troubleshooting and observability. Distributed tracing tools are therefore essential for request analysis and debugging, despite introducing additional overhead that can be amplified by excessive and inefficient data collection. This article proposes RADAR (Reinforcement Learning Agent for Dynamic And Relevant trace sampling), an agent that combines reinforcement learning with a data entropy assessment to achieve more efficient capture of traces relevant to system monitoring, based on the OpenTelemetry standard. RADAR tests different sampling rules to discover which combination is most efficient. A test environment simulating a minimalist online store with several microservices distributed across a Kubernetes cluster served as the basis for the experiments, which evaluated the agent's convergence and the system's performance in terms of resource consumption and collected data quality. Results showed that RADAR reduced network bandwidth consumption by 97.4% and CPU usage by 99.0% compared to full data collection, also outperforming a fixed-rate sampling baseline. Beyond these resource savings, the approach preserved observability of critical scenarios, retaining approximately 85.6% of rare trace patterns and increasing the average entropy of the stored information by approximately 25%, validating the feasibility of using entropy to orchestrate telemetry autonomously and efficiently.
1 Introduction
Distributed tracing supports diagnosis across microservices, but full collection is costly and static sampling can miss rare events or fail to adapt to changing behavior. RADAR combines reinforcement learning and Shannon entropy to adjust OpenTelemetry sampling policies at runtime.
1 Introduction
- Full trace collection can overwhelm bandwidth, consume excessive CPU, and impose prohibitive storage costs at scale.Head sampling may miss rare events or errors that appear later in a request, while manual tail-sampling configurations cannot adapt to dynamic cloud workloads.Source: §1 · p. 2
- Sampling must reduce trace volume while preserving information useful for observability as traffic, errors, and execution paths change over time.The paper identifies static, manually defined heuristics as unable to adapt efficiently to complex and variable scenarios.Source: §1 · p. 2
- RADAR uses reinforcement learning to adjust OpenTelemetry sampling policies dynamically, with Shannon entropy rewarding informational diversity over redundant traces.The method is intended to prioritize traces with greater informational diversity while discarding redundant requests.Source: §1 · p. 2
- RADAR selects combinations of tail-sampling rules to preserve diverse, diagnostically useful traces while balancing operational cost and information quality without prior data labeling.Its contributions include an RL agent integrated with OpenTelemetry and a controllable microservices test environment with traffic and fault injection.Source: §1 · p. 3
2 Fundamentals
The paper introduces distributed observability, OpenTelemetry, sampling, Shannon entropy, and reinforcement learning as foundations for RADAR. These concepts frame tracing as a source of diagnostic context and sampling as a trade-off between collection cost and information retained.
2 Fundamentals
- A distributed trace links structured events into a detailed view of a request’s path across services, supporting inference about system state beyond traditional metrics and logs.OpenTelemetry provides a standardized framework for collecting logs, metrics, and traces across programming languages.Source: §2 · p. 3
- OpenTelemetry Collectors ingest, process, and export telemetry, while head sampling decides at request start and tail sampling waits for the trace to finish.Tail sampling can apply criteria such as retaining errors or abnormal latency, but must buffer spans until the decision.Source: §2 · p. 4
- Shannon entropy measures uncertainty in a symbol distribution; rare events contribute more information, and entropy is maximal when symbols are equally likely.The logarithm base is commonly 2, and entropy is non-negative.Source: §2 · p. 4
- Reinforcement learning learns a decision policy through interaction and scalar reward feedback rather than labeled correct answers.The reward guides learning, and its design can lead to undesirable behavior even when the resulting policy optimizes the specified metric.Source: §2 · pp. 4–5
- A Multi-Armed Bandit is a stateless RL setting in which an agent repeatedly selects among fixed actions using reward history rather than state transitions.It suits decisions made independently at each round without tracking an evolving system state.Source: §2 · p. 5
- The MAPE-K model organizes autonomic management into Monitor, Analyze, Plan, and Execute stages around shared persistent Knowledge.Related service-management work has used RL to reconfigure routing, traffic blocking, and scaling, and to support SLA-aware autoscaling.Source: §2 · p. 5
3 Related Work
Related work addresses trace sampling, anomaly capture, and observability through approaches with different assumptions and mechanisms. RADAR instead targets adaptive decisions about which traces to collect, combining reinforcement learning and entropy with OpenTelemetry compatibility.
3 Related Work
- RADAR addresses the upstream question of which traces are worth collecting, whereas root-cause localization and anomaly-detection studies assume traces are already fully collected [19, 20].The compared approaches aggregate invocations and rank root causes with personalized PageRank [19], or model invocation-graph structure and timing with a dual autoencoder.Source: §3 · p. 5
- Unlike static clustering of vectorized traces, RADAR adapts its policy dynamically on standard OpenTelemetry infrastructure without complex data conversion.The compared clustering approach uses Euclidean distance and hierarchical trees to favor rare traces near the root [38].Source: §3 · pp. 5–6
- Where Poghosyan et al. discard rare traces during noise reduction, RADAR seeks to retain rare and anomalous cases through entropy maximization and a reward-guided feedback loop.RADAR also avoids converting hierarchical traces into flat tables for processing.Source: §3 · p. 6
- Unlike manually triggered logging that activates heavier collection after detecting a problem, RADAR adjusts multiple sampling rules through entropy-based decisions in the telemetry collector.The compared system uses declarative triggers and runtime instrumentation.Source: §3 · p. 6
- RADAR operates entirely in user space through OpenTelemetry, unlike eBPF tracing that requires privileged kernel access, and targets cloud microservice orchestration rather than Hubble’s specialized mobile-device domain [24].Hubble requires invasive Android compiler modifications and hand-written assembly for performance-critical code [24].Source: §3 · pp. 6–7
- RADAR combines reinforcement learning and entropy maximization for dynamic sampling without manual triggers or invasive instrumentation, using native OpenTelemetry compatibility.The comparison with related approaches emphasizes differences in sampling and observability strategy.Source: §3 · p. 7
4 Proposal
RADAR is an automated feedback loop that uses trace entropy and volume to learn sampling-rule combinations. The proposal formalizes rule selection as a stateless bandit and trains the agent on successive episodes of collected traces.
4 Proposal
- The proposal combines observability standards, an RL formulation, Shannon entropy as an informational relevance metric, and an automated feedback loop on containerized infrastructure.Its goal is to learn sampling-rule sets that preserve diagnostically useful data while reducing observability cost.Source: §4 · p. 7
4.1 RADAR system architecture
- Traces pass through the OpenTelemetry Collector to a backend and database; extracted entropy and volume statistics inform the agent’s next sampling policy.A Rules Manager applies the selected policy as updated Collector configuration, closing the loop.Source: §4.1 · p. 8, Figure 1 · p. 8
4.2 Reinforcement learning problem formalization
- Because the agent does not observe prior system state, RADAR formalizes rule selection as a combinatorial Multi-Armed Bandit rather than a traditional MDP.The REINFORCE policy-gradient adaptation learns a probability distribution over rule combinations from reward history; each action activates or deactivates catalog policies.Source: §4.2 · p. 9
4.3 Informational relevance via entropy
- RADAR computes trace entropy from deterministic textual representations, ordering spans and filtering high-cardinality attributes while bucketing continuous values such as latency.Entropy is computed over the frequency distribution of unique representations to prioritize anomalous behavior.Source: §4.3 · p. 10
4.4 Training loop
- Each training episode deploys a sampling configuration, waits for stabilization, measures trace entropy and volume, then updates rule-selection probabilities by gradient ascent.The update increases the likelihood of combinations yielding high entropy at low volume.Source: §4.4 · p. 10
5 Prototype
The prototype implements RADAR in Python around an OpenTelemetry tracing stack, with a policy-gradient agent that updates sampling rules using entropy and trace volume. Its components calculate trace quality, deploy updated collector configurations, and coordinate experiments on Kubernetes.
5 Prototype
- The prototype is written in Python and uses Kubernetes, NumPy, and Elasticsearch libraries for orchestration, computation, and observability-backend access.Its three main modules are the RADAR agent, Rules Manager, and Metrics Extractor.Source: §5 · p. 10, §5.2 · p. 11
5.1 Experimental infrastructure
- The tracing stack sends retained traces from the OpenTelemetry Collector to Jaeger and Elasticsearch, which the Metrics Extractor queries for reward inputs.The full stack can run with Docker Compose or on Kubernetes; the reported experiments used Kubernetes.Source: §5.1 · p. 11
5.2 RADAR implementation
- RADAR uses REINFORCE with a combinatorial multi-armed bandit formulation, sampling each catalog policy independently according to its activation probability.The probability updates use an EMA reward baseline to stabilize learning, and probabilities are clipped to [0.01, 0.99] to preserve exploration.Source: §5.2 · p. 11
5.3 Reward function implementation
- The reward combines normalized entropy with a sigmoid trace-volume penalty, balancing information value against collected volume.The implementation sets α = 1.0, β = 1.0, and C = 10,000 traces; the penalty rises sharply beyond the threshold.Source: §5.3 · p. 12
5.4 Metrics extraction and entropy calculation
- Trace entropy is calculated after spans are ordered, noise attributes filtered, and continuous values such as latency quantized into buckets.The frequency distribution of the resulting trace strings is used for entropy calculation; the configuration used throughout the work reduces Rényi entropy to Shannon entropy.Source: §5.4 · pp. 12–14
5.5 Deployment orchestration
- The Rules Manager translates each selected policy set into a Collector configuration, tags traces with an experiment hash, and updates the Kubernetes ConfigMap.It patches the Collector deployment to trigger a rolling update and waits for the desired replicas before measuring the environment.Source: §5.5 · p. 14
6 Experimental Evaluation
In a Kubernetes Minimal Boutique testbed, RADAR converged across tested rule sets and sharply reduced collection costs compared with full collection. It also retained many rare trace patterns, supporting the authors’ conclusion that entropy-based orchestration can balance resource use and observability.
6.1 Experimental environment
- Minimal Boutique provided a controlled seven-service Kubernetes store, while stochastic Locust traffic mixed repetitive traces with a small number of long, complex ones.Each service had its own database, and shared instrumentation made telemetry structurally homogeneous.Source: §6.1 · p. 15
6.2 Convergence experiments
- Both 3- and 12-rule agents converged to stable reward-maximizing policies; 12 rules reached richer data but took longer and collected more traces than 3.The 6- and 9-rule scenarios showed the same trends.Source: Figure 4 · p. 17, §6.2 · p. 17, Figure 5 · p. 18
6.3 Resource consumption
- 9 Kbit/s bandwidth (vs. 344 Kbit/s for the 100% collector and 73 Kbit/s for the 20% collector) and 0.02% CPU (vs. 1.99% and 0.38%) were measured with RADAR.Bandwidth fell by 97.4% versus the 100% collector and 87.7% versus the 20% collector; CPU fell by 99.0% and 94.7%, respectively.Source: §6.3 · pp. 17–18, Figure 7 · p. 19, Figure 8 · p. 19
6.4 Rare trace preservation
- RADAR retained 85.6% of baseline-identified rare patterns; unique patterns were 94.0% of RADAR traces versus 13.0% of baseline traces.A trace counted as rare if it appeared only once during a test run.Source: Table 4 · p. 21, §6.4 · p. 22
6.5 Discussion
- Stable convergence as rule counts grew supports the feasibility of entropy-based autonomous telemetry orchestration while reducing data volume without sacrificing observability of critical scenarios.The authors contrast this approach with manual tail-sampling configurations that are difficult to maintain in dynamic cloud environments.Source: §6.5 · p. 22
7 Conclusion
RADAR combines reinforcement learning with Shannon entropy to adjust sampling policies autonomously, targeting the trade-off between trace costs and diagnostic value. Experiments report lower resource use while retaining rare trace patterns, but evaluation scope and several design choices limit generalization.
7 Conclusion
- RADAR uses Shannon entropy to distinguish repetitive traces from information-rich, anomalous ones and autonomously adjusts OpenTelemetry sampling policies without direct user intervention.Source: §7 · p. 23
- RADAR reduced bandwidth consumption by 97.4% and CPU usage by 99.0% versus full collection, while retaining approximately 85.6% of rare trace patterns and increasing stored-data entropy by approximately 25%.It also outperformed fixed 20% sampling in resource efficiency.Source: §7 · p. 23
- The authors conclude that entropy-based intelligent agents are a viable, efficient strategy for balancing operational cost and informational value in distributed-system telemetry.Source: §7 · p. 23
7.1 Contributions
- The contributions include a runtime OpenTelemetry sampling agent, an entropy-based reward balancing trace volume and diversity without prior labeling, and a publicly available instrumented microservices testbed.Source: §7.1 · p. 23
7.2 Threats to validity
- Evaluation used only the research group's Minimal Boutique environment, and the study also lacks a matched static same-catalog baseline and systematic reward-hyperparameter sensitivity analysis.The authors also did not quantify the operational cost or transient disruption of collector rolling updates.Source: §7.2 · pp. 23–24
7.3 Future work
- Future work proposes probabilistic rule activation, adding cluster state and business-impact metrics, and validation on independent benchmarks.Source: §7.3 · p. 24