c0t0d0s0.org

Ben Rockwood shows in the blog of his company, how dtrace can help you to find bottlenecks in a fast an efficient manner: DTrace, MySQL, Ganglia, and Digging for Solutions.

I found two really interesting interesting presentation. At first Brent Paulson wrote an really interesting presentation about practical Opensolaris Security. It´s a good overview about the possibilities of Solaris to increase the level of security at your installation. Ben Rockwood of cuddletech.com wrote an good preso about the usage of dtrace in conjunction with mysql.

On the foundations of Dtrace the security specialists Tiller Beauchamp and David Weston created a tool for finding vulnerabilties in your code (or writting exploits, depends on your objectives). It uses the mechanisms of DTrace and extends them. As Internetnews writes in Blackhat: Dtrace a Rootkit:.

Sun's Dtrace application was developed primarily as a tool to help monitor functions on Solaris. According to a pair of security researchers at the Black Hat conference, you can also use Dtrace as the basis for a rootkit-like tool for offensive and defensive security operations.

Finding vulnerabilties and writting exploits are different sides of a special case of debugging code. And debugging is exactly the job, we´ve developed dtrace for. It was really obvious, that someone will use dtrace for such an usecase.

Adam Leventhal made an interesting observation while using Dtrace on Mac OS X and wrote about his findings in"Mac OS X and the missing probes". According to this articles, Apple do not allow the dtrace-ing of all processes. Whenever a process has the flag "P_LNOATTACH" you can´t look into it with dtrace.

Perhaps, they are in fear of disabling or examination of certain DRM functions for example. It leaves a very bad aftertaste. But as Darran Moffat wrote in the comments: "Now we just need a port of mdb so that the proc flags can be changed ."

After Solaris, NetBSD and MacOS there is a fourth operating capable of Dtrace: QNX Neutrino, a real time operating system with vast similarities to unix. In I trace, you trace … what about dtrace? a first prototype implementation of dtrace in QNX was announced by the both developers of the port.

My coworker Dirk Wriedt had some problems with an application at a customer site. Dtrace told him soon, that the application used some libary call in an incorrect way. Normally you would wait some days for a patch for the application. But DTrace can do more for you: dtrace in destructive mode: working around a non-working syscall. Well, it´s certainly a nasty hack from the "don´t do this at home"-department, but ... well ... it seemed to work and it saved the progress of the project until the patch was available.

John Rice describes one of the more advanced techniques with dtrace: DTrace: digging into exec'd comand line args. Really usefull, when you try to find out, what the heck this %§$"$"§ ... fscking program executes and why it doesn´t run.

You should read the blog entry of to read the perception of one of the DTrace developers regarding the relationship of DTrace and Systemtap. But i really think the whole issue opens up the view to a different problem inside of Linux: The "not invented here (NIH)" problem. Linux isn´t immune to that problem.

Andrew Leventhal and Brendan Gregg gave an interesting presentation how DTrace can help you to find nasty performance problems in your software (and how dtrace helped Twitter to find performance problems).

There is an additional provider for monitoring your system: The DTrace provider for iSCSI.You will find a nice bunch of D scripts at the Solaris Internals Wiki, ranging from iSCSI snoop to measuring latencies in iSCSI operations

Joyent published their integration of Dtrace into Ruby and Rails. It´s a handy tool when you optimize your Rails application.

Nice piece about the usage of Dtrace in software development: DTrace and Java: Exposing Performance Problems That Once Were Hidden

Binu Jose Philip describes in his blog a patch for Python to enable dtracing your python scripts.

Ja, ich habe mich auch in der ersten Sekunde gefragt, wofür man eine dtrace/JavaScript-Integration braucht. Wenn man aber überlegt, wo mittlerweile überall Javascript verwendung findet (AJAX, ...) dann bekommt das ganze plötzlich einen sehr grossen Sinn.

Jürgen weisst in seinem Weblog auf einen Artikel bei pro-Linux hin: "DTrace mit Innovationspreis ausgezeichnet
" hin. Am interessantesten ist allerdings folgender Abschnitt:

Da DTrace unter der CDDL steht, ist eine Portierung auf den Linux-Kernel in naher Zukunft ausgeschlossen. Das Linux-Analog zu DTrace ist SystemTap. Es verwendet kprobes, das seit 2004 im Kernel enthalten ist, zur Messung. SystemTap selbst ist zwar eine Userspace-Anwendung, doch es compiliert die vom Benutzer erstellten Skripte in Kernel-Module, die zur Messung in den laufenden Kernel geladen werden. Fehler in den Skripten können das ganze System zum Absturz bringen, weshalb SystemTap auf Produktivsystemen kaum einsetzbar ist.

Wer mehr über den Vergleich von SystemTap und DTrace wissen möchte, sollte sich übrigens Comments to this Systemtap vs Dtrace comparison durchlesen.

PS: Besser als einer Kommentatoren des letzteren Kommentars kann man übrigens den Vergleich nicht zusammenfassen ... "A simple way of putting this is that the linux community have made some thing cool - and the Solaris team made some thing really useful!"