DTrace was recently featured on episode 35 of Geek Muse. DTrace was brought to their attention because of John Birrell’s recent work to port it to FreeBSD (nice work, John!). The plug was nice, but I did want to respond to a few things:
DTrace was referred to as “a scripting language for debugging”. While I can understand why one might get that impression, it’s kind of missing the point. DTrace, concisely, is a systemic observability framework that’s designed explicitly for use on mission-critical systems. It lets users and system administrators get concise answers to arbitrary questions. The scripting language aspect to DTrace lets you express those questions, but that’s really just a component. James Dickens took a stab at an all-encompassing definition of DTrace….
One of the podcasters said something to the effect of “I’m just a web developer…” One of the great things about DTrace is that it has uses for developers at almost any layer of the stack. Initially DTrace could only view the kernel, and C and C++ code, but its release in Solaris 10 well over a year ago, DTrace has been extended to Java, Ruby, php, python, perl, and a handful of other dynamic languages that folks who are “just web developers” tend to use. In addition to being able to understand how your own code works, you’ll be able to see how it interacts with every level of the system all the way down to things like disk I/O and the CPU scheduler.
Shortly after that, someone opined “I could use it for looking at XML-RPC communication”. For sure! DTrace is crazy useful for understanding communication between processes, and in particular for XML-RPC for viewing calls and replies quickly and easily.
At one point they also identified the need to make sure users can’t use DTrace to spy on each other. By default, DTrace is only executable by the root user. System administrators can dole out various levels of DTrace privilege to users as desired. Check out the manual — and the security chapter in particular.