arXiv CSopen access

Spanergy: Energy-aware Distributed Tracing for Microservices

Spanergy: Energy-aware Distributed Tracing for Microservices César Perdigão Batista, Denis Conan, Sophie Chabridon

arXiv:2607.24902v1 [cs.DC] 27 Jul 2026

SAMOVAR, Télécom SudParis, Institut Polytechnique de Paris, 91120 Palaiseau, France {cesar-augusto.perdigao batista, Denis.Conan, Sophie.Chabridon}@telecom-sudparis.eu

Abstract—Cloud computing is gaining popularity by giving access to seemingly unlimited virtual resources. However, Cloud data centres are built with physical resources and their electricity consumption has been continuously growing over the past decades. Microservices are an important building block of Cloud applications, calling for new solutions to observe their energy consumption. Distributed tracing is widely deployed to diagnose latency and failures in microservice-based applications, yet it does not expose the energy cost of individual end-user requests. Such a gap limits energy-aware debugging, accountability, and control. This paper presents Spanergy, an energy-aware distributed tracing approach that correlates permicroservice power measurements with traces and that attributes measured energy consumption to request segments, i.e. trace spans. We showcase Spanergy with synchronous request chains and asynchronous interactions across microservices. We present a rigorous experimental protocol and statistical analysis plan to quantify overhead and to validate conservation and coverage properties on realistic configurations. Enabling OpenTelemetry tracing increased total experiment energy by 59.1% relative to the uninstrumented baseline, and Spanergy post-processing added 15.2% of the baseline energy. Hence, Spanergy’s incremental energy cost is smaller than the energy overhead of enabling tracing itself, making the approach lightweight in practice. Spanergy also reveals that a non-negligible fraction of request energy comes from spans outside the latency-critical path. These results show that energy-aware tracing is feasible at modest overhead and provides actionable insights for energy-efficient microservices. Index Terms—Energy Efficiency, Sustainable Computing, Microservices, Cloud Applications, Distributed Tracing

I. I NTRODUCTION Services enabled by Information and Communication Technologies (ICT) are pervasive and energy-intensive. Estimates place ICT’s share of global greenhouse gas emissions in the 1.8 % to 3.9 % range with a likely upward trend [1]. Cloud data centres alone are projected to increase electricity demand from 292 TWh (2016) to 353 TWh by 2030 under conservative models [2], potentially accounting for over 5 % of CO2 emissions by 2030 [3]. Surveys synthesise techniques spanning infrastructure to application layers for energy efficiency in Cloud systems [4]– [9]. With the rise of microservices, recent studies refine tax© 2026 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works. Accepted version; version of record in Proc. IEEE CCGrid 2026, pp. 276–286, DOI: 10.1109/CCGrid68966.2026.00036.

onomies and identify opportunities particular to containerised, modular systems [10]–[12]. While microservices can improve resource efficiency, they also introduce communication overhead and extensive observability stacks that may affect energy use [13], [14]. In this shift from host and virtual machine controls towards software-level observability and attribution, Distributed Tracing (DT) has matured as a core observability technique to analyse request flows across services [15], [16]. However, DT tools are primarily latency-centric, while energy remains an “odd one out” metric with distinct properties and measurement constraints [17]. DT provides the causal skeleton, where each request corresponds to one trace that contains one or more spans linked by context propagation that preserves the exact path, timing, and concurrency of each request across services. DT does not yet offer a language- and runtime-agnostic way to map a trace to the energy it induces: energy is measured at coarse scopes (host/container), while traces are fine-grained, concurrent, and distributed across microservices that interact both synchronously and asynchronously with each other. As a result, practitioners lack (i) a request-level energy metric that is comparable across endpoints, (ii) diagnostic guidance on where along a request’s execution energy is spent, especially when energy-heavy work is not latency-critical. This gap prevents energy from being treated as a first-class observability concern, for instance, for operational debugging and trade-off analysis. In this paper, we propose refining the architecture of traditional distributed tracing to address the missing link between request causality and measured joules. Our prototype implementation — Spanergy — uses distributed traces as the causal backbone for end-user requests, and in an offline post-mortem enrichment stage, it correlates them with per-microservice CPU power measurements to attribute energy to spans and to entire requests across both synchronous and asynchronous microservice interactions. The main contributions of this paper are the following: • An energy attribution approach at the request level that enables (i) per-request span attribution, (ii) diagnostics that can diverge from latency-only critical path analysis by revealing energy-dominant work outside the latencycritical path, and (iii) endpoint-centric aggregation into a request-level energy catalogue that can support decision making, including transfer of energy profiles across

(often rendered as follows-from in visualisation tools) with the end-user request’s trace, where the propagated context carries the producer’s span identifier.

II. BACKGROUND ON DISTRIBUTED TRACING

III. M OTIVATIONS AND O BJECTIVES

As depicted in Figure 1, the building blocks of distributed traces are spans (A. . . G) [18], [19]. A span represents a unit of work in a microservice. Several spans may coexist in a microservice, thus showing concurrent execution (A. . . D in microservice us1). For instance, a span is created when a microservice receives a request and ends before1 the microservice sends the replies. The treatment of the request may require sending requests to and waiting for replies from other microservices. The corresponding created spans of the addressees are linked with the span of the sender by a child relationship, which is a causal relationship (line with arrow such as A −−→ B). Clearly, when the sender is waiting for the replies, it may consume much less energy. In the case of asynchronous interaction, this corresponds to consuming a message, which leads to the creation of a span. Since the producers and the consumers may not know each other because there exists a publish-subscribe system between them, the link is called a span link or follows-from link in OpenTelemetry terminology (dashed line with arrow such as A −→ E). These are the two causal relationships that we target in this paper. When a request comes from an end user, we call it an enduser request. The first span of an end-user request is tagged with a unique trace identifier and has no parent span, i.e. it is a root span, and the span and trace identifiers are part of the context transmitted to child spans. Other kinds of root spans exist in the OpenTelemetry ecosystem, e.g. the traces that start when consuming a message from a publish-subscribe system or the traces that start when a batch processor starts execution. In this work, we ignore batching and restrict our analysis to spans that (i) belong to the directed acyclic graph (DAG) induced by the parent–child relationship of the enduser request, and (ii) belong to sub-traces that are causally connected to that request through OpenTelemetry span links

In Section III-A, we formulate the three research questions that motivate this study. Then, in Section III-B, we present the illustrative microservice-based application used throughout the paper.

A

1

2

3

4

5

2

3

4

5

3

4

