Tracers – Rust Instrumentation Library

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.

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.