[HN Gopher] Observability in WebAssembly
___________________________________________________________________
Observability in WebAssembly
Author : neuronicnobody
Score : 79 points
Date : 2023-08-29 13:10 UTC (9 hours ago)
(HTM) web link (dev.dylibso.com)
(TXT) w3m dump (dev.dylibso.com)
| pranay01 wrote:
| 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
|
| [1] https://github.com/SigNoz/signoz
| nilslice wrote:
| 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!
| pranay01 wrote:
| Awesome! Would check out the github issue
| bhelx wrote:
| 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.
| serverlessmom wrote:
| Oh neat! (I was here to ask the same question as above) would
| love to share the project when OTel support is released!
| xena wrote:
| I love this. I wish it supported something self-hosted like
| Jaeger though.
| nilslice wrote:
| we will have a pure HTTP & gRPC OTel adapter soon - just
| focused on the platforms first for this announcement but follow
| the repo for updates:
|
| https://github.com/dylibso/observe-sdk
| wikiwong wrote:
| 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!
| naillo wrote:
| 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.
| nilslice wrote:
| i'm the developer (non-designer) responsible for this, and
| dying laughing, so thank you!
| onemoresoop wrote:
| Somebody is a big fan of mustard
| nilslice wrote:
| twomoresoops plz
| [deleted]
| syndicatedjelly wrote:
| lol i didnt even notice the change, just that i felt more
| agitated by the end
| lukevp wrote:
| 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!
| wikiwong wrote:
| Thanks Luke, we greatly appreciate your engagement and help in
| hardening this ecosystem!
| nilslice wrote:
| you're too kind! and excited to see your WebAssembly projects
| here on HN sometime too :)
| titzer wrote:
| 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.
| wikiwong wrote:
| We're inspired by this project, linking for posterity:
| https://github.com/titzer/wizard-engine
| bhelx wrote:
| Thanks Ben! Really looking forward to your WasmCon talk.
| nilslice wrote:
| huge fan of what you're doing with Wizard & Virgil. and thanks
| for all you've done for wasm!
| neuronicnobody wrote:
| Extract logs, traces, and metrics from Wasm!
| kbknapp wrote:
| 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!
| nilslice wrote:
| 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!
| bhelx wrote:
| 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
| _boffin_ wrote:
| Was just thinking of something like this last night. Now, wonder
| if I can compile JS and automatically wire up apm for all spans.
| bhelx wrote:
| 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
| _boffin_ wrote:
| I'll be reviewing.
|
| 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?
| bhelx wrote:
| I have an instrumented version of QuickJS that can be used
| in the javy toolchain:
| https://github.com/bytecodealliance/javy
|
| 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.
| _boffin_ wrote:
| Awesome work and looking forward to checking it out.
|
| 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
| [deleted]
___________________________________________________________________
(page generated 2023-08-29 23:01 UTC)