5

us2

journeys that reuse the same endpoints. A prototype implementation that shows that distributed tracing can be enabled with additional energy cost relative to an uninstrumented baseline, and that energy postprocessing incurs a limited overhead that remains controlled. The remainder of this paper is organised as follows. First, we present terminology in Section II. Then, in Section III, we motivate the work by formulating three research questions, and by describing the illustrative microservice-based application used throughout the paper. Sections IV and V present the approach we propose in Spanergy for energy attribution and then evaluate its feasibility under realistic microservice interactions, which include synchronous request chains and asynchronous behaviour. Section VI discusses some work related to distributed tracing and its consideration of energy consumption. Section VII presents the lessons learned throughout answering the research questions.

D4

6

7

8

9

10

11

12

8

9

10

11

12

13

•

1 For the sake of completeness, a child span should be created for sending the reply so that the kind of the request-treatment span is server and the kind of the span for sending the reply is client.

6

E

F

9

us5

us4

C

us3

us1

B

t0

t1

t2

t3

t4

t5 t6

t7

t8

t9

G

t10

11

t11 t12

t13

time

Fig. 1: Spans of a trace with five microservices (us1 . . . us5 )

A. Research questions In this paper, we motivate and study the following research questions. a) Per-request energy estimation: We target applicationlevel design and operation decisions with awareness of infrastructure-level interactions. The scope of this work is request-level energy attribution. Per-request energy estimation is not provided by mainstream tracing platforms, which model requests as DAGs of spans for latency diagnosis, nor by existing energy tools that report host, container, or process-level power without request causality. A principled method that fuses distributed traces with power meters would enable attribution of measured joules to individual requests, supporting per-request budgeting, energy-aware debugging, and comparative evaluation of designs. In this context, we propose the following research question: (RQ1) How to estimate energy consumption of individual end-user requests? b) Latency vs. energy analysis: The relationship between latency and energy is complex and often nonlinear. A span with short duration may consume disproportionate energy if it triggers intensive computation or data movement. Conversely, a long-running span may consume minimal energy if it spends most of its time waiting on I/O or network communication. The latency-critical path pinpoints the longest causally dependent chain that bounds end-to-end response time [20], [21]. A latency-based analysis would then flag a given span only if it lies on the critical path. Similarly, latency slack quantifies tolerance to delay [20], yet it does not track energy under overlap. By attributing measured per–service power to active spans across segments, we obtain span energies that reflect

resource usage during overlap. This enables an energy-critical path that can diverge from the latency-critical path and expose spans that dominate joules even when they do not constrain end–to–end latency. Energy attribution also enables a finer-grained understanding of resource efficiency. Modern data centres employ heterogeneous hardware with varying power characteristics. A span executing on a high-performance processor may complete faster but consume more energy than the same span on a lower-power core. Latency alone cannot distinguish between these scenarios. Energy attribution quantifies the trade-off, allowing operators to make informed decisions about workload placement. For example, if a span has positive latency slack, it can be migrated to a more energy-efficient processor without affecting end-to-end latency. This type of optimisation requires explicit energy measurement and cannot be inferred from timing data. The energy-critical path introduced in this work parallels the latency-critical path but highlights a different set of spans. The energy-critical path surfaces the chain that accumulates the greatest joule cost, even when its spans are overlapped and thus invisible to latency reductions. Therefore, latencycritical spans determine response time, while energy-critical spans dominate energy consumption. In many cases, these paths diverge. A request may have a latency-critical path that involves lightweight coordination spans with minimal energy footprint, while the bulk of energy is consumed by off-latencypath spans performing data processing or external API calls. Therefore, a comparative study of latency vs energy diagnostics quantifies the added value of energy-aware traces, and we formulate the following research question: (RQ2) To what extent does request-level energy attribution from distributed traces yield diagnostic insights that differ from latency-only critical path analysis? c) Request-level energy catalogue: A request-level energy catalogue makes energy attributable to the application’s externally visible endpoints, enabling stakeholders to reason about energy in terms of the same API surface used to design, operate, and govern the system. The catalogue supports concrete questions that cannot be answered from aggregate host or service totals, such as which endpoints explain the largest share of total energy under a given demand mix, and which portions of a journey concentrate energy. This attribution enables prioritisation that is directly actionable, because it identifies where energy is spent in the request space rather than only in infrastructure-level signals. The catalogue is also useful because it can generalise energy insights beyond a single reference journey. If endpoints act as reusable building blocks across multiple journeys, then energy profiles estimated for those endpoints in a controlled reference journey can be transferred to other journeys that reuse the same endpoints, supporting forecasting, budgeting, and governance. This matters for diverse stakeholders. End users can be informed about the relative energy cost of actions and can choose lower energy alternatives when available. Operators and architects can identify energy-dominant request classes

and investigate whether system activity or asynchronous continuations dominate energy. Product owners and sustainability officers can allocate energy cost to features and track whether energy reduction efforts target the endpoints that explain most of the measured energy. We formulate the following research question: (RQ3) How useful can a request-level energy catalogue be for supporting decision making across diverse stakeholders (end-users, operators, architects, product owners, sustainability officers) with respect to generalising energy profiles estimated from a reference user journey to other journeys that reuse the same endpoints? B. Illustrative application Our experiment architecture is based on the microservice multi-language OpenTelemetry Demo (otel-demo) application2 that is representative of observability instrumented microservice-based applications deployed into Clouds. Figure 2 displays the entities of the application. The application includes a frontend, microservices built with different frameworks, a publish-subscribe system (Kafka), configuration components (flagd), and a database (PostgreSQL). Note that, for reproducibility reasons, we have excluded the LLM and the Product Reviews microservices because setting up an underlying LLM model or connecting to an external platform could confound energy measurements. Ad Currency

Database (PostgreSQL)

Cache (Valkey)

Cart Accounting queue (Kafka) Frontend Proxy (Envoy)

Fraud Detection

Checkout

Payment

Flagd

Email Frontend Flagd-ui

Product Catalog Shipping

Quote Recommendation

Fig. 2: Illustrative application: The OpenTelemetry Demo

IV. E NERGY- AWARE D ISTRIBUTED T RACING In Section IV-A, we present an overview of the architecture we have designed for energy-aware distributed tracing. Then, in Section IV-B, we describe the process followed by Spanergy for attributing energy to application spans. Finally, in Section IV-C, we define the notion of energy-critical path and differentiate it from the traditional concept of latency-critical path. A. Architecture for energy-aware distributed tracing Recent research has been advancing on experimental frameworks for modelling energy-efficient microservices. Still, there 2 https://github.com/open-telemetry/opentelemetry-demo/tree/2.1.3

