I''m interested to know if there''s any programmatic interface to DTrace so an application could control dtrace probes and receive the raw data in a form it could easily use? It seems all the existing work is on human-oriented interfaces involving writing scripts to do ad-hoc system management and getting back text reports. I''m interested in having a program be able to use dtrace to supplement its own profiling informationi with information about system events caused by various states. So for example a database could supplement each node in its plan tree with how many physical versus logical i/o that plan node generated and how much time was spent in each node in system wait versus cpu. Currently that kind of data is not available unless the application is doing all the i/o scheduling itself. -- This message posted from opensolaris.org
On Wed, Sep 26, 2007 at 03:01:37PM -0700, Greg wrote:> I''m interested to know if there''s any programmatic interface to DTrace so an application could control dtrace probes and receive the raw data in a form it could easily use?There is a such an interface, with two language bindings: an undocumented (but well-established) C interface (libdtrace), and a documented JNI interface (see http://www.opensolaris.org/os/project/dtrace-chime/java_dtrace_api/). If you''re interested in the former, consult the source for either dtrace(1M) (usr/src/cmd/dtrace/dtrace.c) or a simpler consumer like intrstat(1M) (usr/src/cmd/intrstat/intrstat.c) -- with our apologies for the fact that it isn''t documented. - Bryan -------------------------------------------------------------------------- Bryan Cantrill, Solaris Kernel Development. http://blogs.sun.com/bmc
On Wed, Sep 26, 2007 at 03:25:11PM -0700, Bryan Cantrill wrote:> There is a such an interface, with two language bindings: an undocumented > (but well-established) C interface (libdtrace), and a documented JNI interface > (see http://www.opensolaris.org/os/project/dtrace-chime/java_dtrace_api/).It''s worth noting here that the former, undocumented interface is classified as Private meaning that future builds may cause consumers to malfunction; the latter, documented interface is classied as Evolving which means that incompatibilities would be unlikely. (to the PSARC police: apologies for the excessively comprehensible simplifications of stability taxonomies.) Adam -- Adam Leventhal, FishWorks http://blogs.sun.com/ahl
>>I''m interested to know if there''s any programmatic interface to DTrace so an application could control dtrace probes and receive the raw data in a form it could easily use? >> > >There is a such an interface, with two language bindings: an undocumented >(but well-established) C interface (libdtrace), and a documented JNI interface >(see http://www.opensolaris.org/os/project/dtrace-chime/java_dtrace_api/). >If you''re interested in the former, consult the source for either >dtrace(1M) (usr/src/cmd/dtrace/dtrace.c) or a simpler consumer like >intrstat(1M) (usr/src/cmd/intrstat/intrstat.c) -- with our apologies for >the fact that it isn''t documented. >Tom Erickson wrote a nice blog entry on some aspects of using libdtrace and it''s well worth a read: http://blogs.sun.com/tomee/date/20050614 Jon.
Bryan Cantrill wrote:> On Wed, Sep 26, 2007 at 03:01:37PM -0700, Greg wrote: >> I''m interested to know if there''s any programmatic interface to DTrace >> so an application could control dtrace probes and receive the raw data >> in a form it could easily use? > > There is a such an interface, with two language bindings: an undocumented > (but well-established) C interface (libdtrace), and a documented JNI interface > (see http://www.opensolaris.org/os/project/dtrace-chime/java_dtrace_api/). > If you''re interested in the former, consult the source for either > dtrace(1M) (usr/src/cmd/dtrace/dtrace.c) or a simpler consumer like > intrstat(1M) (usr/src/cmd/intrstat/intrstat.c) -- with our apologies for > the fact that it isn''t documented.Hi Bryan, How stable is libdtrace? James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems
> >> I''m interested to know if there''s any programmatic interface to DTrace > >> so an application could control dtrace probes and receive the raw data > >> in a form it could easily use? > > > > There is a such an interface, with two language bindings: an undocumented > > (but well-established) C interface (libdtrace), and a documented JNI interface > > (see http://www.opensolaris.org/os/project/dtrace-chime/java_dtrace_api/). > > If you''re interested in the former, consult the source for either > > dtrace(1M) (usr/src/cmd/dtrace/dtrace.c) or a simpler consumer like > > intrstat(1M) (usr/src/cmd/intrstat/intrstat.c) -- with our apologies for > > the fact that it isn''t documented. > > > Hi Bryan, > How stable is libdtrace?(For people who are not familiar with Sun''s interface nomenclature: James''s question is about interface stability not functional stability.) As Adam said, it''s a Private interface, so it can change at any time. But as a practical matter, I don''t think it''s going to change much, at least for the foreseeable future -- and almost certainly not in a way that breaks existing consumers: we''re more in a mode of building on DTrace than working directly on it. That''s part of the reason that I call it "well-established" -- conveniently skirting interface taxonomy while still relating that it''s not undergoing radical change. And just to reiterate the point that Jon made: Tom has a terrific blog entry on libdtrace at http://blogs.sun.com/tomee/date/20050614: I think that that blog entry is pretty much the documentation... ;) - Bryan -------------------------------------------------------------------------- Bryan Cantrill, Solaris Kernel Development. http://blogs.sun.com/bmc
Bryan Cantrill writes:> As Adam said, it''s a Private interface, so it can change at any time. > But as a practical matter, I don''t think it''s going to change much, at > least for the foreseeable future -- and almost certainly not in a way that > breaks existing consumers: we''re more in a mode of building on DTraceIn that case, it sounds like raising the advertised stability level ''soon'' might be a good thing to do. You could go with "Uncommitted" as an improvement over "Project Private," and not necessarily spend any time getting man pages written.> And just to reiterate the point that Jon made: Tom has a terrific blog > entry on libdtrace at http://blogs.sun.com/tomee/date/20050614: I > think that that blog entry is pretty much the documentation... ;)Converting that blog entry into a man page entry (cut-n-paste into bugster, and file an RFE) sounds like one of the steps on the journey to me. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677