[lttng-dev] announcing: lttng and ruby!

[Chris Riddoch]

Hi, folks.

I've been making tools to work with lttng-ust in the ruby ecosystem,
and I've just put some of the results of this work on github.

First, I've instrumented the ruby interpreter with lttng tracepoints,
which can be built with --enable-lttng and currently exist alongside
the existing dtrace probes.  I'm still working on the code that will
generate the tracepoints for each instruction in the virtual machine,
but it's already possible to identify useful information with it:
method calls and returns involving the C api, object creation, string
creation, a variety of other useful things.  Before trying to get this
merged into upstream ruby, I want to unify ruby's interfaces to
tracing libraries, so that a tracepoint calls will expand at compile
time to either dtrace or lttng instrumentation based on compile-time
selections. Qemu does something like this, and I've looked to its for
ideas on implementing it.

My current work on that is at
https://github.com/riddochc/ruby/tree/ruby-2.3-lttng

For application-level tracing, I've also written a ruby gem for users
who don't care to have the whole interpreter built for tracing at the
same time.  It provides an API similar enough to the built-in Logging
class that I've been able to send everything logged in a Rails website
to lttng.  In addition to that, combining this with ruby's built-in
library-level (quite slow) tracing, allows all the data from that API
to be recorded through lttng.  (At the moment, I need to fix the gem's
build process, but that shouldn't take me long.)

My work on that can be found here: https://github.com/riddochc/lttng-agent-ruby

I'm also interested in tooling like the python interface to
babeltrace's CTF parser, and being able to process generated CTF in
ruby as well. I've been studying the babeltrace API towards that goal.

I look forward to hearing your thoughts on these projects!

-- 
Chris Riddoch
http://www.syntacticsugar.org/