Runtime

Instrumented microservice application OpenTelemetry SDK in microservices

OpenTelemetry pipeline

Power meter

SDK → Collector → Export (OTLP)

Per-microservice power as time series

(Distributed traces)

(software meter)

OTel trace export (spans, ids, timestamps)

Power time series (per microservice)

Spanergy (post-processing core) • Align traces and power on a common timeline • Join power samples with spans by microservice/time overlap • Attribute energy to spans via fair-share across concurrent spans • Derive analysis-ready attributes (coverage, LCP/ECP)

Output A: Enriched traces • energy per span • span attributes

Output B: Analysis artifacts

Fig. 4: Example of an enriched trace visualised using Jaeger

• per-request energy catalogue • per-microservice and endpoint summaries

Fig. 3: Spanergy architecture overview

is a gap towards attributing energy consumption along service call chains [22]. Such a gap is directly addressed by Spanergy’s architecture illustrated in Figure 3. Services are instrumented with OpenTelemetry (OTel) SDKs and export spans via OTLP to the OTel Collector, which decouples instrumentation from the choice of trace backend. OpenTelemetry is adopted because it is vendor-neutral, widely available across languages, and provides standard processing mechanisms (sampling, batching, compression) to control telemetry cost in a portable manner. Spanergy correlates two time-stamped inputs produced during runtime: (i) distributed traces, carrying span identifiers and timestamps, and (ii) per-microservice power time series measured at the process/container scope. Power and traces are recorded in parallel, and later aligned. Spanergy operates offline as post-mortem processing: it reads exported traces and power series, aligns them in time, and assigns measured service energy to spans. Although the architecture is agnostic to the choice of software power meter, the current implementation relies on Scaphandre3 to collect CPU power at process scope before mapping those observations to microservice identifiers. The attribution stage then aligns the resulting power series with trace timestamps. Spanergy outputs (A) enriched traces where each span carries an energy estimate, and (B) analysis artefacts including per-request catalogues, per-microservice and endpoint summaries, and sanity reports containing conservation and cover3 https://github.com/hubblo-org/scaphandre

age checks. The enriched traces remain fully compatible with open-source trace visualisation tools such as Jaeger (Fig. 4), where a distributed trace enriched with Spanergy attributes can be observed. This compatibility matters because it enables energy-aware inspection and debugging within existing observability workflows, without requiring a custom viewer or a new storage backend. B. Energy Attribution In microservice-based applications, several requests can hit the same microservice at the same time, leading to more concurrent spans. Commonly, power is measured for the service as a whole, not per request. The goal is therefore to attribute only the energy actually produced and to split that energy fairly among concurrent spans. In our work, we build tooling—Spanergy—to attribute energy estimates to spans that execute under concurrency: Given per-microservice stepwise power and a set of spans with start/end times, assign nonnegative energy estimates to spans such that (i) the sum equals power integrated over intervals with concurrent spans; (ii) overlap never multiplies energy; (iii) concurrent spans share instantaneous energy equally; (iv) it is computed with a single sweep over sorted boundaries. To build Spanergy, we have to identify assumptions and restrictions to the problem. First of all, we assume that all the timestamps are in the same unit and epoch. During a given time interval (e.g. time interval d = [t4 , t5 ) of Figure 1), we treat power as constant and equal to the left sample (here, power pd is equal to the power at t4 ). This is conservative and matches how sampled signals are usually handled. As already noted, time intervals are right-open to avoid doublecounting the boundary. In addition, when n spans coexist, each receives 1/n of the instantaneous energy. Spanergy attributes the raw service-scope CPU power reported by the software power meter in each time slice. Hence, if no span is active

C. Latency and energy critical paths As depicted in Figure 1, a span is decomposed into span fragments. The latency-critical path is defined as the chain of span fragments that determine the overall response time: If any span fragment on this chain completes earlier, the entire request completes earlier by the same amount [20], [21]. Each span fragment has a duration and we can compute the part of this duration that has no concurrent span fragments from child spans. The latency-critical path is found by starting at the first fragment of the root span and repeatedly selecting the child span fragment that finishes last after accounting for nonoverlapping children. For instance, in Figure 1, the latencycritical path is computed as the following segments: A1–2 + C3–6 + A7 + E8 + F9 + E10 + G11 + E12 + A13 .

A

1

20mJ

2 10mJ

3

4

5

6

10mJ 10mJ

10mJ

7

8

2

3

11 10mJ

12

13

10mJ 20mJ

5

10mJ 10mJ

10mJ

C

4

10 10mJ

10mJ

3

4 10mJ 10mJ

us2

10mJ

5

6 10mJ

us3

B 10mJ

9 10mJ

20mJ 10mJ

us1

D4 50mJ

E

8

20mJ

9 10mJ

us4

F

10

11 10mJ

20mJ

12 20mJ

9

20mJ

us5

on a slice, that slice remains unattributed. If spans are active, the slice energy is shared among them. The current allocator uses equal-share splitting across concurrent spans to ensure deterministic service-scope conservation. Intuitively, as depicted in Figure 1, we cut the timeline whenever anything relevant changes (beginning or end of a span) and we only charge energy to the concurrent spans of a right-open time interval. Since the microservice power is constant during a right-open time interval, the energy in that time slice is power times duration, and each span receives a fair share. Summing a span’s shares over all slices yields its energy, and summing across the spans of a trace yields the request energy. Practically, we normalise microservice identifiers so that traces and power samples match without ambiguity. Instead of checking each span against every energy interval, we create one sorted list of all relevant boundaries (span starts/ends and power changes) and traverse it once. We keep the set of concurrent spans up to date and attribute energy slice by slice. In addition, for the computation of the set of concurrent spans at a given instant t, we encode the right-open semantics by removing, from the active set, the spans that end at t, and then adding the spans that start at t. Finally, we cut the last energy interval at the last span end. This avoids long idle tails that would complicate accounting and audits. Therefore, the energy attribution algorithm can be sketched as follows: 1) Collect boundaries: Take all span starts, span ends, and power-change times; sort and de-duplicate. 2) Apply the tie-break at each boundary: First remove spans that end, then update power if it changes, then add spans that start. 3) Form the next slice: The current boundary and the next boundary define a half-open slice of time. 4) Attribute the slice: If at least one span exists, distribute the slice energy (power × duration) equally among the active spans. 5) Repeat to the end: Continue until the last span end for the service; remove that last span to avoid long idle tails that would complicate accounting; write the assigned energy back to spans.

