Transcript: WASI OTel Host Plugin Demo, TypeScript Templates & v2 Service Docs
wasmCloud Weekly Community Call — Wed, February 11, 2026 · 35m 1s
Speakers: Bailey Hayes, Jeremy Fleitz, Eric, Lucas Fontes, Liam Randall, Frank Schaffa, Yordis Prieto
Full Transcript
Bailey Hayes 00:57
Jeremy, I just made you a co-host too.
Liam Randall 01:55
Jeremy, excited for your OTel demo.
Jeremy Fleitz 02:23
I know everybody's in various different parts of the country, but after all the snow, it's amazing. I started to see grass — still got some snow.
Bailey Hayes 02:40
It's a beautiful day today here in North Carolina.
Liam Randall 02:50
Beautiful — where the whole place is still covered with snow, Crete. It's like hardened, six inches of ice — everything is so thick even I can walk on it. Bitter cold here too. I've never seen anything like this in DC.
Frank Schaffa 04:04
Not much to report. I was able to run a Hello World on kind — made it really trivial, that works fine. What I'm having trouble with is bringing my own image with that sense.
Bailey Hayes 04:34
When you say your own image, you mean building your own wasmCloud host, or —
Frank Schaffa 04:41
No — creating my version of Hello World. It compiles and runs locally, but exporting the Rust version and getting it to run, not yet.
Bailey Hayes 05:01
If you're running into stuff, feel free to post in the wasmCloud Slack Help channel. Maybe I'll spy something that looks familiar.
Frank Schaffa 05:13
It'd be great if there's some — not just the happy path, but actually some debugging hints.
Bailey Hayes 05:21
I created a Claude skill for some of the debugging with wash and component development. If you want it, I'll drop a link. Knowing how to use wac edit, for example, is something folks stumble on. I added this specifically for that. If you're using Claude, I recommend adding our skills via the Claude marketplace.
Sorry I'm running a little late — I was code-reviewing Eric's doc so we could have a doc of the week, but I'm too slow on that, so I'll have to just pull up your PR live, Eric. Let me hit custom livestream.
Lucas Fontes 06:41
It's the same as Python.
Bailey Hayes 06:45
We're live. Welcome to wasmCloud community call, February 11. We're going to start with a demo from Jeremy, who's been working on a host plugin for WASI OTel, which is really exciting. We talked about it and telemetry in general the last couple of calls. This is a working example of it running. Jeremy, take it away.
Jeremy Fleitz 07:14
Thank you very much. This is the pull request currently up under wasmcloud/wash. What this does — it adds the wasi-otel host plugin to wash runtime. Quick overview of the interfaces it provides: tracing, logs, and metrics, implementing the wasi-otel interface. Functions provided: on_start, on_end, outer_span_context (so you can do full tracing), and for logging/metrics it's on_emit and export.
If you want to run this just using wash dev, you add it to your .wash config YAML under dev: with wasi-otel: true. As far as settings for OpenTelemetry, this is exactly the same way OTel works on the host that Lucas demoed about a month ago — it uses the underlying SDK and all the default OTel environment variables. There's nothing you have to provide to the host itself beyond those.
The example under examples/otel-http started with just the HTTP counter, but also has common calls to the OTel provider showing logging, metrics, and tracing.
For the demo — first I'm going to use Aspire, which is a Dockerized OTel collector. I have two ports exposed: 18888 for the dashboard and 5318 for the collector. Let me open the dashboard — no logs, completely expected because I haven't started anything yet.
Now I go to the OTel HTTP example. I export my two environment variables — OTEL_EXPORTER_OTLP_ENDPOINT at port 5318, and the export protocol. Then I run wash dev. The environment variables turn on OTel for the host too, so I'm going to see both host-level OpenTelemetry and OTel from the component using this host plugin.
It's listening on port 8000 — I'll start making some curl statements. The HTTP counter is incrementing as expected. Going to Aspire — at first there's a ton of wash-runtime (the host-level metrics from a month ago), but now there's also wasi-otel-type logging, providing the service name. You can also pass additional info as a wasi-otel-log-record in JSON.
The cool thing — when I come to traces, this is where the life cycle comes together. I see spans at both the runtime and component level. At first it's building the component, reloading the component. Then when a request comes in, you see spans from runtime and wasi-otel. The way this works: on workload-item bind, the host plugin takes the active context from the component and mashes that into a workload ID that gets passed, so every trace event from a component is keyed with that ID — no confusion about which OTel data came from which component.
Clicking inside a trace I can see the runtime call and the first wasi-otel call. I'm passing request-count as a value from the example — I got 94. You start seeing additional calls being done at the runtime level. Timestamps are in order. Anything tagged wasi-otel is coming from the WASI component itself, not from the host runtime.
On the metrics side, wash-runtime is the host-level data. The OTel runtime is currently not pushing metrics out — not configured at the moment. But wasi-otel from inside the example uses batch exporting with a five-second timeout (configurable later through the observability init method). I'm passing two gauges from the example showing the overall counts.
Switching back to the source code — the typical bindings already there for the HTTP counter. What was added: bindings to wasi-otel and wasi-clocks (for timestamps). The function exposed on the host plugin is on_emit. The call otel-log passes log info to the OTel provider using log-record, which is flexible — you could change it to any attributes or events. Tracing works almost exactly the same way. For meter, I call metrics-export and pass a resource-metrics object.
On the host plugin lifecycle: when the host starts itself, it creates the exporters (span, log, metric) and all the providers. It reads from the OpenTelemetry SDK environment variables — if you want to change anything, set the env vars. On workload-item bind, every type we expose is added to the linker, so when you run your component it can find them without errors. The component context is created and added for that workload item, so every event is keyed with the workload ID. On unbind, we wait to make sure everything has been flushed and goes to the collector.
Jeremy Fleitz 16:57
Finally when the OTel plugin is unloaded, it does the force-flush and shutdown. The rest is basic implementation — creating the binding for when export is called for metrics or on_emit for logs, then converting the data the log record into something the wasi-otel library expects, and getting it back out. That's everything. Any questions?
Frank Schaffa 17:48
What's the overhead in terms of timing — have you tested with and without?
Jeremy Fleitz 18:03
Excellent question. I have not captured any data like that, but you're 100% right — OTel can be very noisy. Elizabeth touched on that a couple of weeks ago, with a quick way of taking out the OTel extraction so components can react faster. My demo really wanted to show info level — throwing everything out there. In a production environment I'd recommend errors only from a tracing perspective. Dev can be noisier so it's easier to see what's going on.
Bailey Hayes 18:56
One cool thing to highlight — unlike the previous ways OTel had worked between our components and providers, which involved effectively a network hop over NATS while communicating with a provider, all of this is built into the host. The individual component is talking to wasi-otel, which is an interface, so you're going from the component boundary to something implemented at the host level. You are exiting WebAssembly into the host, but those calls are in nanoseconds — same process. At the kernel level there's going to be a memcpy, that type of thing — but I think we'll find this to be blazingly fast. We should get some benches around it though.
Frank Schaffa 19:50
Having this kind of capability is really key for understanding the environment. One other thing — if the processing of this can impact performance, can this be done asynchronously?
Bailey Hayes 20:27
Right now this is operating against WASI P2. I expect us to update all of this to use native async from WASI P3 once we can depend on those features. In this scenario it's a sync call from component to host, but what the host is actually doing is async, effectively.
Frank Schaffa 21:02
Last question — in the plot, there was a number in parenthesis, what does it mean?
Jeremy Fleitz 21:21
The number of events or trace events captured. Eight at wash-runtime, four at wasi-otel. A quick way in Aspire to say: total 12 trace spans or events.
Bailey Hayes 21:46
Excellent. Thanks Jeremy. Any other questions for Jeremy? Eric's been doing an awesome job building out additional TypeScript templates. I wanted him to have a chance to give a shot for a couple more he just dropped. Eric, do you mind walking through your templates and then the doc updates?
Eric 22:27
Quick update on what we've got and what's coming. Last time I showed a couple of templates going up into the TypeScript repo — these are up now in the v2 branch. If you want to use them, go to the templates directory and the v2 branch of wasmcloud/typescript.
We've got http-client, http-hello-world using fetch, http-hello-world using Hono, and an http-service using Hono. That last one mocks a backend, so you get an example REST CRUD API working against a mock status store. But our new in-progress templates give you the same thing with KV and Blobstore backends. This does two things: gives you a working template out of the box for these tasks, and also an educational model for adding a backend to an HTTP starter.
Let's jump over and see this working. This is already running with wash dev. I'll add a new item to toss in the Blobstore — "super cool item." We'll do "extra super cool item." Then curl the items — JSON list, here's our extra super cool item. New template to work with.
We want them to function as both robust starting points for your own applications and educational models. We'll be leveraging these in the Developer Guide for wasmCloud docs. We've still got more coming — we want a good set of templates for all the core common WASI interfaces. Feedback welcome on what templates you'd like to see.
Bailey Hayes 25:16
I'm going to drop a link to the updated and expanded service docs. Do you mind speaking to that as our doc of the week?
Eric 25:41
We've had placeholder service docs and basic overview documentation for a bit, but we've needed to expand that — specifically how to create services. This update creates a comprehensive guide: not just understanding services at a high level and how they differ from components, but exactly what you need to do to run them. Service export requirements at the start, with examples of creating a service that works with wasi-cli run or with a custom interface export, walking step-by-step. Plus an expansion of the services overview page going into further detail on how this all works. As you're thinking about how to build wasmCloud applications with services, hopefully this is a more robust resource.
Bailey Hayes 26:55
You have another PR that's pretty cool too. Might as well do that one while we're here. I'm asking Lucas to code review on that one. Here's the link.
Eric 27:14
This one goes to another core piece of the wasmCloud v2 architecture — adding custom hosts and building host plugins. Crucial piece for the general v2 launch. Step-by-step illustrated with examples — walks through creating host plugins to extend wasmCloud with additional capabilities, and the process of building custom hosts for cases like edge deployment, specialized hardware, or integration with existing systems. Still under review, but the idea is to help you get started in a practical, holding-your-hand walkthrough.
Bailey Hayes 28:13
Thank you, Eric. Excellent docs. Hard to choose one doc of the week with two bangers like this. Check those out — give us feedback. Love community feedback, especially prioritizing types of templates and content. Now that we're getting ready to release wasmCloud v2 we are in the hardening final stretches. That's basically our agenda.
Frank Schaffa 28:48
Couple of questions — when are those PRs going to be merged?
Bailey Hayes 28:55
As fast as I review the services one, and as fast as Lucas reviews the other. The reason I didn't want to immediately plus the host-creation one — Lucas just did a refactor in some of that space, especially for OTel initialization. We probably want to call that out in the doc and I was worried about missing nuances.
Frank Schaffa 29:25
Does wash doctor still exist?
Lucas Fontes 29:31
wash doctor has been removed. It was checking for the existence of a few binaries in certain places, not respecting PATH. If you had nvm installed, it would not pick things up. Given that templates now can execute an optional command at the very beginning, the template itself can perform those checks. When you clone a template, the first step is download dependencies, check the environment — that's where those checks execute, where wash doctor should be executed.
Frank Schaffa 30:13
Because I was following instructions that are being updated. One of them was to do a wash doctor.
Eric 30:29
We need to strip that out. There's a PR for quick-start and updates on the Developer Guide. Some already has wash doctor removal — more to go.
Bailey Hayes 30:45
Gold feedback, Frank — keep it coming.
Bailey Hayes 30:52
Yordis, how you doing, dude?
Yordis Prieto 30:56
Hello.
Bailey Hayes 30:58
I saw you come on camera. Happy to see you.
Yordis Prieto 31:01
I missed the last one — there was a good one with the girl that presented.
Bailey Hayes 31:06
Sure — Elizabeth Gilbert.
Yordis Prieto 31:08
Sadly my contracting company put a meeting literally called "Platform stuff" that I belong to at the exact same time. So I had to watch you from YouTube.
Bailey Hayes 31:29
Do you have any questions or things you want to hear from us?
Yordis Prieto 31:34
No, but I'm on the third round of reviewing the map support in WIT and in Wasmtime. I think I'm one or two code reviews away from merging that.
Bailey Hayes 31:48
That's awesome. Another thing once you have that — you should talk to somebody like Eric here. We need you to get that documented inside the component model book.
Yordis Prieto 32:00
Okay. As for that one, I'm going to pick the bigger battle — which is struct.
Bailey Hayes 32:07
Whoa, okay.
Yordis Prieto 32:09
People told me it's tricky because of the cyclic typing situation that structs allow, but sounds like a challenge to me.
Bailey Hayes 32:21
Cool — looking forward to seeing what you drop next. Map was pretty popular. A lot of people said to me "I thought this was going to be after 1.0" — turns out we can make additive changes. We did a good job doing the versioning updates.
I got the WASI 0.2.10 release out last week. I'm really hopeful that's the last 0.2.x release — it doesn't have to be, but most of those changes are doc updates, additive changes, things hidden behind feature gates. All the development right now and the effort focuses on WASI P3.
Where we are: despite GitHub's best efforts to keep me from being able to publish a release given outages, we got the release candidate out. However that RC is not in most of the repos yet — we ran into some changes with wasi-cli that exposed existing bugs, so we're making wit-bindgen and wasm-tools fixes for that. Once those are released today, we'll roll it into things like Wasmtime. I'm really hopeful — we still haven't had another request for a change on top of that RC. I want to get it into everybody's hands as fast as humanly possible so we can harden and stabilize.
Victor has made massive progress on the second reference implementation. He may have found something that needs more clarification in the spec — he's diving deep on that today. We're also getting really close on that.
That's it for my WASI P3 update I give every week. Anybody else have anything? We might be wrapping it up early today. Have a good wasmCloud Wednesday. See ya. Bye.