I wonder how well (or if it's even possible?) to pair this with hosted WASM runners (like CloudFlare Workers, or Fastly Runners, etc.).
It looks like there is also (limited?) support for tracing functions and allocations in WASM binaries you didn't compile. I'm looking forward to trying this out!
Yes, it should work in Cloudflare, you'd just need to use the JS adapter for whichever APM you use (Datadog, Honeycomb, Lightstep w/ more coming soon). The library provides import functions you pass into your module instance, and as long as the Wasm was instrumented before you deploy the Worker, you should have no issues. Please let us know if you hit any though!
One caveat that Datadog (specifically traces) probably won't work on the edge just yet. But if this is something you're interested in kbknapp feel free to post your questions or requests here https://github.com/dylibso/observe-sdk/discussions
I do have some experimental code working with QuickJS that does this. Feel free to reach out of if you're interested in trying it out or start a discussion https://github.com/dylibso/observe-sdk/discussions
Question: are you wiring it up like how APM is wired up in JVM applications or what exactly are you doing? Does it effect stack trace outputs or leave those alone?
1. Emit metrics directly about the QuickJS runtime similar to node metrics
2. Expose the Observe API as js bindings
With the Observe API exposed to JS, you can do manual instrumentation. I have also instrumented the pieces of QuickJS that invoke JS functions in order to automatically emit spans and it works, but still trying to fill some information gaps to make it more usable than manual instrumentation.
> are you wiring it up like how APM is wired up in JVM applications or what exactly are you doing? Does it effect stack trace outputs or leave those alone?
I can't speak to how JVM does it, but no this does not effect the call stack.
This is by the same team behind Extism, a WASM plug-in library implemented in multiple languages. I’ve been active on their Discord and they’ve been really awesome and supportive of any questions I have. I’m excited to see where they go with this observability SDK. WASM has a major usability problem right now, and we need things like this and Extism to make it smoother to produce and consume wasm programs!
What a crazy choice of background color. On the other hand it kinda signals that the developers themselves designed it which is generally a good sign of other characteristics of a project.
Great to see more focus on observability for Wasm now. This was a major impetus and still a major goal of the Wizard Research Engine, which has engine-level hooks that allow programmable instrumentation.
Thanks for the feedback, we've done some internal work to verify open source, self hosted platforms like Jaeger, Zipkin, and OpenObserve. Official support is coming soon!
Not sure if OP is from Dylibso, but would love to see telemetry data emitted in OpenTelemetry format as well so different tools (including open source ones) which support Otel format can also consume this data.
I am one of the maintainers at SigNoz [1], an otel native open source observability platform and would love to enable our users to see telemetry data from WASM
It shall be done! we already have the OTel formatting ready to go, but focused on these platform specific adapters for launch. In fact, Lightstep and Honeycomb adapters are fairly thin wrappers around the OTel formatting we do out of our instrumentation layer.
We’ve got a ticket open on the GitHub repo to track in case you’d like to follow along. Happy to get your users supported!
Yep, should be really soon. Also, we will check out signoz too. Could you see a reason to have an official adapter at some point? The adapter can tie things together for you that the platform expects, like set extra metadata, set trace ids, etc.
32 comments
[ 6.0 ms ] story [ 90.2 ms ] threadIt looks like there is also (limited?) support for tracing functions and allocations in WASM binaries you didn't compile. I'm looking forward to trying this out!
Question: are you wiring it up like how APM is wired up in JVM applications or what exactly are you doing? Does it effect stack trace outputs or leave those alone?
There are two primary goals:
1. Emit metrics directly about the QuickJS runtime similar to node metrics 2. Expose the Observe API as js bindings
With the Observe API exposed to JS, you can do manual instrumentation. I have also instrumented the pieces of QuickJS that invoke JS functions in order to automatically emit spans and it works, but still trying to fill some information gaps to make it more usable than manual instrumentation.
> are you wiring it up like how APM is wired up in JVM applications or what exactly are you doing? Does it effect stack trace outputs or leave those alone?
I can't speak to how JVM does it, but no this does not effect the call stack.
One thing I’m also thinking about for node and friends is looking into is using v8 profiling and seeing if I can hook up something from that.
But yeah, great stuff
https://github.com/dylibso/observe-sdk
I am one of the maintainers at SigNoz [1], an otel native open source observability platform and would love to enable our users to see telemetry data from WASM
[1] https://github.com/SigNoz/signoz
We’ve got a ticket open on the GitHub repo to track in case you’d like to follow along. Happy to get your users supported!