G

11

20mJ

t0

t1

t2

t3

t4

t5 t6

t7

t8

t9

t10

t11 t12

t13

time

Fig. 5: Span fragments with energy consumption attribution

Once energy has been attributed to spans, we can study the distribution of energy across the trace. By considering the graph of a trace built from child and follows-from relationships between spans and with spans decomposed into span fragments, the energy-critical path is the root-to-leaf path maximising the sum of per-span energies. In Figure 5, we complement Figure 1 with energy consumption attribution. The energy-critical path, that is the path that consumes the most energy, is A1 + B2–3 + D4 + B5 + A6 + E8 + F9 + E10 + G11 + E12 + A13 with 250mJ. V. E XPERIMENTAL EVALUATION This section is organised as follows. First, we specify, in Section V-A, the experimental design used to validate requestlevel energy attribution. We present the scenarios and experimentation protocol in Section V-B. Then, in Section V-C, we detail the metrics used to quantify the incremental energy overhead of Spanergy when moving from scenario S0 with no tracing, to S1 with tracing only, to S2 with tracing plus Spanergy. Next, we describe the validation process in Section V-D and the hypotheses for statistical analysis in Section V-E. Finally, in Sections V-F and V-G, we present the results and discuss threats to validity. The system under test is the OpenTelemetry Demo application, referred to as otel-demo. This application has been selected because it includes synchronous request chains and asynchronous interactions across microservices. The design follows guidance for controlled experimentation and statistical conclusion validity in empirical software engineering [23]–[25]. The acceptability question is framed as an equivalence style comparison, which is appropriate when the objective is to show that an overhead remains below a practical threshold [26]. The analysis can be further assessed using the replication package at https://zenodo.org/records/18677258. A. Testbed and deployment Experiments are executed on the Grid’50004 site in Lyon using the Taurus cluster. Each run reserves one node and starts from a clean operating system image provided by the testbed 4 https://www.grid5000.fr

deployment mechanism. The Taurus nodes in this study have the following configuration. Model is Dell PowerEdge R720. CPU is Intel Xeon E5-2630 Sandy Bridge at 2.30GHz with 2 CPUs per node and 6 cores per CPU. Memory is 32 GiB. The otel-demo application is deployed using Docker Compose. Locust5 is used as the external load generator. The workload is fixed across all the runs triggered by the same Locust script and the same deterministic request sequence, with a fixed total of 6,410 requests that generate internal synchronous and asynchronous microservice interactions. The request mix represents a user journey that includes browsing, cart operations, and checkout, plus auxiliary endpoints. The exact request mix and sequencing are specified by the load generator artefact released with the reproduction package. B. Scenarios and experimentation protocol We define three scenarios: • S0, no tracing. The application executes with tracing disabled at the SDK level and no spans are exported. • S1, tracing only. The application executes with OpenTelemetry tracing enabled using a fixed configuration, with sampler and exporter settings held constant across runs. This scenario captures the energy overhead attributable to tracing, exporting and the presence of the OpenTelemetry Collector. • S2, tracing plus Spanergy. The load phase is identical to S1 and produces the same observability data. After the load completes, Spanergy post-processing executes to compute request-level energy attribution outputs. The energy consumed by this post-processing is treated as Spanergy overhead beyond tracing. The protocol produces 60 runs, and each run includes warmup and cool-down intervals. First, 30 S0 runs are executed sequentially. Then, 30 combined runs are executed sequentially. Each combined run contains Phase 1, which is the load phase under tracing, and Phase 2, which is the Spanergy postprocessing phase executed after Phase 1. In these combined runs, the S1 metric corresponds to the total energy from Phase 1. The S2 metric corresponds to the total energy from Phase 1 plus the energy consumed during Phase 2. C. Metrics, instrumentation, and energy computation The primary metric for the overhead study is the total experiment energy. For a run, the total experiment energy is computed as the sum of energies across all the otel-demo microservices included in the experimental scope. Processlevel power samples are collected and mapped to microservices. For each microservice, samples are treated as a time ordered power series with power in watts and timestamps in seconds. Power telemetry is collected with Scaphandre, which estimates per-process CPU power from Linux powercap/RAPL energy counters and /proc CPU-time accounting between consecutive scrapes. During export, container- and service-level 5 https://locust.io/

power are obtained by aggregating the corresponding PIDs into service-scope series used by the attribution workflow. Energy and overhead metrics are computed on the measurement window that excludes deployment transients. Energy for a microservice is computed using trapezoidal integration over consecutive power samples. For a microservice us with power samples (tk , Pk ) ordered by time, energy is computed as Eus =

n X Pk−1 + Pk k=2

2

× (tk − tk−1 )

(1)

where (tk − tk−1 ) is the elapsed time in seconds and Eus is in joules. If a microservice has only one power sample in the measurement window, trapezoidal integration is not defined. In this rare data quality case, energy is approximated by assuming constant power over a fallback duration, which is computed as the median of per-target median sampling intervals over targets with at least two samples. In this campaign, the median per-microservice power sampling interval is about 2.12s. Span durations are mostly sub-second, with a median around 27ms and P90 around 171ms. This mismatch can bias very short spans. For this reason, the analysis emphasises runlevel and endpoint-level aggregates with confidence intervals and interprets fine-grained span values together with coverage diagnostics. Total energy for a run is computed as X Etot = Eus (2) us∈S

where S is the fixed set of microservices considered for aggregation. In addition to energy, the study records latency and throughput from Locust, CPU and memory utilisation from host and process metrics, and trace volume (number of exported spans during Phase 1 within the measurement window) from exported telemetry artefacts. D. Validation Request-level energy attribution is validated against energy conservation at the microservice horizon. For each microservice us ∈ S, let Eus be the measured microservice energy attr from Eq. 1 over the load window, and let Eus be the sum of Spanergy attributed energies over all the spans executed by us within the same window. The analysis reports the attr conservation ratio rus = Eus /Eus . Ratios above 1 indicate over attribution and must not occur beyond a small tolerance that accounts for numerical and alignment error. The analysis flags microservices with rus > 1.01 and reports the maximum observed violation per run. The analysis also reports 1−rus to quantify energy that is not covered by spans, which captures background activity and gaps in tracing coverage. E. Hypotheses and statistical analysis Let ES0,i denote total energy for S0 run i with i ∈ {1, . . . , 30}. Let ES1,j denote S1 energy corresponding to Phase 1 energy in combined run j and let ESp2,j denote

