WasmLens: Automatic Glass-Box Instrumentation for Composed WebAssembly Applications

WasmLens: Automatic Glass-Box Instrumentation for Composed WebAssembly Applications Michiel Van Kenhove✉

IDLab, Ghent University - imec Ghent, Belgium michiel.vankenhove@ugent.be

Ewout Verlinde José Santos

IDLab, Ghent University - imec Ghent, Belgium

arXiv:2611.12710v1 [cs.SE] 9 Nov 2026

Abstract The WebAssembly Component Model enables language-independent composition of independently developed components, but complicates observability. Existing tracing support flattens execution hierarchy by attributing every span created inside a composition to a single host-level parent context, so execution across component boundaries cannot be reconstructed. The problem is amplified because components are typically deployed as black boxes whose internals cannot be modified or inspected by the system integrator. To address these limitations, we propose a revised wasi:otel/tracing design in which the runtime maintains a per-component span stack, restoring parent-child relationships across component boundaries without changing component interfaces or source code. This change has since been adopted upstream. Building on this design, we present WasmLens, an automatic instrumentation tool that derives instrumentation points from a composition graph and injects tracing middleware into already composed binaries, yielding end-to-end traces for black-box compositions with no developer configuration. This automatic instrumentation raises mean request latency from 238 µs to 454 µs across six component boundaries. Raising the expected number of boundary crossings from 6 to 11 further increases latency to 514 µs, an incremental cost of 12 µs per crossing, of which 10.4 µs is attributable to instrumentation. These results show that instrumentation overhead is additive in composition depth rather than proportional to baseline execution time.

CCS Concepts • Software and its engineering → Runtime environments; Software performance; Software testing and debugging; • Computer systems organization → Cloud computing.

Keywords WebAssembly, Component Model, distributed tracing, OpenTelemetry, observability, auto-instrumentation, binary rewriting ACM Reference Format: Michiel Van Kenhove, Ewout Verlinde, José Santos, Filip De Turck, Bruno Volckaert, and Merlijn Sebrechts. 2026. WasmLens: Automatic Glass-Box Instrumentation for Composed WebAssembly Applications. In WebAssembly, Cloud and Edge: Shaping the Future of Computing (WACE ’26), December

This work is licensed under a Creative Commons Attribution 4.0 International License. WACE ’26, Tarragona, Spain © 2026 Copyright held by the owner/author(s). ACM ISBN 979-8-4007-3109-9/2026/12 https://doi.org/10.1145/3861044.3862585

Filip De Turck Bruno Volckaert Merlijn Sebrechts

IDLab, Ghent University - imec Ghent, Belgium

14–18, 2026, Tarragona, Spain. ACM, New York, NY, USA, 6 pages. https: //doi.org/10.1145/3861044.3862585

1

Introduction

Modern cloud-native applications increasingly rely on observable telemetry to reason about behavior across many independently developed and deployed components. The WebAssembly (Wasm) Component Model extends Wasm beyond the browser, enabling portable, sandboxed components to be composed through standardized interfaces [4]. This structured composition shares key principles with microservice architectures, particularly explicit interfaces, component autonomy, and independent evolution [10], while providing lightweight isolation, portability, and compact deployment. Distributed tracing through OpenTelemetry (OTel) [13] is the established means of reconstructing causal execution paths in such distributed architectures. The Component Model breaks assumptions that distributed tracing relies on. Execution is not tied to long-running service instances: a composition may be assembled statically at build time and executed entirely within a single runtime, so architecturally significant boundaries leave no trace at the process, socket, or system-call level, placing them out of reach of zero-code approaches that observe at the kernel [1, 14] or language-runtime [15] boundary. Many components are also distributed as binary-only artifacts, ruling out code-level instrumentation by the integrator. Finally, the propagation mechanism currently standardized for Wasm captures only the host context present at invocation time, flattening nested spans into siblings of a single root, with more structure lost the deeper the composition. This paper makes three contributions. We show that wasi:otel/tracing cannot preserve trace hierarchy in statically composed applications, and that the obvious workaround of passing span context through WIT interfaces is unacceptable in a black-box setting (Section 2). We propose a revised interface in which the runtime maintains a per-component span stack, replacing the static outer-spancontext accessor with a dynamic current-span-context query. We implement it in wasmCloud’s [29] runtime, and our proposed interface change has since been adopted upstream [25] in the wasi:otel specification (Section 3). We then present WasmLens, an open-source tool [23], which derives instrumentation points from a composition graph and injects OTel tracing into an already composed binary without source code access or manual configuration (Section 4). We then show that its overhead grows linearly with the number of boundaries a request crosses (Section 5). Finally, Section 6 positions our approach against existing zero-code instrumentation, and Section 7 concludes the paper.

