
Tracers – Rust Instrumentation Library - adamnemecek
https://github.com/anelson/tracers
======
anelson
Author here, I was surprised to see this on HN so early. I haven't even
published the crate yet.

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...

~~~
adamnemecek
I take that as a compliment, haha.

~~~
anelson
As well you should. Few things are more motivating than seeing one's not-
quite-yet-finished project on HN ;)

------
brian_herman__
Shouldn’t it use eBPF on Linux instead of system tap?

~~~
anelson
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.

~~~
fnord123
>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.

Sounds like a great use case to document.

~~~
anelson
Yes absolutely. Better docs are a top priority right now.

------
tracker1
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.

~~~
orf
This doesn’t make sense to include in the standard library, it’s a perfect use
case for a crate.

------
anelson
This is now published on crates.io for those of you interested in playing with
it:

[https://crates.io/crates/tracers](https://crates.io/crates/tracers)

Better docs and a quick start coming soon.

------
sanxiyn
I am curious how this compares to [https://github.com/cuviper/rust-
libprobe](https://github.com/cuviper/rust-libprobe)

~~~
anelson
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.