Phase 2 energy in the same run, with j ∈ {1, . . . , 30}. The S2 energy for combined run j is then ES2,j = ES1,j + ESp2,j . Let µ(·) denote the mean of the underlying distribution of per-run energy for a scenario under the fixed workload. Sample means are denoted by Ē. This sample size supports stable 95% confidence interval estimation for overhead metrics. a) Tracing overhead, S0 to S1: The first hypothesis quantifies the mean energy increase when tracing is enabled. H0,01 : µ(ES1 ) ≤ µ(ES0 )

(3)

H1,01 : µ(ES1 ) > µ(ES0 )

(4)

Since S0 runs and S1 observations come from different runs, inference uses independent sample procedures. The analysis reports the difference in means µ(ES1 ) − µ(ES0 ) and the relative overhead (µ(ES1 ) − µ(ES0 ))/µ(ES0 ), each with 95% confidence. Normality is assessed using the Shapiro- Wilk test [27]. Welch procedures [28] are used as the primary parametric reference due to unequal variance robustness. Practical significance is reported using effect sizes [24]. The analysis reports Hedges g for the standardised mean difference with small sample correction and Cliff’s delta for ordinal dominance. Hedges g is interpreted using standard conventions for small, medium, and large effects. Cliff’s delta is interpreted using the standard magnitude thresholds reported in the literature. b) Spanergy acceptability relative to tracing: The second hypothesis evaluates whether Spanergy overhead remains below the tracing overhead, using µ(ES0 ) as the common baseline. The criterion is µ(ESp2 ) ≤ µ(ES1 ) − µ(ES0 ). This yields H0,A : µ(ESp2 ) ≥ µ(ES1 ) − µ(ES0 )

(5)

H1,A : µ(ESp2 ) < µ(ES1 ) − µ(ES0 )

(6)

The analysis reports the relative Spanergy overhead µ(ESp2 )/µ(ES0 ) with a 95% confidence interval. The analysis also reports the acceptability statistic S = µ(ESp2 ) − (µ(ES1 ) − µ(ES0 ))

(7)

and a one-sided 95% confidence interval computed using delta method standard errors that account for the covariance between ES1,j and ESp2,j within combined runs. This hypothesis structure follows equivalence and non-inferiority reasoning used in experimental software engineering when the objective is to support a bounded overhead claim [26]. F. Experimental results a) Power quality assurance: We seek to establish temporal coherence between Spanergy’s request-level energy and independent observations. Concretely, we assess whether the time profiles Ewall (t), Ehost (t), Eapp (t), and Etrace (t) co-vary, exhibiting similar rises, falls, and event timing, even if their absolute magnitudes differ due to meter scope and granularity. If Etrace (t) follows the same time pattern as Ewall (t), Ehost (t), and Eapp (t) (high correlation, small lag), this supports that Spanergy preserves real energy dynamics at the request level.

Fig. 6: Time-aligned power trajectories across measurement levels

Fig. 7: Power (Pearson) correlation matrix

For this particular question, we select as representative the run whose Phase 1 energy is closest to the median across all combined runs. Figure 6 relates power levels through time, while Figure 7 shows the power correlation matrix for that representative run. The host and summed service power signals co-vary strongly (r = 0.73), and the trace-derived request power tracks both the service aggregate (r = 0.68) and the host signal (r = 0.60). Correlations with the wall meter are weaker (r ∈ [0.32, 0.61]), which is consistent with scope differences and a non-negligible baseline outside the container set. This indicates that trace-derived request energy captures a substantial fraction of the measured service energy dynamics while leaving a remainder attributable to background activity and incomplete coverage. b) Spanergy overhead: The S0–S1 contrast isolates the incremental energy attributable to tracing, exporting, and the Collector under a fixed workload. Figure 8 illustrates energy consumption for the scenarios. Welch inference on run-level totals indicates a mean increase of 103.5 J, with a 95% confidence interval of [99.4, 107.6] J and a relative overhead of 0.591 (95% CI [0.567, 0.616]). The p-value (3.1 × 10−35 ) provides strong evidence against H0,01 . Effect sizes support practical relevance: Hedges g = 13.1 indicates a difference far larger than within-scenario dispersion, and Cliff’s δ = 1.0 indicates complete dominance of S1 over S0 across the observed runs. The acceptability hypothesis evaluates whether Spanergy post-processing remains below the tracing overhead budget

Fig. 8: Energy consumption across scenarios

defined by µ(ES1 ) − µ(ES0 ). The mean relative Spanergy overhead is 0.152 of the S0 baseline (95% CI [0.143, 0.161]). The acceptability statistic in Eq. 7 is negative (S = −77.0 J) and its one-sided 95% upper confidence bound remains below zero (S0.95 = −73.5 J), supporting H1,A under the adopted confidence level. This indicates that the incremental cost of Spanergy post-processing is substantially smaller than the energy already incurred by enabling tracing. c) Per-request energy estimation: The following discussion refers to Research Questions 1 and 3. For RQ3, outputs are considered useful when they support reproducible decisions through stable endpoint ranking, interpretable demandto-service decomposition, or diagnostic signals. When computed repeatedly over comparable intervals, those indicators also form endpoint-level time series that can reveal recurring and seasonal energy demand patterns. Using Spanergy-attributed energies on end-user requests, the analysis constructs a request energy catalogue that maps canonical endpoint signatures to mean end-to-end energy and uncertainty across runs. The resulting footprint is concentrated: POST /api/checkout exhibits a mean of 0.390 J per request (95% CI [0.360, 0.417]), while GET /api/recommendations averages 0.0657 J (95% CI [0.0642, 0.0672]) and POST /api/cart averages 0.0355 J (95% CI [0.0349, 0.0361]). These endpoint-level estimates support reasoning at the API boundary and enable “bill of materials” decompositions of per-microservice estimations into contributions from dominant request types as Figure 9 illustrates. These results show that attribution enables reliable estimation of end-to-end energy for individual end-user requests, with per-endpoint means and confidence intervals that are consistent across runs, hence answering RQ1. In particular, the request-level energy catalogue exposes clear differences between endpoints such as POST /api/checkout and GET /api/recommendations that would remain invisible at host- or servicelevel totals. In a SaaS context, these outputs can support role-specific decisions. Operators can prioritise optimisation on high-joule endpoints. Architects can compare interaction alternatives under joule budgets. Product teams can rank journeys by operational energy footprint. Sustainability teams can monitor endpoint-level progress against reduction targets. End users can be informed about lower energy or quality of service alternatives when equivalent actions exist. d) Span energy in LCP and ECP: The following discussion refers to Research Question 2.