WACE ’26, December 14–18, 2026, Tarragona, Spain

Van Kenhove et al.

Component 2

Pricing

do:something

(3) Inter-Guest Boundary

do:something

3 wasi:http

Component 1 wasi:keyvalue

(2) Intra-Guest Boundary

wasi:http

Identity

2

Matcher

6

Payment

5

Driver

Gateway

(1) Host-Guest Boundary wasi:keyvalue

4

wasi:http

1

Host Runtime

Host Runtime

Figure 1: The host-guest (1), intra-guest (2), and inter-guest (3) context boundaries in a composed WebAssembly application.

2 Background and Motivation 2.1 Composing WebAssembly Components The Component Model raises the abstraction level at which Wasm binaries interact, using the WebAssembly Interface Types (WIT) language to define safe, language-agnostic interfaces. Components can be linked statically at build time with tools such as wac [2], producing a single composed component. This linking process automatically generates lightweight intermediary shim components that reconcile interface mismatches. Context propagation must account for three execution boundaries, shown in Figure 1: the host-guest boundary (1) between a guest and host-provided capabilities such as WASI interfaces; the intra-guest boundary (2) between internal transitions within a single component; and the inter-guest boundary (3) between composed components. Inter-guest boundaries are either static, resolved at composition time via shims, or dynamic, mediated by the runtime. Static inter-guest boundaries are the hard case because at runtime they are indistinguishable from ordinary intra-guest execution. A composed ride-hailing application, shown in Figure 2, serves as a running example throughout the paper and as the evaluated workload in Section 5. Six components are statically composed with wac: a gateway exposing wasi:http/incoming-handler and calling, in turn, an identity component that validates a bearer token, a pricing component that computes a fare, a matcher that selects candidate drivers, and a payment component that returns a payment URL. The matcher invokes a driver component in a retry loop, repeating until a candidate accepts. Every other interaction occurs exactly once per request. Composition is nested, with driver linked into matcher first and the result composed with the remaining components. Only wasi:http/incoming-handler is exported at the top level, so the runtime sees the whole application as one opaque guest instance. We deploy locally with wash [28], which embeds a Wasmtime [3] based host runtime.

Figure 2: The statically composed ride-hailing application, with six components linked by wac into a single guest component. A request crosses the host-guest boundary (1), then the inter-guest boundaries to identity (2), pricing (3), matcher (4), driver (5), and payment (6).

2.2

Tracing Across Composed Boundaries

OTel represents execution as traces of spans connected by parentchild relationships, maintained through context propagation [12]. The wasi:otel/tracing interface [19, 26] standardizes emission of OTel traces from Wasm guests. It provides functions for creating and completing spans, and, in version 0.2.0-rc.1, for accessing the active parent host span context via outer-span-context at component entry. This design assumes that a host-provided span context is available at invocation time and can be used as the parent context for subsequently created spans. In a static composition the runtime treats the entire composite as one guest instance, so outer-span-context returns the span context active on the host side at that moment. That context is neither derived from nor affected by spans emitted inside the composition during execution. Using it as the parent of every new span produces a flat hierarchy in which all component spans attach directly to the host’s entry span: when the gateway calls the matcher, the matcher’s span does not nest beneath the gateway’s, and both become siblings of the root. The structure needed to reconstruct execution order is absent, and causal reasoning across components becomes unreliable. The same gap appears without any boundary crossing, since the interface exposes no runtime-managed notion of an active span: nested spans created inside a single component cannot resolve their parent either. The direct workaround is to propagate context explicitly through WIT, extending every function signature with a span-context parameter. However, this is unattractive for three reasons. It violates separation of concerns, since business-logic interfaces become dependent on the telemetry stack. It also propagates, in the sense that every caller along every path must pass a context object through. And it forces recompilation of components with no observability

