DTrace is meant for sysadmins (and developers, so they say, as if I am going to give them my root role) and service personnel who want to interrogate the system to better understand the OS behavior and the userland programs. There is no use re-counting the power of Dtrace here. (I leave it to the reader to know what google is and how to use dtrace as a search term in an exercise.)
ONTAP is an OS by NetApp, for NetApp filers (more on that on a later post). It’s underlying fs, WAFL, is designed to meet a specific set of requirements (fast NFS, large fs, low RAID overhead and fast restarts). Obviously it gained a few pounds here and there (CIFS, FC, iSCSI, De-duplication, Snap mirrors etc). Even database applications on NAS are now a reality (*shudders*), owing a large part to NetApp.
We already see the NetApp filers being used in data centers for a wide variety of purposes. This can only mean that the system integrators, administrators and application developers will need to rely on accurate, fast, real-time metrics from the OS. The ability to ask an operating system some arbitrary questions and recieve accurate answers should not and must not be an after thought – not when the tools are already available in the market. It should come as a second nature – like a shell prompt.
Porting DTrace to ONTAP and having it available (may be under “priv set dtrace”) makes sense. Besides the obvious and drooling use of dtrace by the sysadmins, an optional Dtrace toolkit can be incorporated as part of an autosupport mechanism – not only to provide tech support with critical information but also to provide the additional umph to the Martini reports. Oh yea – and to the sales team as to when they can start calling you with “You need more filers and I can prove it” sort of calls.
You could give your developers the appropriate privileges (dtrace_kernel, dtrace_proc, dtrace_user) and that would remove the need to let them know your root password.
And yes, I totally agree that ONTAP needs to have DTrace.