On DTrace envy

Posted Aug 7, 2007 22:51 UTC (Tue) by bgregg (guest, #46639)
Parent article: On DTrace envy

Great article. I have some points to add from by background as a customer using DTrace, writing most of the scripts in the DTraceToolkit, and more recently joining Sun.

making this tool usable by a much wider set of system administrators

This is also important with DTrace, which I've helped encourage by creating a collection of scripts called the DTraceToolkit DTraceToolkit (inspired by the SE Toolkit), which also contains man pages, example files, notes, and a list of one-liners. It would be great if regular sysadmins wrote their own scripts, but if they don't have the time or skill to do that, then using the DTraceToolkit is better than not using DTrace. People can also use the scripts and one-liners in the toolkit as examples from which to learn DTrace.

Another way to reach a larger audience for DTrace is the DTrace Topics wiki, where I hope to write documentation specific to different roles (sysadmin, DBA, etc). This is in addition to the Dynamic Tracing Guide on docs.sun.com, which (DTrace aside) is an example of outstanding technical documentation.

SystemTap's language, instead, has conditionals, loops, and the ability to define functions.

Loops keep being mentioned as a feature of SystemTap's language, perhaps as it's a well known programming construct from other languages. If you write a few hundred DTrace scripts, you'll discover that loops aren't actually that important - perhaps 1 in 40 scripts that I write I think that loops would be nice, then use a workaround. If they did become more important, I imagine they could be added after carefully addressing safety concerns.

As for functions: again, sounds nice, but write a few hundred DTrace programs and note how many times you wanted them. Most DTrace scripts are short, a dozen lines or so; and the DTrace providers make concise abstractions available that shouldn't need too much digging to get to what you want (such as needing functions or loops). There are also workarounds for functions, such as using #defines.

So not having loops or functions would, for other languages, be a big deal. It isn't really the case here, at least in my experience.

DTrace has the ability to work with user-space probes.

This is a big deal; it is allowing providers to be created for languages such as Java, JavaScript, Ruby, Python, etc, and is what makes DTrace complete. DTrace is about observing your application as it runs and interacts with the system libraries, syscalls, kernel and device drivers - the entire software stack. This means if a customer has a performance issue, almost anywhere, DTrace can find it. This is the miracle solution to performance disputes - the application developers, database vendor and os vendor can all use the same tool and see the same numbers.

A while back I wrote a JavaScript DTrace provider, and now with much help from engineers at both Sun and Mozilla, we are looking at how best this could be made a permanent part of Mozilla. Great for JavaScript developers on either Solaris or MacOS, and Linux too - if it ports DTrace.