WasmLens: Automatic Glass-Box Instrumentation for Composed WebAssembly Applications

requirement of their own, which, in a composition assembled from third-party binaries, is exactly the set the integrator cannot rebuild.

2.3

Observing Black-Box Components

Components are often independently developed, versioned, and distributed as binary artifacts, integrated purely through interface definitions. The Component Model deliberately reinforces this, since composition is established by interface compatibility rather than access to implementation details. Without explicit instrumentation, execution inside a component is therefore not observable from outside. Such components become dark nodes in an otherwise well-structured composition graph, and trace continuity breaks at every non-participating component. Instrumenting every component manually is not a general solution. Integrators often lack source access to the components they compose. Embedding tracing logic entangles operational infrastructure with business functionality, expanding the WIT interfaces a component imports or exports with propagation primitives. Instrumentation effort also competes with feature work, so coverage remains incomplete even where standardized APIs exist [1, 18]. Together with the trace flattening issue above, these constraints motivate a shift from manually instrumented black-box compositions to automatically instrumented glass-box compositions, in which tracing is introduced after composition but before deployment.

3

Ambient Context Propagation

Restoring trace hierarchy without polluting interfaces requires three things. Each component must resolve its immediate caller as parent, rather than the host root span. No context object may appear in a business-logic WIT signature. And a guest must be able to query the active span at any point during execution, as native OTel SDKs allow. We therefore replace the static outer-span-context accessor with a dynamic current-span-context query backed by host-managed ambient state. The host maintains a logical span stack per component instance: it pushes the incoming context on on-start, returns the top of the stack on current-span-context, and removes the corresponding entry on on-end. If a gateway component starts a span and then calls a service component, the callee’s current-span-context then returns the gateway’s active span. When the stack is empty, the host falls back to its own ambient context, reproducing the previous behavior and preserving continuity with the incoming request. Following design discussion [24] with the wasi:otel maintainers, the static accessor was found redundant once ambient state exists, and the replacement has been adopted upstream [25]. We implement the design in the host runtime that wasmCloud’s wash embeds. Host-side implementations of WIT interfaces are shared across all components consuming them, so per-component state must be isolated explicitly. We therefore extend the runtime’s ComponentContext with a span stack keyed per component invocation rather than per component, which avoids shared mutable state between concurrent invocations. Stack discipline is sound because component invocations execute synchronously, so on-start and onend events are strictly ordered within one execution path. Under the optional threading proposal the stack would need to be initialized

WACE ’26, December 14–18, 2026, Tarragona, Spain

per thread. For dynamically linked components, whose boundaries the runtime mediates across process or network boundaries, the host instead encodes the active context into transport metadata before dispatch and reinitializes the local span stack on receipt, a form of propagation wasmCloud and Spin already implement [21, 27]. Running the example of Section 2.1 on the modified runtime yields the expected hierarchy. The gateway span becomes the parent of the identity, pricing, matcher, and payment spans, and matcher the parent of driver, instead of the six sibling spans the original interface produces. This result is obtained without modifying any WIT interface or application call signature.

4

WasmLens

Correct propagation makes hierarchical traces possible, but it does not make them automatic. WasmLens [23] provides this automation by injecting tracing at the component boundaries of an already composed binary, using Splicer [7, 8] as its transformation layer.

4.1

Composition Rewriting

Splicer rewrites Wasm component graphs through declarative injection rules. Given a target composition, a middleware binary, and a rule set, it decomposes the component graph, inserts adapter components at selected interface edges, and recomposes a valid Wasm binary. WasmLens targets Splicer’s Tier 1 contract, which exposes minimal invocation metadata, notably a call-id, without access to function arguments or payloads. A call-id is enough to correlate the entry and exit of the same invocation. The adapter preserves the original WIT signature while routing execution through Tier 1 hooks, so the same tracing middleware remains reusable across arbitrary interfaces. The cost is indirection. An uninstrumented boundary is represented by a single generated shim, whereas an instrumented one becomes three shimmed edges: component to adapter, adapter to middleware, and adapter to downstream component.

4.2

