Exploring the Landscape for Open Telemetry for Wasm

### Overview In this talk presented at WasmCon, Saiyam Pathak (Principal Developer Advocate at Loft Labs) and Shivay Lamba (Developer Relations Engineer at Couchbase) explore the current observability landscape for WebAssembly (Wasm) and its integration with OpenTelemetry (OTel). As enterprises adopt WebAssembly to run workloads across browsers, edge nodes, and cloud servers, understanding runtime behavior and troubleshooting performance becomes essential. The presentation covers fundamental observability concepts, details why Wasm’s sandboxing poses unique monitoring challenges, and analyzes the solutions and runtimes currently bridging OTel and Wasm.

### Key Topics - **Observability Fundamentals**: The role of metrics, logs, traces, and profiling in diagnosing system health, API flow bottlenecks, and errors in cloud-native platforms. - **Challenges with Wasm Observability**: Why the platform-independent, sandboxed nature of WebAssembly complicates monitoring, particularly regarding host isolation, continuous system clock access for timestamps, and lack of host visibility. - **Observability for Wasm-Powered Applications**: Utilizing existing language-level SDKs (such as .NET OpenTelemetry SDK in Blazor frontends/backends or the Fastly JS npm integration for Fastly Compute edge functions) to generate spans and logs. - **Wasm Runtime and Module-Level Instrumentation**: Mechanisms like WASI logging, Dylibso's Observe SDK, Loophole Labs' Wasm Toolkit, WasmCloud OTel integration, and Fermyon Spin plugins. - **Standardization Efforts**: The Phase 1 WASI proposal (`wasi-observe`) designed to standardize guest-level automatic instrumentation.

### Technical Details Monitoring traditional applications typically relies on sidecars or host-level agents (like DaemonSets in Kubernetes). However, WebAssembly guest modules operate in a sandbox isolated from the underlying host system, lacking native access to system clocks and inter-process communication (IPC) channels without explicitly granted capabilities. Consequently, guest functions cannot directly emit standard telemetry to host collectors on their own.

The speakers outline several current strategies to overcome this gap: - **Host Runtime Instrumentation**: Runtimes take on the responsibility of observing guest activity. For instance, WasmEdge includes native support for `wasi-logging` (exposing log levels such as Trace, Debug, Info, Warn, Error, and Critical to `stderr`). In WasmCloud, the host runtime captures traces and metrics via push-based protocols directly to an OTel collector. Similarly, Fermyon Spin (and SpinKube in Kubernetes) offers dedicated OTel plugins to capture host execution spans without requiring deep code modifications. - **Observe SDK (Dylibso)**: An open-source, multi-language SDK that instruments guest function calls and memory allocations. It connects via adapters (e.g., OTel `stdout`, Zipkin, Datadog) to export traces and span IDs out of runtimes like Wazero. Dylibso supports both manual instrumentation and auto-instrumentation via API keys. - **Wasm Toolkit (Loophole Labs)**: A runtime-agnostic approach that converts Wasm modules into text representation, injects DWARF debugging functions and labels, and recompiles back to Wasm to trace guest function calls and key-value lookups. - **Downstream Collectors**: Once telemetry is exported to an OTel Collector, backend platforms such as SigNoz can ingest the telemetry data into databases like ClickHouse for visualization.

### Takeaways While observability in WebAssembly has historically been difficult due to guest isolation, practical solutions exist today through runtime plugins (Spin, WasmCloud) and adapter libraries (Observe SDK). The runtime currently bears most of the responsibility for capturing telemetry. Ongoing standardization efforts—specifically the `wasi-observe` proposal led by Caleb at Fermyon—aim to bring native, automated guest-level instrumentation to the broader WebAssembly ecosystem in the near future.