While dtrace is extremely robust, it is usually, in my case, not pulled up thanks to the level of expertness needed to really dig properly. This seems to really help welcome usage much more frequently and, with the OSX core / kernel team lagging as they have been for years, we really need additional instrumentation like this.
If I took a version of DTrace and removed about 95% of it's functionality, you'd have what sysdig currently does. It'd be a lot easier to learn, because there wouldn't be much to learn.
The sysdig command line style is promising, and it's exciting to see innovation in this space, but what's there right now is still give and take. Try writing a DTrace aggregation and a sysdig chisel side by side, to see what I mean. In many common cases sysdig is much more laborious to use right now.
More functionality can be added to sysdig (aggregations -- or chisel functions, thread local variables, tracepoints, kprobes, uprobes, PMCs, register inspection, kernel stacks, user stacks, user stack helpers, kernel filters and aggregations), allowing it to catch up to what DTrace can do, and solve the problems it can solve.
But I think comparing sysdig to DTrace is either wrong or premature. If sysdig isn't going to do those features I mentioned, then it's a different type of tool (nothing wrong with that), but it is misleading and unfair on itself to compare it to DTrace. If it is going to do those features -- and it just hasn't yet -- then why compare it to DTrace now? sysdig will be giving people a poor first impression, and again, it's unfair on itself.