Automatic Boundary Detection

Splicer alone requires developers to enumerate the boundaries to instrument. That is reasonable for targeted middleware but defeats the purpose of auto-instrumentation: it presumes detailed knowledge of the composition graph, including the internal structure of third-party components that should remain opaque, and must be maintained as the composition evolves. WasmLens instead derives candidate boundaries from the composition structure itself, using the graph representation produced by cviz [6]. We classify instrumentation points into two categories: top-level exports of the root component, which represent system entry points such as HTTP handlers; and internal import relationships between components or between a component and the host. Both correspond to control-flow transitions and are therefore natural span boundaries. Traversing exported interfaces and component imports produces a complete candidate set, which WasmLens emits as Splicer injection rules. By default every such edge is instrumented, so coverage extends through nested compositions without any hand-written rule.

WACE ’26, December 14–18, 2026, Tarragona, Spain

4.3

Tracing Middleware

The middleware constructs OTel spans around each intercepted invocation through two Tier 1 hooks. On entry the middleware retrieves the parent span via current-span-context and builds a new child span that inherits its trace identifier and trace state, recording a start timestamp and a name derived from the interface and function being called. Because the Tier 1 hooks are stateless, this span is held in an in-flight map keyed by call-id. On return, the matching entry is retrieved and a complete SpanData is exported via on-end. Applying WasmLens to the example binary of Section 2.1 yields a trace structurally equivalent to the manually instrumented variant: each detected boundary appears as a span named by its fully qualified interface and function identifier, hierarchy is preserved through current-span-context, and host and guest execution remain distinguishable through reported service names. WasmLens therefore achieves semantic parity with manual instrumentation while eliminating boundary configuration entirely.

5

Table 1: Latency and throughput at concurrency 𝑐 = 1 against composition depth, where E[𝐵] = 5+𝑛 is the expected number of boundary crossings per request. Latency is the mean perrequest latency over a ten-second run. Throughput is given in requests per second (RPS). Three of the six measured values of 𝑛 are shown. Variant

Evaluation Results

All experiments run on a Lenovo LOQ 15IRX10 with an Intel Core i7-13700HX and 24 GB RAM running Arch Linux, using wasmCloud wash-runtime v2.1.0 extended with the interface of Section 3 and a local OTel collector. Load is generated with wrk [9], ten seconds per run, with the load generator pinned to a disjoint CPU range so that the measured overhead reflects instrumentation rather than client-server contention. We compare three variants of the application of Section 2.1: uninstrumented, manually instrumented, and automatically instrumented with WasmLens.

5.1

Van Kenhove et al.

Per-Boundary Overhead

With the six boundary crossings of Figure 2, the uninstrumented baseline has a mean latency of 238 µs, manual instrumentation 300 µs, and WasmLens 454 µs. Dividing the added latency by the six boundaries gives a first estimate of the per-boundary cost: ≈ 10 µs for manual instrumentation and ≈ 36 µs for automatic instrumentation. Expressed as a ratio, automatic instrumentation adds 91% to the baseline execution time. That framing is potentially misleading though: the uninstrumented baseline is intentionally lightweight, so any fixed overhead looks large relative to it. To test whether the overhead is indeed fixed per boundary, we vary the number of boundary crossings without changing the actual work performed. The matcher component queries one driver at a time and retries on rejection. The probability that a driver accepts is 𝑝 = 1/𝑛. Increasing 𝑛 therefore increases matcher-to-driver calls and thus adds inter-component boundary crossings without altering the remaining execution path. Let 𝑋 ∼ Geom(𝑝) denote the number of driver attempts, then E[𝑋 ] = 1/𝑝 = 𝑛. With five fixed boundary crossings outside the retry loop, the expected number of boundary crossings per request is E[𝐵] = 5 + 𝑛. Table 1 reports the results. Latency grows linearly with 𝑛 in all three variants. Each additional matcher-to-driver crossing costs 1.6 µs uninstrumented, 6.7 µs with manual instrumentation, and 12.0 µs with WasmLens (𝑅 2 = 0.77, 0.93, and 0.99 respectively). Even without tracing, a crossing is not free. The 1.6 µs slope is the cost of the shims the Component Model inserts between components. Subtracting it leaves the cost of tracing alone: about 5.1 µs

