OTel meets Wasm: Rethinking OpenTelemetry Collector Extensibility

This talk was presented at KubeCon + CloudNativeCon Japan 2026 with Tsuzuki Tsuchiya (Tsuzu).

---

OpenTelemetry Collector is a flexible, vendor-neutral telemetry pipeline, but extensibility is still more operationally expensive than it should be. The contrib distribution offers many community components, yet some teams cannot adopt the full binary as-is because they require tighter control over included functionality and security posture. Building a smaller collector with only the necessary components is possible, but in practice, it often means maintaining a custom build pipeline just to support relatively small extensions. This talk explores an alternative model for dynamically customizing the OpenTelemetry Collector with WebAssembly. Instead of rebuilding and redistributing the entire collector binary for each change, custom receiver, processor, and exporter logic can be introduced in a more decoupled way. The session examines what this model enables, where it fits, where it falls short, and what trade-offs emerge around safety, portability, performance, and operations.

Transcript

1. #KubeCon #CloudNativeCon OTel meets Wasm: Rethinking OpenTelemetry Collector Extensibility Kotaro Inoue, Individual Tsuzuki Tsuchiya, LY Corporation
2. How many of you have…? Used OpenTelemetry Collector (incl. 3rd party distro) 🙋
3. How many of you have…? Built OpenTelemetry Collector (with ocb) 🙋
4. How many of you have…? Written OpenTelemetry Collector plugin 🙋
5. About us Kotaro Inoue Software Engineer / Cloud Infrastructure Architect Kubernetes Org Member GitHub: musaprg / X: @musaprg / LinkedIn: musaprg Tsuzuki Tsuchiya Software Engineer at LY Corporation, Japan Developing and operating internal Kubernetes as a Service GitHub: tsuzu / X: @_tsuzu_ / LinkedIn: tsuzu
6. Agenda 1. Overview of OpenTelemetry Collector Internal and Operational Challenges 2. Overview of WebAssembly WebAssembly for Extensibility 3. Introduction to OTelWasm Bringing WebAssembly to the OTel Collector 4. Demo OTelWasm in Action 5. Toward Production Challenges and Future Directions
7. Overview of OpenTelemetry Collector Internal and Operational Challenges
8. What is OpenTelemetry? • An Incubating project of the Cloud Native Computing Foundation (CNCF) • An open-source, vendor-neutral observability framework https://github.com/cncf/artwork • Responsible for generating, exporting, and collecting telemetry (metrics, logs, traces, etc.) • Includes: • OpenTelemetry Protocol (OTLP) for telemetry data and transport • Language-specific SDKs for application instrumentation • OpenTelemetry Collector
9. OpenTelemetry Protocol (OTLP) • Standard protocol for exchanging telemetry data • Defines: • Data encoding using Protocol Buffers (protobuf) • Transport over gRPC or HTTP
10. OpenTelemetry (OTel) Collector • Vendor-neutral implementation for receiving, processing, and exporting telemetry • Builds telemetry pipelines from modular components • Receiver – Ingests telemetry • Processor – Transforms or enriches telemetry • Exporter – Sends telemetry to backend systems • Implemented in Go • Custom components can also be implemented in Go https://opentelemetry.io/docs/collector/
11. Official Distributions of OTel Collector Core Distribution • All components from the Core repository • A curated subset of Contrib components • Stable, “classic” distribution • Only tracks new components only from the Core repository Contrib Distribution • All components from the Core repository • All components from the Contrib repository • Includes open-source and vendor-supported components https://github.com/open-telemetry/opentelemetry-collector-releases/blob/main/distributions
12. Contrib Distro is a good starting point, but… Production Considerations • Large binary size due to the number of bundled components • Larger attack surface due to unnecessary components Contrib Distribution • All components from the Core repository • All components from the Contrib repository • Includes open-source and vendor-supported components https://github.com/open-telemetry/opentelemetry-collector-releases/blob/main/distributions
13. OpenTelemetry Collector builder (ocb) • A tool for building your own custom Collector distribution • Define a builder manifest in YAML that lists the components to include (shown on the right) • OCB generates the source files required to build the Collector from the manifest
14. Downside: Operational Overhead Even small extensions may require maintaining a custom build pipeline Custom build configuration Binary build and distribution CI/CD setup and maintenance 🤔 How can we make the Collector easier to extend?
15. Our Motivation Dynamically add or modify Collector components without rebuilding the OTel Collector
16. Options for Dynamic Extensibility • Domain-specific language (DSL) ◦ OTTL — OpenTelemetry Transformation Language ▪ Designed for telemetry transformation in processors ▪ Used by the Contrib transformprocessor • Embedded scripting language ◦ Lua ◦ Python • Portable execution format ◦ WebAssembly
17. Overview of WebAssembly WebAssembly for Extensibility
18. WebAssembly (Wasm) A portable instruction format and execution model • Originally designed for near-native execution in web browsers • Now widely used as an embedded runtime outside the browser Why Wasm? • • • • https://github.com/carlosbaraza/web-assembly-logo/blob/master/dist/icon/web-assembly-icon.svg Near-native performance Multiple source languages Sandboxed execution Portability across runtimes https://webassembly.github.io/spec/core/intro/introduction.html
19. Real-World Examples of Wasm Extensibility WebAssembly is already used as an extension mechanism in several real-world systems. • Proxy-Wasm — proxies such as Envoy • Kubernetes Scheduler — kube-scheduler-wasm-extension • Trivy — container image vulnerability scanner • Open Policy Agent — policy engine
20. WebAssembly (Wasm) Examples of Wasm Runtimes Wasm Guest Wasm Runtime (Wasm Host) Host OS Server • In browsers ◦ V8 — Chrome ◦ SpiderMonkey — Firefox • Outside the browser ◦ Wasmtime ◦ WasmEdge ◦ wazero
21. How Hosts and Wasm Guests Interact Guest Function Host (2) Host-provided functions (1) Guest-exported functions (3) Shared data representation Host Function Guest
22. WebAssembly System Interface (WASI) Standard interfaces for accessing host capabilities https://wasi.dev/interfaces • Exposes host resources to Wasm guests through standard APIs ◦ Similar to POSIX system calls • Examples: ◦ File systems ◦ Clocks ◦ Randomness • This talk uses WASI Preview 1 (WASI 0.1) ◦ Widely supported across languages and runtimes • Newer versions (WASI 0.2/0.3) are based on the Component Model
23. Socket API Support in WASI Preview 1 APIs for pre-opened sockets only • sock_accept • POSIX accept(2) • sock_recv WASI Preview 1 alone is insufficient for implementing an HTTP server • POSIX recv(2), readv(2) • sock_send • POSIX send(2), writev(2) • sock_shutdown • POSIX shutdown(2) Missing APIs include socket(2), bind(2), and listen(2).
24. Socket Support through WASIp1 Extensions WasmEdge Socket Extension • Designed to provide socket APIs missing from WASIp1 • Implemented by WasmEdge, a CNCF-hosted WebAssembly runtime • SDKs available for:JavaScript / Node.js, Rust, C, Go • An extension of WASIp1 aiming for broader POSIX compatibility WASIX • Led by Wasmer • Implemented in the Wasmer WebAssembly runtime • SDKs available for: Rust, C
25. Go Support for WebAssembly and WASI Go 1.11 • Added support for compiling Go to WebAssembly (GOOS=js GOARCH=wasm) • Added WebAssembly support to the standard library Go 1.21 • Added the //go:wasmimport directive ◦ Import functions provided by the host • Added support for targeting WASIp1 (GOOS=wasip1 GOARCH=wasm) • Added WASIp1 support to the standard library Go 1.24 • Added the //go:wasmexport directive ◦ Export functions callable by the host • Added support for building WASIp1 reactor modules ◦ Long-lived modules with callable exports Before Go 1.24, TinyGo was commonly used for Go-based Wasm plugins https://go.dev/doc https://github.com /tinygo-org/tinygo-site/blob/release/static/im ages/tinygo-logo.png
26. Go Support for WASI Preview 1 • Standard library support for WASIp1 • os, syscall, and parts of net • Limited to the socket capabilities available in WASIp1 • WasmEdge socket extensions via dispatchrun/net • Adds support for creating outbound connections and listeners • Provides net.Dialer- and net.Listener-compatible APIs https://go.dev/doc
27. wasibuilder • Replaces Go standard library packages at build time • Uses implementations compatible with the WasmEdge Socket Extension • Enables existing Go applications to target Wasm with minimal code changes
28. Introduction to OTelWasm Bringing WebAssembly to the OTel Collector
29. OTelWasm • WebAssembly plugins for the OpenTelemetry Collector • Go SDK available • Supported components: • Receiver • Processor • Exporter • Includes a Builder manifest for: • Core Distribution + OTelWasm components
30. (Recap) How Hosts and Wasm Guests Interact Guest Function Host (2) Host-provided functions (1) Guest-exported functions (3) Shared data representation Host Function Guest
31. OTelWasm Host–Guest Interface Host • start***Receiver • process*** • push*** Wasm Otel Runtime Col (Wazero) (2) Hostprovided functions • • • • current*** setResult*** getPluginConfig getShutdownRequested (1) Guest-exported functions (3) Shared data representation OTLP protobuf messages Guest Module
32. Wazero A WebAssembly runtime written entirely in Go • Zero external dependencies • No CGO dependency • Embeddable directly into Go applications • Two execution modes ◦ Interpreter — available on all Gosupported platforms ◦ Compiler — available on amd64 and arm64 • Used by open-source projects such as: ◦ Kube-scheduler-wasm-extension ◦ Trivy
33. Telemetry Processing Flow in wasmprocessor
34. Available plugin sources • Local File • Remote ◦ HTTP https://example.com/plugins/otlpreceiver.wasm ◦ OCI Image oci://ghcr.io/otelwasm/plugins/otlpreceiver:latest ▪ Wasm OCI Artifact Layout (by CNCF Tag Runtime) ▪ Compat (general single layer docker image)
35. Demo OTelWasm in Action
36. OpAMP Integration 36
37. Demo Architecture
38. Toward Production Challenges and Future Directions
39. Performance: Benchmark: Processor Append a new label to 100 records OTelWasm (wazero interpreter) OTelWasm (wazero compiled) ここにベンチマーク結果の表がく Time 27.0 ms る Memory 1.43 MB x 35 x9 769 µs 163 KB x 354 x 96 Go-native Plugin 2.17 µs 1.7 KB Machine | Apple M3 Pro (11 cores), macOS (Darwin 24.3.0) Go | 1.26.4 wazero | v1.12.0 48
40. Performance: Performance Issues 49
41. Performance: The Proto ABI (Current) 50
42. Performance: The Handle/Accessor ABI 51
43. Performance: Handle/Accessor ABI: Results Append a new label to 100 records ABI OTelWasm (wazero interpreter) Proto ABI 27.0 ms る Handler/Accessor ABI OTelWasm (wazero compiled) ここにベンチマーク結果の表がく 185 µs x 35 x 6.3 769 µs x 26 29.1 µs x 354 x 13 Go-native Plugin 2.17 µs N/A Machine | Apple M3 Pro (11 cores), macOS (Darwin 24.3.0) Go | 1.26.4 wazero | v1.12.0 52
44. Newer WASI Specs Version Sockets Threads Async Rust Zig Tiny Go Go Wasm Runtime WASI 0.1 ❌ ❌ ❌ ✅ ✅ ✅ ✅ Wasmtime WasmEdge Wasmer wazero WASI 0.2 ✅ ✅ ❌ ✅ ✅ ✅ ❌ Wasmtime WASI 0.3 ✅ ✅ ✅ ✅ ✅ ❌ ❌ Wasmtime 53
45. Summary 1. OTelWasm - Collector plugins in Wasm, pulled from OCI registries 2. Performance - 354x slower than native, but the handle ABI cuts it to 13x 3. Limitations - WASI 0.1 is missing key features; WASI 0.2/0.3 support have been eagerly awaited . OTelWasm is not production ready yet, but the the extension with Wasm now works! We’d appreciate your feedback!