Exploring the Landscape for Open Telemetry for Wasm
summary
Overview of how OpenTelemetry is actually collected for Wasm: current implementations rely on runtime/host instrumentation (wasmCloud, Spin, Fastly) or tooling that converts/rewrites modules (VM toolkit, Loft Labs) and an observe SDK that auto- or manually-instruments modules and exports to OTLP (examples use an OTEL stdout adapter, Datadog, Zipkin). Guest functions cannot natively emit metrics yet so traces come from host calls and rewrites; a wasi logging API exists now and wasi observe is a Phase One proposal to enable guest-side auto-instrumentation.
AI-written summary · about
chapters (10)
- 0:00OpenTelemetry and WebAssembly intro
- 2:27Observability with WebAssembly
- 9:10OpenTelemetry in WebAssembly
- 11:16Using OpenTelemetry with WebAssembly-powered applications
- 14:27Implementing OpenTelemetry for Wasm
- 17:25WASI logging and Observe SDK
- 21:44Wasm Toolkit observability tools
- 23:29OpenTelemetry in WasmCloud and Spin
- 25:36Future of WASI Observe
- 27:43Conclusion and Q&A
related talks
27mObserving the Future: Embracing OTEL in WebAssembly
25mObservability at the Edge: Instrumenting WebAssembly with OpenTelemetry
28mUnlocking Observability in WebAssembly with OpenTelemetry
29mOTel Me About It: Latest Updates in WASI OTel
36mObservability For You and Me with OpenTelemetry
22mBridging the OpenTelemetry Adoption Gap in Cloud-Native Applications
20mObservability and Open Telemetry
23mObservability Without Borders: The OpenTelemetry Collector in a WebA...