𝑛

E[𝐵]

Latency (µs)

RPS

Uninstrumented

1 3 6

6 8 11

238 242 245

4146 4059 4030

Manual

1 3 6

6 8 11

300 308 331

3272 3192 2941

Auto (WasmLens)

1 3 6

6 8 11

454 479 514

2141 2031 1896

per boundary for manual instrumentation and 10.4 µs for WasmLens. Both variants make the same three wasi:otel host calls per boundary. The extra cost aligns with Splicer’s adapter-based transformation, which adds indirection layers at every instrumented boundary (Section 4). These numbers are lower than the 10 and 36 µs estimated from the baseline, because not every boundary costs the same. A boundary’s cost depends on how much metadata its host calls carry, and for WasmLens on how many shims it expands into. The matcherto-driver call carries a small payload, so it sits at the cheap end. What both measurements agree on is that instrumentation adds a cost per boundary crossed, and that this cost does not grow as compositions get deeper.

5.2

Overhead Under Load

The measurements up until now send one request at a time. We now check whether instrumentation costs proportionally more as concurrent load increases. To do so, we vary the client-side concurrency 𝑐 ∈ {1, 2, 4, 8, 16, 32}. Throughout these runs, we keep 𝑝 fixed at 1, so that the first driver always accepts and no matcherto-driver retries occur. Every request therefore follows the same deterministic path with exactly 𝐵 = 6 boundary crossings. Figure 3 shows that the uninstrumented baseline maintains the highest throughput, with the manually and automatically instrumented variants progressively lower, reflecting their additional per-request overhead compared to baseline. Despite these absolute differences, all three behave the same way as load increases. Throughput grows with concurrency up to 𝑐 ≈ 16, beyond which additional concurrency no longer increases throughput and the latency rises instead. At 𝑐 = 32 the three variants sustain 21,909, 19,276, and 13,081 requests per second. Instrumentation therefore costs a roughly constant fraction of throughput at every concurrency level rather than a growing one. WasmLens sustains between 51% and 60% of the baseline throughput across the range, and manual instrumentation between 79% and 88%, with no downward trend as load increases. All three variants

WasmLens: Automatic Glass-Box Instrumentation for Composed WebAssembly Applications

Requests/sec

20,000 15,000 10,000 5,000 0 1

2

Uninstrumented

4

8

Concurrency level Manual

16

32

Auto (WasmLens)

Figure 3: Throughput as client concurrency 𝑐 increases, with 𝑝 = 1 so that every request makes 𝐵 = 6 boundary crossings.

also saturate at the same concurrency level, so instrumentation is not what limits throughput under load.

5.3

Binary Size

Instrumentation has little effect on the binary size. The composed binary grows from 2372 KiB uninstrumented to 2420 KiB with manual instrumentation (+2.0%) and 2400 KiB with WasmLens (+1.2%). The difference between the two approaches is negligible, though it is consistent with WasmLens including the tracing logic once as shared middleware rather than linking it into each component separately.

6

Related Work

Zero-code instrumentation removes the need for developers to insert spans and propagate context by hand. Two general-purpose families dominate, differing in their observation boundary, which determines what survives in a WebAssembly composition. We then discuss the only Wasm-specific approach we are aware of. Language-level instrumentation. OTel provides automatic instrumentation for multiple programming languages and frameworks, such as Go, Java, Python, JavaScript, PHP, and .NET by hooking method invocations, framework lifecycle events, and library calls within the application’s language runtime [15]. This approach yields rich semantic detail, but the enabling mechanisms, including monkey patching, bytecode rewriting, and runtime agents, depend on features of specific language runtimes and are unavailable in Wasm. Compiling existing OTel SDKs to Wasm is itself obstructed by system-interface assumptions and platform-specific hooks [19]. Kernel-level instrumentation. eBPF provides an event-driven mechanism for attaching programs to kernel hooks, enabling system tracing and network observability without modifying the monitored applications [5, 17]. OTel eBPF Instrumentation [14] captures protocol-level interactions such as HTTP and gRPC, while MiSeRTrace [22] associates kernel events with individual requests, and

WACE ’26, December 14–18, 2026, Tarragona, Spain

