Re:Tracers – Rust Instrumentation Library
by anelson on Wednesday November 20, 2019 @01:38AM
(#21581604)
This crate is for enabling low-overhead tracing of userland Rust code. To that end it supports both systemtap and ltt-ng.
Systemtap probes are available to eBPF instrumentation, so in that sense this does indirectly use eBPF. I know this isn't obvious, I haven't had a chance to get the docs up to my standard.
In fact I went to great lengths to ensure that the eBPF tracing tools can discover the trace points generated by this implementation. This even required submitting an upstream bug to the BCC toolchain. But now it works great for primitive types that have some meaningful equivalent in eBPF terms.
Re:Tracers – Rust Instrumentation Library
by fnord123 on Wednesday November 20, 2019 @05:03AM
(#21582517)
>Systemtap probes are available to eBPF instrumentation, so in that sense this does indirectly use eBPF. I know this isn't obvious, I haven't had a chance to get the docs up to my standard.
Re:Tracers – Rust Instrumentation Library
by tjfontaine on Wednesday November 20, 2019 @01:35AM
(#21581591)
You can use eBPF tooling to attach to User SDT probes; this library is a way to instrument your code once and have those probes available via the appropriate tracing infrastructure on the running platform
Re:Tracers – Rust Instrumentation Library
by anelson on Wednesday November 20, 2019 @01:41AM
(#21581615)
Yes exactly. The goal of this project is to let authors put trace points in their code and at compile time target whatever tracing system makes sense. On Linux that's either systemtap or ltt-ng. On Windows it (will be; not implemented yet) the event tracing API, on MacOS and FreeBSD it would be dtrace. There's also an option to completely disable tracing at compile time, which removes all tracing code and imposes absolutely zero runtime overhead.
Re:Tracers – Rust Instrumentation Library
by anelson on Thursday November 21, 2019 @12:40AM
(#21591720)
Cool! Assuming it's a faithful port with source-level compatibility, it should work with the existing DTrace implementation I'm building. The differences between compiler toolchains are already abstracted away by the excellent `cc` crate.
In any case I already have a Windows CI build; when DTrace is ready I'll add DTrace on Windows there and see what happens.
Re:Tracers – Rust Instrumentation Library
by tracker1 on Tuesday November 19, 2019 @05:54PM
(#21579235)
Nice to see this implementation. Would be nice to see this as an in the box option in a future Rust release, but totally understand that there are other, higher priorities.
Re:Tracers – Rust Instrumentation Library
by anelson on Wednesday November 20, 2019 @03:30AM
(#21582110)
Great question. `rust-libprobe` was the original inspiration for `tracers`, and made me start to explore what else was possible. Everything that follows shouldn't be taken as criticism of `rust-libprobe` in any way; without cuviper's work there would be no `tracers` at all.
The main limitation of `rust-libprobe` is that it uses the `asm` feature in nightly Rust. In my case I really wanted to be able to use stable Rust so that was a deal-breaker.
`rust-libprobe` also doesn't include any logic to help to expose Rust native types to the probes. It works with primitive types but I wanted a framework that would allow the use of arbitrary Rust types provided a trait implementation was available to adapt them to the C representation. An example of this is Rust `String` or `&str` types, which my code will lazily convert into a C-style string if the caller chooses to include such values in the probe.
Furthermore I wanted probes that are integrated into the type system. You define probes as methods on a trait, with regular Rust parameters. Those get translated into probes at compile time but they remain methods, so if you don't call them you get the usual unused method warnings, if you forget an argument to a probe it's a compile error, if you pass the wrong type you get a compile err, etc. It's much safer and more ergonomic, in my opinion.
Finally note that `tracers` has SystemTap and LLT-ng impls now, DTrace is about half way done, and Windows ETW is coming. `rust-libprobe` is clearly designed to support various tracing impls but it only supports SystemTap today, and the way it is designed it would be difficult to adapt it to something like DTrace which requires the use of a compile-time code gen step. `tracers` has a ton of code run at compile time specifically to support the code-gen case, so in theory any tracing system that requires compile-time code generation could be adapted to use it.
This was my first real Rust project and I was really impressed with how powerful proc macros can be.
Now I need to polish the docs and publish...
Systemtap probes are available to eBPF instrumentation, so in that sense this does indirectly use eBPF. I know this isn't obvious, I haven't had a chance to get the docs up to my standard.
In fact I went to great lengths to ensure that the eBPF tracing tools can discover the trace points generated by this implementation. This even required submitting an upstream bug to the BCC toolchain. But now it works great for primitive types that have some meaningful equivalent in eBPF terms.
Sounds like a great use case to document.
[1]: https://www.microsoft.com/en-us/download/details.aspx?id=580...
[2]: https://github.com/microsoft/DTrace-on-Windows
In any case I already have a Windows CI build; when DTrace is ready I'll add DTrace on Windows there and see what happens.
https://crates.io/crates/tracers
Better docs and a quick start coming soon.
The main limitation of `rust-libprobe` is that it uses the `asm` feature in nightly Rust. In my case I really wanted to be able to use stable Rust so that was a deal-breaker.
`rust-libprobe` also doesn't include any logic to help to expose Rust native types to the probes. It works with primitive types but I wanted a framework that would allow the use of arbitrary Rust types provided a trait implementation was available to adapt them to the C representation. An example of this is Rust `String` or `&str` types, which my code will lazily convert into a C-style string if the caller chooses to include such values in the probe.
Furthermore I wanted probes that are integrated into the type system. You define probes as methods on a trait, with regular Rust parameters. Those get translated into probes at compile time but they remain methods, so if you don't call them you get the usual unused method warnings, if you forget an argument to a probe it's a compile error, if you pass the wrong type you get a compile err, etc. It's much safer and more ergonomic, in my opinion.
Finally note that `tracers` has SystemTap and LLT-ng impls now, DTrace is about half way done, and Windows ETW is coming. `rust-libprobe` is clearly designed to support various tracing impls but it only supports SystemTap today, and the way it is designed it would be difficult to adapt it to something like DTrace which requires the use of a compile-time code gen step. `tracers` has a ton of code run at compile time specifically to support the code-gen case, so in theory any tracing system that requires compile-time code generation could be adapted to use it.