Fig. 9: Endpoint energy composition by microservice

Fig. 10: Span energy distribution by LCP/ECP membership

Classic latency-critical path (LCP) analysis characterises performance using the span chain that dominates end-to-end latency. Spanergy enables a complementary energy-critical path (ECP) view that focuses on attributed energy within the same request. For each end-user request, we compute one latency-critical path (LCP) and one energy-critical path (ECP) on the same trace graph, and treat each path as the set of spans it selects. We then compute a per-request Jaccard overlap |LCP ∩ECP |/|LCP ∪ECP |, aggregate these values within each run, and finally report the mean and confidence intervals across the 30 runs. Across runs, the span-set overlap between LCP and ECP is high but not identical: the mean perrequest Jaccard similarity overlap is 0.872 with a 95% CI of [0.869, 0.875], indicating a systematic yet bounded divergence between latency-dominant and energy-dominant work. From an energy perspective, most span-attributed energy lies on spans that are both latency- and energy-critical. Figure 10 shows that spans in LCP ∩ ECP account for 75.3% of span energy (95% CI [74.8, 75.9]) while representing 57.7% of spans by count. At the same time, 13.9% of span energy lies on ECP-only spans (95% CI [13.4, 14.5]), which are not latency-critical and would be invisible to latency-only diagnoses. The mean share of request energy on the LCP is 0.861, leaving approximately 14% of request energy outside the latency-critical chain. Note that Jaccard overlap is a spancount similarity metric, whereas Figure 10 reports energy shares by class, so the two quantities are informative but not directly comparable. They differ because Jaccard gives equal weight to spans and uses only the LCP ∪ ECP set, while Figure 10 weights by attributed energy and also includes the Neither category.

Fig. 11: Top 4 services — Span-attributed vs container total energy

These findings answer RQ2 by showing that energy-aware diagnostics can diverge from latency-only critical path analysis: while most energy lies on spans that are both latency- and energy-critical, about 14% of request energy is concentrated on ECP-only spans that latency-centric methods would miss. This divergence demonstrates that request-level energy attribution yields additional diagnostic insights beyond what latencybased critical path analysis can provide. e) Dark energy debugging: We distinguish traced-span attributed energy from the unattributed remainder at microservice scope. The remainder denotes measured service energy that is not mapped to traced spans in the selected window. It can encompass background runtime activity, I/O operations, incomplete instrumentation coverage, or asynchronous work with missing or delayed causal links. During Spanergy’s development and evaluation, we observed that it can also serve as a practical diagnostic instrument for identifying anomalous energy behaviour and guiding corrective deployment changes. Figure 11 contrasts, for the four most energyconsuming services, the total container energy with the subset of energy that Spanergy attributes to traced spans. Campaignwide (30 runs), the product-catalog container consumes on average 12.2 J, whereas only 0.193 J are attributed to its spans. In earlier experiments conducted with the official repository deployment configuration, prior to stabilising the application’s runtime behaviour, the product-catalog container consumed approximately 121.8 J (Figure 12), i.e., an order of magnitude above the campaign baseline. Interestingly, only a small fraction of this elevated consumption was explained by span-attributed energy. We refer to this mismatch as the dark energy problem: container-level energy is high, yet the traced-span energy remains low, leaving a large unattributed remainder. This observation was particularly unexpected under our fixed request mix, where product-catalog is not expected to experience sustained stress comparable to the front-end service, which acts as the application entry point. Subsequent investigation revealed that product-catalog exhibited constant CPU saturation (close to 100% utilisation), which plausibly explains the excessive energy consumption. The issue was mitigated by relaxing memory constraints: increasing the container memory limit from 20 MB to 80 MB, and the Go runtime memory limit from 16 MB to 64 MB. This configuration change reduced garbage-collection pressure, alleviated CPU-bound behaviour, and restored the service to

Fig. 12: Single dark energy run top 4 services — Spanattributed vs container total energy

a stable operating regime with normalised performance and energy consumption. G. Threats to validity Internal validity is primarily threatened by temporal misalignment between power sampling, span timing, and request boundaries. The analysis mitigates this risk by integrating microservice-level power series over a consistent measurement window that excludes deployment transients (Eq. 1). Residual alignment error, sampling jitter, and rare fallback cases with a single sample can still bias short-lived spans and small microservices. Additional internal threats arise from microservice-to-process mapping and from non-deterministic background activity within containers, which can inflate energy occurring outside traced spans and affect catalogue coverage and conservation checks. Spanergy mitigates interpretation risk through explicit conservation checks with conservation ratio rus , uncovered-energy reporting with 1 − rus , and coherence checks against independent power signals. These controls expose uncertainty and support auditing. However, they do not eliminate attribution imprecision. Construct validity concerns whether our measurements and operationalisations faithfully capture the intended constructs (here, request/span energy attribution and LCP/ECP membership). Construct validity depends on trace completeness and on the correctness of request and span classification. Sampling strategies that drop spans reduce attribution coverage, and tail-based strategies may introduce bias into traces that are retained. Although crucial in production systems, this study does not apply any sampling, therefore reports coverage diagnostics and treats catalogue-based inference as conditional on sufficient coverage. Construct validity is also affected by the equal-share overlap rule used in this study. When concurrent spans have heterogeneous resource intensity, perspan allocation can shift even when service-level conservation holds. This motivates resource-weighted overlap allocation as an important future direction. This type of validity can be further affected by the power basis used for attribution. The current implementation allocates raw service-scope CPU power reported by the software power meter, without subtracting a per-service idle baseline. Consequently, span energies in active windows reflect both dynamic and baseline components,