TraceWeaver [1] reconstructs request paths from externally collected span timings and call-graph information. Building on timingbased reconstruction, CrossTrace [16] correlates timestamped ingress and egress spans within a service without relying on OSthread affinity, an assumption that can fail when requests migrate between threads or when a thread handles multiple logical requests concurrently [1, 20]. Across services, CrossTrace propagates span identifiers through TCP header options. None of this transfers to composed Wasm. A Wasm runtime mediates all system interaction, so many component-level operations are multiplexed onto one runtime thread and surface to the kernel as a single syscall sequence. Statically composed boundaries are resolved at build time and crossed by in-process calls that generate no socket or syscall activity at all, removing the very signal these systems correlate on. A single runtime instance may also execute unrelated components concurrently, interleaving their events into one kernel-observable stream with no identifier to attribute them. Wasm-specific tracing. WasmTracer [11] moves the observation boundary closer to the guest by observing WASI-mediated system calls through eBPF and constructing OTel spans in a user-space agent. Because spans are derived from monitored syscall activity, execution that does not result in such interactions is not directly captured by the approach. Unlike instrumentation inside the guest, the observation boundary remains outside the Wasm module. Although the paper outlines an implementation based on eBPF tracing and OTel integration, it reports that implementation and evaluation were still ongoing at the time of publication. Existing systems optimize either for low-level system breadth or for application-level semantic depth, but not both in a Wasm setting. WasmLens shifts the observation boundary to the composition graph itself, so inter-component interactions are observed directly rather than inferred from kernel- or WASI-level events. It takes one property from each family. Like language-level instrumentation it records the interfaces and functions being called, rather than reconstructing structure from lower-level events. Like kernel-level instrumentation it needs no cooperation from the code it observes and works regardless of the language a component was written in, since instrumentation attaches to the compiled interface boundary that the Component Model defines independently of any source language.

7

Conclusion

Composed WebAssembly applications lose their trace hierarchy at statically composed boundaries, and the components themselves often cannot be instrumented by the integrator who composes them. We addressed the first with a revised wasi:otel/tracing design in which the runtime maintains a per-component span stack, restoring parent and child relationships without requiring changes to any component interface. This change has been adopted upstream. We addressed the second with WasmLens, which derives instrumentation points from a composition graph and injects tracing middleware into already composed binaries, producing traces equivalent to manual instrumentation without configuration or access to their source code. Instrumentation adds a fixed cost per boundary crossing rather than a cost proportional to the time a request takes. Whether that

WACE ’26, December 14–18, 2026, Tarragona, Spain

cost matters depends on how much work the components themselves do. For example, when a request spends milliseconds in application logic or waiting on host calls, tens of microseconds per boundary can be considered negligible. On the other hand, when a request performs little actual computation and primarily crosses boundaries, as in our benchmark, the overhead becomes visible. That overhead is offset by the ability to trace components that would otherwise remain unobservable, since WasmLens can instrument them without source code changes or manual context propagation. The two approaches can also be combined, with an integrator instrumenting the components they control by hand and employing WasmLens for the other, possibly third-party, components. Several directions remain open as future work. Our evaluation covers one application on one machine, so measurements across more compositions would further validate the per-boundary figures we report. Additionally, WasmLens targets Splicer’s Tier 1 middleware, which exposes only interface name, function name, and call identifier. Tier 2 middleware grants read-only access to function parameters, which would allow richer span attributes derived from runtime arguments, but introduces challenges related to Application Binary Interface (ABI) diversity, schema uncertainty, and the safe handling of potentially sensitive data. That extension therefore requires both robust parameter extraction and appropriate redaction strategies. A second direction is configurability. WasmLens currently instruments every detected boundary, and letting users selectively include or exclude interfaces would reduce telemetry noise in large compositions.

