Dtrace Review

Similar experience here, except that I've solved similar issues (and far more complicated issues) with DTrace instead of strace. The range of information that DTrace can retrieve about a running application surpasses anything that strace can retrieve. DTrace can retrieve information on a systemic scale, whereas each strace instance operates on a single process. And the overhead is significantly lower with DTrace. For many of the systems applications I design for Illumos, I've used DTrace probes as a way of logging very frequent events, on demand (to avoid frequent IO). All of the events that _must_ be logged for the application to function properly, are logged and fsync'd. I think that in most systems dynamic tracing will eventually replace a significant portion of the logging functionality that people code into their applications. Either way, if you think strace is sweet, give DTrace a spin. Some helpful links: [0] A video demostration of DTrace, by the creator of DTrace. [0] [this video] [1] A post I wrote, demonstrating DTrace. Similar posts can be found on the blog's dtrace-addict page. [1] [link] [2] A wiki that contains DTrace examples for various languages and system facilities. Some examples may be Illumos-centric. [2] [link] [3] DTrace's home. Contains blogs by the engineers behind DTrace. [3] [link] UPDATE: Meant to reply to parent's parent.

> Does anyone have any inside knowledge of when, if ever, DTrace might become a standard/official part of Linux? Never. Due to dtrace being licensed under the CDDL it will never be mainlined into the upstream kernel. I would be keen to point out this does not mean there is a conflict of licenses from a legal point of view. Before anyone starts making claims like "you're not allowed to do this", see the use of the ZFS kernel module in recent releases of Ubuntu. I shall say no more on the matter as a refuse to be drawn into a licensing debate... Getting back on topic, those seeking more on user space providers should check out this video from Bryan Cantrill. [this video] Full disclosure I never had to run Solaris in production so I can look back on Sun with rose tinted glasses. That said I still long for many of the features it pioneered. Seriously ZFS would eliminate half of my production problems and dtrace would make the remaining half solvable.

That sounds very believable and would have slowed commercial SPARC users from switching to whitebox x86, likely intentionally, but would have had no relevance to startups and the rapid onslaught of hyperscalers. A video that amuses me with respect to engineering culture and organization blindness is Cantrill doing a DTrace demo at Google in 2007 [this video] . The audience seems completely unaware about the significance of what they are seeing. The length of time between Linux getting cogent tracing support is telling. GOOG could have single-handedly propped up an extra-Sun OpenSolaris community, and there would have been nice symbiosis considering their early container usage and how long that took to grow as well.

> Code, on the other hand, is a social constrution but entirely confined in an abstract and mathematical world. Brian Cantrill had a good observation in a 2007 Google TechTalk introducing Dtrace: > In software the blueprints are the machine. In software once you design the thing you've built it: the design is the machine. That's why the waterfall model is so fundamentally flawed. This idea that you could design the design before you design it, which is what the waterfall model is essentially saying, is flawed. Software is both, it's both information and machine. (@3m40s) * [this video] I originally ran across it on Google Video: * [link]