so dynamic-only interpretations should be framed accordingly, especially under low utilisation or changing concurrency. External validity is limited by the chosen workload, deployment configuration, and hardware. The campaign uses a single deterministic Locust script, a fixed tracing configuration, and one cluster type. Overhead magnitudes and catalogue values may change under different request mixes, scaling regimes, or tracing configurations. Statistical conclusion validity further relies on run-level independence and on the stability of the experimental environment across sequential run blocks. Homogeneous nodes and clean deployments reduce confounding, but unobserved drift across time remains a plausible source of residual variance. Scalability is a key quality attribute in real-world microservice systems that may comprise thousands of services and complex interactions. Because Spanergy attributes energy only to retained spans, scalability is directly coupled to sampling policy. At large scale, sampling should be treated as a constrained estimation design that preserves endpoint representativeness while bounding telemetry ingestion and storage cost. A practical direction could be to combine adaptive tail sampling with endpoint stratification so that low-frequency highenergy traces remain observable alongside common traffic. Under this regime, each reporting window should publish coverage and conservation confidence indicators to assess result stability. In this context, the current full-tracing campaign provides a reference point for attribution overhead and coverage before sampling is introduced. The proposed methods and metrics should therefore be applied to additional settings to characterise the overhead-coverage trade-off under different sampling policies and production conditions. VI. R ELATED W ORK Distributed tracing (DT) provides request-scoped causality across services and is now a core practice in production observability [15], [29]. DT already captures request propagation through spans, timing, and links, which makes it the natural scope for energy attribution. It brings end-to-end causality to complex systems [16], [29]. Workflow-centric tracing [30] and universal context propagation [31] underpin the design of tracing tools. This section discusses related work that leverages DT baggage/context by attaching energy metadata. By correlating measured power with spans, one can perform fair-share energy attribution across overlapping work and across services. Using OpenTelemetry link propagation between causally related spans, it is possible to preserve attribution through asynchronous hops and background work [15], [18]. Reported prototype systems stream per-request estimates through sidecars and models in FLEET [32], couple trace graphs with power and network data to recover per-request totals [17] or unite distributed tracing and energy/CO2 by extending the OpenTelemetry Java agent in RETIT6 [33]. These directions are feasible and useful, and they expose clear 6 https://github.com/RETIT/opentelemetry-javaagent-extension

trade-offs between model drift and measurement overhead, and between online timeliness and post-mortem fidelity. FLEET [32] augments microservices with sidecars and ML models to estimate per-request energy and propagate it inband for policies. Request energy is transported primarily in headers rather than embedded as a first-class trace artefact with formal additivity to measured power. Our approach differs by favouring measurement-grounded attribution, via trace timestamps and power correlation with explicit handling of overlap and idle baselines. RETIT [33] attaches span attributes for CPU time (ms), memory, storage, and network bytes to every span captured by the standard OpenTelemetry Java auto-instrumentation. For entry transactions, it also publishes OpenTelemetry metrics so backends can aggregate Joules per request or endpoint. Being a Java-only tool, a practical limitation is span/thread correspondence: values are valid only if a span starts and ends on the same thread. In contrast, our approach is languageagnostic, which is common for microservice architectures. Unlike technology-dependent (JVM), model-first or sidecarcentric proposals, we ground attribution in measurements and make energy a native artefact of traces that existing backends can query, aggregate, and validate alongside latency and errors, thereby shifting analysis from an application sidecar concern to a first-class observability concern. This positions trace-level energy as both an auditable ledger for post-mortem analysis and a calibration source for lightweight online estimators that serve policies. VII. C ONCLUSION This paper presented Spanergy, an energy-aware distributed tracing approach that attributes measured energy consumption to end-user requests in microservice applications. It adopts a language-agnostic methodology to correlate per-service power measurements with OpenTelemetry traces and allocate energy across spans using a deterministic sweep-line algorithm, enabling request-level energy estimation that preserves conservation properties and accounts for both synchronous and asynchronous interactions. The post-processing adds a controlled incremental cost of only 15.2% of the S0 baseline, which corresponds to roughly 8.7% of the total S2 energy under the observed mean ratios, highlighting that Spanergy is lightweight compared to the cost of enabling tracing itself. The experimental evaluation demonstrates that Spanergy estimates per-span and per-request energy, and that it enables endpoint-centric aggregation into a request-level energy catalogue. This catalogue is actionable at the API boundary: it ranks endpoints by energy cost and enables interpretable decompositions of CPU energy consumption per microservice into demand-driven request types, supporting concrete energy bottleneck detection, optimisation, and debugging decisions. Spanergy further enables stable end-user request-level energy estimation (e.g., for the otel-demo, POST /api/checkout at 0.390 J per request) and shows that energy-aware diagnostics differ from latency-only analysis. While latency-critical path (LCP) and energy-critical path (ECP) overlap, a non-negligible

fraction of energy lies outside the LCP spans, revealing energy-dominant work that LCP would miss. Spanergy enables stakeholders to reason about energy in the same terms they use for operational and architectural decisions: requests, endpoints, traces, and journeys. Request-level energy catalogues can support diverse use cases, from enduser transparency and feature prioritisation to energy-aware service-level objectives and carbon-conscious scheduling. In this sense, the catalogue should be read as a practical showcase of usefulness for decision support in SaaS governance and operations under the studied conditions. In our experiments, endpoint energy profiles are stable across repeated runs for a fixed journey and deployment configuration. Assessing how well these profiles transfer across other user journeys and deployment contexts is a natural next step. A promising direction is to evaluate sampling policies under explicit constraints, using conservation and coverage metrics to characterise the trade-off between telemetry cost and attribution fidelity to determine when robust energy consumption conclusions can be drawn. A complementary next step is to broaden telemetry scope beyond CPU power to improve attribution coverage across diverse workloads. VIII. ACKNOWLEDGEMENTS This research was produced within the framework of Energy4Climate Interdisciplinary Center (E4C) of IP Paris. This research was supported by 3rd Programme d’Investissements d’Avenir [ANR-18-EUR-0006-02]. This work also received funding from the France 2030 programme, managed by the French National Research Agency under grant agreement No. ANR-23-PECL-0003. The authors would also like to acknowledge the contribution of Henrique de Medeiros, who provided helpful comments and expertise on software power meters. R EFERENCES [1] C. Freitag, M. Berners-Lee, K. Widdicks, B. Knowles, G. S. Blair, and A. Friday, “The Real Climate and Transformative Impact of ICT,” Patterns, vol. 2, no. 9, 2021. [2] M. Koot and F. Wijnhoven, “Usage Impact on Data Center Electricity Needs: A System Dynamic Forecasting Model,” Applied Energy, vol. 291, p. 116798, 2021. [3] A. S. Andrae, “Hypotheses for Primary Energy Use, Electricity Use and CO2 Emissions of Global Computing,” WSEAS Transactions on Power Systems, vol. 15, pp. 50–59, 2020. [4] T. Mastelic, A. Oleksiak, H. Claussen, I. Brandic, J.-M. Pierson, and A. V. Vasilakos, “Cloud Computing: Survey on Energy Efficiency,” ACM Computing Surveys, vol. 47, no. 2, pp. 1–36, 2014. [5] A.-C. Orgerie, M. D. Assuncao, and L. Lefevre, “A Survey on Techniques for Improving the Energy Efficiency of Large-scale Distributed Systems,” ACM Computing Surveys, vol. 46, no. 4, pp. 1–31, 2014. [6] M. Dayarathna, Y. Wen, and R. Fan, “Data Center Energy Consumption Modeling: A Survey,” IEEE Communications Surveys & Tutorials, vol. 18, no. 1, pp. 732–794, 2015. [7] T. Kaur and I. Chana, “Energy Efficiency Techniques in Cloud Computing: A Survey and Taxonomy,” ACM Computing Surveys, vol. 48, no. 2, pp. 1–46, 2015. [8] A. A. Khan and M. Zakarya, “Energy, Performance and Cost Efficient Cloud Datacentres: A Survey,” Computer Science Review, vol. 40, p. 100390, 2021. [9] R. Buyya, S. Ilager, and P. Arroba, “Energy-efficiency and Sustainability in New Generation Cloud Computing,” Software: Practice and Experience, vol. 54, no. 1, pp. 24–38, 2024.

