dtrace probes

Issue by graydon
Wednesday May 29, 2013 at 23:45 GMT

For earlier discussion, see https://github.com/rust-lang/rust/issues/6816

This issue was labelled with: A-instrumentation, A-libs, I-enhancement, P-low in the Rust repository

I think rust should expose dtrace userland probes

Links:
http://www.solarisinternals.com/wiki/index.php/DTrace_Topics_USDT
https://wikis.oracle.com/display/DTrace/Statically+Defined+Tracing+for+User+Applications
https://wiki.freebsd.org/DTrace/userland

Some specific providers (including some dynamic):
https://github.com/chrisa/libusdt
https://github.com/chrisa/node-dtrace-provider
http://prefetch.net/projects/apache_modtrace/index.html
https://bugzilla.mozilla.org/show_bug.cgi?id=370906

Probably at least some for pervasive / standard-library actions:

• per-task CPU time, coroutine switches, lifecycle events
• heap allocations, GC, segmented stack growth
• message passing, IO ops / byte volumes
• conditions raised

Note that the "USDT" mechanism provides static probes whereas things like libusdt (above) provide an API for dynamically registering probes at runtime. This is probably important, possibly even a good place to start, though it's slightly more expensive; ideally of course we should be able to provide both.

See also #6810 concerning metrics. I think there's some potential design-informing between the two. Possibly libusdt as a reporting sink for metrics?

Start by reading the earlier discussion in #6816 and the related metrics issue #6810, then review the linked DTrace, USDT, libusdt, and node-dtrace-provider references. The issue does not name files or tests; completion would require settling the scope and design for static and dynamic probes and identifying the standard-library actions to cover.