Add WebAssembly as a tier-3 supported platform

[evan-bradley]

Component(s)

No response

Is your feature request related to a problem? Please describe.

The Collector has a large feature set that makes it useful as a telemetry collection and processing utility in a variety of contexts. However, as a standard executable binary, it may not always be accessible to me in all situations I would like.

Describe the solution you'd like

WebAssembly (Wasm) is currently the best candidate for a "write once, run anywhere" technology, based on current software support. There are a number of popular standalone runtimes, it is supported by all major browsers, and a handful of languages offer libraries that embed a Wasm runtime inside a program.

Go has good support for Wasm, which extends to running the Collector as a Wasm binary when compiled with components that don't rely on standard OS syscalls: opening ports, filesystem interactions, etc. As a result, fairly minimal changes to the current Collector codebase are required to support WebAssembly output.

I would like to propose that we add WebAssembly (specifically GOOS=js) as a tier-3 platform to our documented platform support, with an eye toward tier-2 support if there is community demand.

In the near-term, this will require:

1. Gate certain parts of the Collector that make syscalls not supported in WebAssembly behind build flags
2. Add some basic tests in CI to verify WebAssembly support. This should be easy, as WebAssembly runtimes are available on the OSes we run on our GH Actions runners.

Go also has WASI support, which is generally used for running on WebAssembly runtimes as opposed to in the browser. This is less restrictive and easier to port to, which we can address after supporting GOOS=js.

Describe alternatives you've considered

No response

Additional context

No response

Tip

_{React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}

[axw]

I could see this being helpful for something like open-telemetry/opentelemetry-collector-contrib#11772, hypothetically enabling the WASM code to directly use pdata etc.

Another place this could be useful, and maybe more realistic than above, is for expanding https://ottl.run to complete pipelines, including otlphttpexporter.

@evan-bradley just out of curiosity, are you able to share any specific use cases that motivated opening this?

[evan-bradley]

I could see this being helpful for something like open-telemetry/opentelemetry-collector-contrib#11772, hypothetically enabling the WASM code to directly use pdata etc.

The implementation of this is a bit reversed from that issue: here we are compiling the Collector to a Wasm binary, as where that issue describes running Wasm binaries inside a Wasm runtime inside the Collector. It may help inform it in some minor ways, but overall that issue is much more difficult, in my opinion.

Another place this could be useful, and maybe more realistic than above, is for expanding ottl.run to complete pipelines, including otlphttpexporter.

Absolutely, I think we could re-use this to a degree.

just out of curiosity, are you able to share any specific use cases that motivated opening this?

I did some research a while back and found out we are much closer to implementing this than I previously thought. My main goal right now is to explore running the Collector in the browser, for e.g. running Collector processors alongside the OTel JS SDK. The immediate use for this is for an upcoming Observability Day talk Pablo and I have that covers the current state-of-the-art on this topic.

[axw]

The implementation of this is a bit reversed from that issue: here we are compiling the Collector to a Wasm binary, as where that issue describes running Wasm binaries inside a Wasm runtime inside the Collector. It may help inform it in some minor ways, but overall that issue is much more difficult, in my opinion.

Oh yeah I understood that, just saying that it might provide some benefit if you wanted to build a Go-based processor that is delivered as WASM, since you could then use collector components (pdata, etc.). In practice it might not work out though, since data will need to cross between the host and WASM runtime.