[10] M. H. Hilman, M. A. Rodriguez, and R. Buyya, “Multiple Workflows Scheduling in Multi-tenant Distributed Systems: A Taxonomy and Future Directions,” in ACM Computing Surveys, 2020. [11] Z. Zhong, M. Xu, M. A. Rodriguez, C. Xu, and R. Buyya, “Machine Learning-based Orchestration of Containers: A Taxonomy and Future Directions,” ACM Computing Surveys, vol. 54, no. 10s, pp. 1–35, 2022. [12] G. Araújo, V. Barbosa, L. N. Lima, A. Sabino, C. Brito, I. Fé, P. Rego, E. Choi, D. Min, T. A. Nguyen et al., “Energy Consumption in Microservices Architectures: A Systematic Literature Review,” IEEE Access, 2024. [13] J. Soldani, D. A. Tamburri, and W.-J. Van Den Heuvel, “The Pains and Gains of Microservices: A Systematic Grey Literature Review,” Journal of Systems and Software, vol. 146, pp. 215–232, 2018. [14] S. Haselböck and R. Weinreich, “Decision Guidance Models for Microservice Monitoring,” ICSAW, pp. 54–61, 2017. [15] A. Parker, D. Spoonhower, J. Mace, and R. Isaacs, Distributed Tracing in Practice. O’Reilly, 2020. [16] T. Davidson, E. Wall, and J. Mace, “A Qualitative Interview Study of Distributed Tracing Visualisation,” IEEE Transactions on Visualization and Computer Graphics, vol. 30, no. 7, pp. 3828–3840, 2024. [17] V. Anand, Z. Xie, M. Stolet, R. De Viti, T. Davidson, R. Karimipour, S. Alzayat, and J. Mace, “The Odd One Out: Energy Is Not Like Other Metrics,” ACM SIGENERGY Energy Informatics Review, vol. 3, no. 3, pp. 71–77, 2023. [18] T. Young and A. Parker, Learning OpenTelemetry. O’Reilly Media, Inc., 2024. [19] OpenTelemetry, https://opentelemetry.io/docs/, accessed December 2025. [20] M. Chow, D. Meisner, J. Flinn, D. Peek, and T. F. Wenisch, “The Mystery Machine: End-to-end Performance Analysis of Large-scale Internet Services,” in 11th USENIX Symposium on Operating Systems Design and Implementation (OSDI), Oct. 2014, pp. 217–231. [21] Z. Zhang, M. K. Ramanathan, P. Raj, A. Parwal, T. Sherwood, and M. Chabbi, “CRISP: Critical Path Analysis of Large-Scale Microservice Architectures,” in 2022 USENIX Annual Technical Conf. (ATC), Jul. 2022, pp. 655–672. [22] J. Legler, S. Werner, M. C. Borges, and S. Tai, “Service-Level Energy Modeling and Experimentation for Cloud-Native Microservices,” in 23rd Int. Conf. on Service-Oriented Computing (ICSOC), ser. LNCS, vol. 16320. Shenzhen, China: Springer, Dec. 2025. [23] C. Wohlin, P. Runeson, M. Höst, M. C. Ohlsson, B. Regnell, and A. Wesslén, Experimentation in Software Engineering. Springer, 2012. [24] A. Arcuri and L. Briand, “A hitchhiker’s guide to statistical tests for assessing randomized algorithms in software engineering,” Software Testing, Verification and Reliability, vol. 24, no. 3, pp. 219–250, 2014. [25] B. Kitchenham, L. Madeyski, D. Budgen, J. Keung, P. Brereton, S. Charters, S. Gibbs et al., “Robust Statistical Methods for Empirical Software Engineering,” Empirical Software Engineering, vol. 22, no. 2, pp. 576– 630, 2017. [26] J. J. Dolado, M. C. Otero, and M. Harman, “Equivalence hypothesis testing in experimental software engineering,” Software Quality Journal, vol. 22, no. 2, pp. 215–238, 2014. [27] S. S. Shapiro and M. Wilk, “An Analysis of Variance Test for Normality,” Biometrika, vol. 52, no. 3-4, pp. 591––611, 1965. [28] B. L. Welch, “The generalization of ”Student’s” problem when several different population variances are involved,” Biometrika, vol. 34, no. 1-2, pp. 28––35, 1947. [29] Y. Shkuro, Mastering Distributed Tracing: Analyzing Performance in Microservices and Complex Systems. Packt Publishing, 2019. [Online]. Available: https://www.oreilly.com/library/view/ mastering-distributed-tracing/9781788628464/ [30] R. R. Sambasivan, I. Shafer, J. Mace, B. H. Sigelman, R. Fonseca, and G. R. Ganger, “Principled Workflow-centric Tracing of Distributed Systems,” in SoCC, 2016, pp. 401–414. [31] J. Mace and R. Fonseca, “Universal Context Propagation for Distributed System Instrumentation,” in EuroSys, 2018. [32] C. Meadows, “FLEET: Fine-grained, Lightweight Energy Estimate Tracing for Microservice Architectures,” Master’s thesis, The George Washington University, USA, 2023. [Online]. Available: https: //scholarspace.library.gwu.edu/concern/gw etds/5t34sk50c [33] A. Brunnert and F. Gutzy, “Extending the OpenTelemetry Java Auto-Instrumentation Agent to Publish Green Software Metrics,” in Softwaretechnik-Trends, 44(4), 2024.