-
Notifications
You must be signed in to change notification settings - Fork 826
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(tracing) Introducing USDT probes in Wasmer #2152
Closed
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is a proof-of-concept, or at best a work-in-progress, of integrating USDT probes inside Wasmer through the new `wasmer-tracing` crate. USDT stands for Userland Statically Defined Tracing. USDT probes are probes originally designed by DTrace, but now sucessfully implemented in many environments, like Darwin, Solaris, Linux, Illumos, and even [Windows][windows-dtrace]. It allows dynamic tracing at low-cost (a probe is a noop, except when run with `dtrace` where a special section of the object file is read to get the real probes and to instrument the executable code, in some cases). USDT aren't tied to DTrace only now. On Linux for example, eBPF understands USDT probes. The process of generating and linking the probes is automated, but the FFI bridge (`probes_ffi.c` and `lib.rs`) must be completed by hand for each new added probe. It's not an issue as a few number of strategic probes are going to be implemented. This patch provides a new crate: `wasmer-tracing`. The current set of probes (`instance_start`, `instance_end`, `function_start`, `function_invoked2` and `function_end`) is only present to showcase the idea. The `scripts/tracing.d` script showcases how to read data from those probes to trace the execution of the VM itself with a DTrace script. Note that for the moment, the probes —as implemented— are designed to be used in Rust. It means we can only analyze the compilation-step/compile-time of a Wasm module into executable code, and some runtime operations. More work is required to implement probes inside the executable code we generate with the compilers, i.e for the entire execution-step/runtime (LLVM has [XRay Instrumentation] for example, not sure it's the path we must follow but it exists). The next commit showcases how to use `wasmer-tracing`. [windows-dtrace]: https://techcommunity.microsoft.com/t5/windows-kernel-internals/dtrace-on-windows/ba-p/362902 [XRay Instrumentation]: https://www.llvm.org/docs/XRay.html
This patch showcases `wasmer-tracing` inside `wasmer` itself. Let's see: ```sh $ make build-wasmer $ sudo dtrace -l -c ./target/release/wasmer | rg wasmer 54242 wasmer38542 wasmer wasmer_tracing_probe_function_end function-end 54243 wasmer38542 wasmer wasmer_tracing_probe_function_invoke2 function-invoke2 54244 wasmer38542 wasmer wasmer_tracing_probe_function_start function-start 54245 wasmer38542 wasmer wasmer_tracing_probe_instance_end instance-end 54246 wasmer38542 wasmer wasmer_tracing_probe_instance_start instance-start ``` See, Wasmer has USDT probes now! Now, let's use the `lib/tracing/scripts/tracing.d` script (it's not fabulous, it just showcases the principle): ```sh $ sudo ./lib/tracing/scripts/tracing.d -c './target/release/wasmer run ./tests/examples/add.wat --invoke add -- 39 3' From DTrace (wasmer-tracing) 42 instance starts function starts function invoked with arg0=39, arg1=3 function ends instance ends ``` The first output line (“From DTrace (wasmer-tracing)”) is from the `tracing.d` script. The second output line (“42”) is from Wasmer (it's the sum of 39 and 3). The rest of the output is from the `tracing.d` script. Notice how the `wasmer*:::function-invoked2` block receives the arguments of the `add` exported function, inside `arg0` and `arg1`. I'm totally aware that `wasmer` isn't the correct place to declare probes. Ideally, the VM, the compilers and the engines are better places. Remember that it's just to showcase `wasmer-tracing`.
Next step, remove |
Hywan
changed the title
feat(tracing) Introducing
feat(tracing) Introducing USDT probes in Wasmer
Mar 11, 2021
wasmer-tracing
To make our lives simpler, we have created `sonde` (https://github.com/Hywan/sonde-rs). It replaces `wasmer-tracing`.
Closing this |
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See original description to get the context
Description
Introducing
wasmer-tracing
(719f37d)This is a proof-of-concept, or at best a work-in-progress, of
integrating USDT probes inside Wasmer through the new
wasmer-tracing
crate.
USDT stands for Userland Statically Defined Tracing. USDT probes are
probes originally designed by DTrace, but now sucessfully implemented
in many environments, like Darwin, Solaris, Linux, Illumos, and even
Windows. It allows dynamic tracing at low-cost (a
probe is a noop, except when run with
dtrace
where a special sectionof the object file is read to get the real probes and to instrument
the executable code, in some cases).
USDT aren't tied to DTrace only. On Linux for example, eBPF
understands USDT probes.
The process of generating and linking the probes is automated, but the
FFI bridge (
probes_ffi.c
andlib.rs
) must be completed by hand foreach new added probe. It's not an issue as a few number of strategic
probes are going to be implemented.
This patch provides a new crate:
wasmer-tracing
.The current set of probes (
instance_start
,instance_end
,function_start
,function_invoke2
andfunction_end
) is onlypresent to showcase the idea.
The
scripts/tracing.d
script showcases how to read data from thoseprobes to trace the execution of the VM itself with a DTrace script.
Note that for the moment, the probes —as implemented— are designed to
be used in Rust. It means we can only analyze the
compilation-step/compile-time of a Wasm module into executable code,
and some runtime operations. More work is required to implement probes
inside the executable code we generate with the compilers, i.e for the
entire execution-step/runtime (LLVM has XRay Instrumentation for
example, not sure it's the path we must follow but it exists).
Showcasing how to use
wasmer-tracing
(773ded6)This patch showcases
wasmer-tracing
insidewasmer
itself. Let'ssee:
$ make build-wasmer $ sudo dtrace -l -c ./target/release/wasmer | rg wasmer 54242 wasmer38542 wasmer wasmer_tracing_probe_function_end function-end 54243 wasmer38542 wasmer wasmer_tracing_probe_function_invoke2 function-invoke2 54244 wasmer38542 wasmer wasmer_tracing_probe_function_start function-start 54245 wasmer38542 wasmer wasmer_tracing_probe_instance_end instance-end 54246 wasmer38542 wasmer wasmer_tracing_probe_instance_start instance-start
See, Wasmer has USDT probes now! Now, let's use the
lib/tracing/scripts/tracing.d
script (it's not fabulous, it justshowcases the principle):
The first output line (“From DTrace (wasmer-tracing)”) is from the
tracing.d
script. The second output line (“42”) is from Wasmer (it'sthe sum of 39 and 3). The rest of the output is from the
tracing.d
script.
Notice how the
wasmer*:::function-invoke2
block receives thearguments of the
add
exported function, insidearg0
andarg1
.I'm totally aware that
wasmer
isn't the correct place to declareprobes. Ideally, the VM, the compilers and the engines are better
places. Remember that it's just to showcase
wasmer-tracing
.Description
This patch introduces USDT probes inside Wasmer (not inside the code generated by the compilers). Originally, this patch was doing it with
wasmer-tracing
, a new crate. There was a limitation though: We need to add clearly a lot of probes, and maintaining them by hand was complex, especially because the declaration of the probes was centralized in a single crate while they were being used in multiple crates. This patch has been updated to usesonde
, a crate we wrote to address all our needs and previous limitations.The resulting diff is much (much) smaller and easier to review.
Review