How does instrumenting work?

[ubiquitous-dev]

I think I follow the concept in general... so for example if I'm using rust to host wasm programs, I would use the rust SDK to inject a set of host functions into the wasm instance prior to initializing the guest module. Then the guest module (if it's instrumented) would have hooks to write to those injected functions from the SDK. Then you would take the telemetry in the SDK and register an adapter to transform it into the format you need to send to Datdog, OTEL, etc. The part I'm not clear about is how you instrument the guest module.

I see there's an auto-instrumenter, but what metrics/traces/logs is it actually getting? normally a guest has some type of observability SDK to actually collect the metrics (eg. if you are building a .NET program, you would install a core OTEL library and then additional OTEL libraries for each service to instrument asp.net core, http, aws sdk calls, etc. etc.) How is that part working? Like does it depend on you using some standard component within your code like OTEL and then it will adapt it on the host side to different formats? or is there a bespoke format that does the guest=>host communication, and the observe-sdk is going to build that out?

What I'm really interested in is am I just getting stdout as a "log" and fuel/epoch metrics for execution? or is there more to it than that?

[bhelx]

This answer is as it works today, and so some of this may change. But I'll try to describe how things work now and how they will work in the near future.

I think I follow the concept in general... so for example if I'm using rust to host wasm programs, I would use the rust SDK to inject a set of host functions into the wasm instance prior to initializing the guest module. Then the guest module (if it's instrumented) would have hooks to write to those injected functions from the SDK. Then you would take the telemetry in the SDK and register an adapter to transform it into the format you need to send to Datdog, OTEL, etc.

Yes, 100% correct!

I see there's an auto-instrumenter, but what metrics/traces/logs is it actually getting? normally a guest has some type of observability SDK to actually collect the metrics (eg. if you are building a .NET program, you would install a core OTEL library and then additional OTEL libraries for each service to instrument asp.net core, http, aws sdk calls, etc. etc.) How is that part working? Like does it depend on you using some standard component within your code like OTEL and then it will adapt it on the host side to different formats? or is there a bespoke format that does the guest=>host communication, and the observe-sdk is going to build that out?

As of today, there are 2 distinct (but not mutually exclusive) paths to instrumenting the guest. First is our instrumenting compiler. This can "recompile" any wasm module and insert trace probes which turns each invocation of an export function into a tracer. You'll have the full trace of functions and memory allocation events that occurred.

Second is to manually instrument, which means manually calling the Host functions (Observe API) that the Host SDKs implement. You can call these host functions directly but it's better to use our language bindings to make it idiomatic. Right now we support C, C++, and Rust. Here is an example of what this looks like in Rust. Although metrics and logs are experimental right now and might not work in every adapter, span_enter and span_exit and span_tags should work everywhere.

Note: I do have experimental guest language bindings for JS guests that use quickjs, but it's not available yet. That will be our first dynamic language we support.

Regarding OTEL, in the future we will support OTEL exporters that use the language bindings so you could use OTEL in the guest. But right now you have to code to our Host API then use an OTEL adapter if you want OTEL.

What I'm really interested in is am I just getting stdout as a "log" and fuel/epoch metrics for execution? or is there more to it than that?

You may be on hold at the moment. We don't support .NET on the host side, but when we include the observe-sdk into the Extism runtime, that should enable it for you. We don't support fuel yet but it's something we're exploring.