Acknowledgments The authors thank Elizabeth Gilbert (Carnegie Mellon University) for valuable discussions on WebAssembly component interposition and for their work on Splicer, which directly influenced WasmLens. This work received funding from the Smart Networks and Services Joint Undertaking (SNS JU) under the Horizon Europe research and innovation program of the European Union under Grant Agreement number 101139067 (https://doi.org/10.3030/101139067) (https://elasticproject.eu/). Expressed views and opinions are however those of the authors only and do not necessarily reflect those of the European Union. Neither the European Union nor the granting authority can be held responsible for them. José Santos is funded by the Research Foundation Flanders (FWO), grant number 1253226N.

References [1] Sachin Ashok, Vipul Harsh, Brighten Godfrey, Radhika Mittal, Srinivasan Parthasarathy, and Larisa Shwartz. 2024. TraceWeaver: Distributed Request Tracing for Microservices Without Application Modification. In Proceedings of the ACM SIGCOMM 2024 Conference (ACM SIGCOMM ’24). Association for Computing Machinery, New York, NY, USA, 828–842. doi:10.1145/3651890.3672254 [2] Bytecode Alliance. 2026. Bytecodealliance/Wac. Bytecode Alliance. Retrieved 2026-09-17 from https://github.com/bytecodealliance/wac [3] Bytecode Alliance. 2026. Bytecodealliance/Wasmtime. Bytecode Alliance. Retrieved 2026-09-17 from https://github.com/bytecodealliance/wasmtime [4] Bytecode Alliance. 2026. Introduction: The WebAssembly Component Model. Retrieved 2026-05-09 from https://component-model.bytecodealliance.org/ [5] Milo Craun, Khizar Hussain, Uddhav Gautam, Zhengjie Ji, Tanuj Rao, and Dan Williams. 2024. Eliminating eBPF Tracing Overhead on Untraced Processes. In Proceedings of the ACM SIGCOMM 2024 Workshop on eBPF and Kernel Extensions (eBPF ’24). Association for Computing Machinery, New York, NY, USA, 16–22. doi:10.1145/3672197.3673431

Van Kenhove et al.

[6] cviz Authors. 2026. Cosmonic-Labs/Cviz. Cosmonic Labs. Retrieved 2026-09-17 from https://github.com/cosmonic-labs/cviz [7] Elizabeth Gilbert. 2026. Ejrgilbert/Splicer. Retrieved 2026-09-17 from https: //github.com/ejrgilbert/splicer [8] Elizabeth Gilbert, Chris Fallin, Heather Miller, and Ben L. Titzer. 2026. Write Once, Instrument Anywhere: Portable, Sandboxed Tooling with WebAssembly Components. arXiv:2610.38682 [cs.SE] doi:10.48550/arXiv.2610.38682 [9] Will Glozer. 2026. Wg/Wrk. Retrieved 2026-09-18 from https://github.com/wg/ wrk [10] Pooyan Jamshidi, Claus Pahl, Nabor C. Mendonça, James Lewis, and Stefan Tilkov. 2018. Microservices: The Journey So Far and Challenges Ahead. IEEE Software 35, 3 (May 2018), 24–35. doi:10.1109/MS.2018.2141039 [11] Anri Nakamura and Naohiro Hayashibara. 2025. Wasm Tracer: Improving Observability Using eBPF for Wasm Applications. In 2025 IEEE Conference on Dependable, Autonomic and Secure Computing (DASC). IEEE, USA, 149–150. doi:10.1109/DASC68382.2025.00030 [12] OpenTelemetry Authors. 2026. Context Propagation. Retrieved 2026-09-17 from https://opentelemetry.io/docs/concepts/context-propagation/ [13] OpenTelemetry Authors. 2026. OpenTelemetry. Retrieved 2026-09-17 from https://opentelemetry.io/ [14] OpenTelemetry Authors. 2026. OpenTelemetry eBPF Instrumentation. Retrieved 2026-09-17 from https://opentelemetry.io/docs/zero-code/obi/ [15] OpenTelemetry Authors. 2026. Zero-Code Instrumentation. Retrieved 2026-09-17 from https://opentelemetry.io/docs/zero-code/ [16] Linh-An Phan, MingXue Wang, Guangyu Wu, Wang Dawei, Chen Liqun, and Li Jin. 2025. CrossTrace: Efficient Cross-Thread and Cross-Service Span Correlation in Distributed Tracing for Microservices. arXiv:2508.11342 [cs.NI] doi:10.48550/ arXiv.2508.11342 [17] Mohammadreza Rezvani, Ali Jahanshahi, and Daniel Wong. 2024. Characterizing In-Kernel Observability of Latency-Sensitive Request-Level Metrics with eBPF. In 2024 IEEE International Symposium on Performance Analysis of Systems and Software (ISPASS). IEEE, USA, 24–35. doi:10.1109/ISPASS61541.2024.00013 [18] Matheus Santana, Adalberto Sampaio, Marcos Andrade, and Nelson S. Rosa. 2019. Transparent Tracing of Microservice-Based Applications. In Proceedings of the 34th ACM/SIGAPP Symposium on Applied Computing (SAC ’19). Association for Computing Machinery, New York, NY, USA, 1252–1259. doi:10.1145/3297280. 3297403 [19] Caleb Schoepp. 2025. Unlocking Otel in WebAssembly - Wasm I/O 2025. Retrieved 2026-09-17 from https://dev.to/fermyon/unlocking-otel-in-webassembly-wasmio-2025-1m8n [20] Junxian Shen, Han Zhang, Yang Xiang, Xingang Shi, Xinrui Li, Yunxi Shen, Zijian Zhang, Yongxiang Wu, Xia Yin, Jilong Wang, Mingwei Xu, Yahui Li, Jiping Yin, Jianchang Song, Zhuofeng Li, and Runjie Nie. 2023. Network-Centric Distributed Tracing with DeepFlow: Troubleshooting Your Microservices in Zero Code. In Proceedings of the ACM SIGCOMM 2023 Conference (ACM SIGCOMM ’23). Association for Computing Machinery, New York, NY, USA, 420–437. doi:10.1145/3603269.3604823 [21] Spin Authors. 2023. Observing Applications. Retrieved 2026-09-17 from https: //spinframework.dev/v3/observing-apps [22] Thrivikraman V, Vishnu R. Dixit, Nikhil Ram S, Vikas K. Gowda, Santhosh Kumar Vasudevan, and Subramaniam Kalambur. 2022. MiSeRTrace: Kernel-Level Request Tracing for Microservice Visibility. In Companion of the 2022 ACM/SPEC International Conference on Performance Engineering (ICPE ’22). Association for Computing Machinery, New York, NY, USA, 77–80. doi:10.1145/3491204.3527462 [23] Ewout Verlinde. 2026. Idlab-Discover/WasmLens. IDLab DISCOVER. Retrieved 2026-09-17 from https://github.com/idlab-discover/WasmLens [24] Ewout Verlinde. 2026. Limitation of ‘wasi:Otel/Tracing’ for Statically Composed Components - Issue #15 - WebAssembly/Wasi-Otel. Retrieved 2026-10-01 from https://github.com/WebAssembly/wasi-otel/issues/15 [25] Ewout Verlinde. 2026. Replace outer-Span-Context with current-Span-Context by EwoutV - Pull Request #16 - WebAssembly/Wasi-Otel. Retrieved 2026-09-17 from https://github.com/WebAssembly/wasi-otel/pull/16 [26] wasi-otel Authors. 2026. WebAssembly/Wasi-Otel. WebAssembly. Retrieved 2026-09-30 from https://github.com/WebAssembly/wasi-otel [27] wasmCloud Authors. 2026. Observability with OpenTelemetry - wasmCloud. Retrieved 2026-09-17 from https://wasmcloud.com/docs/v1/deployment/ observability/observability-with-opentelemetry/ [28] wasmCloud Authors. 2026. Wash - Wasm Shell CLI for wasmCloud - wasmCloud. Retrieved 2026-09-17 from https://wasmcloud.com/docs/wash/ [29] wasmCloud Authors. 2026. The WebAssembly Application Platform - wasmCloud. Retrieved 2026-09-17 from https://wasmcloud.com/

Related documents

• vTen: Tensor-Centric Verification Framework for Domain-Specific Accelerators#1218107
• vTen: Tensor-Centric Verification Framework for Domain-Specific Accelerators#1210257
• When Requirements Interact: Scaling Long-Horizon Coding via Interdependent Specifications#1491864
• When Requirements Interact: Scaling Long-Horizon Coding via Interdependent Specifications#1483061
• Trace-to-Architecture: Capability Bottleneck Diagnosis for Harness Revision#1341611