Choosing the Probe Points

DTrace allows developers to embed static probe points in application code, including both
complete applications and shared libraries. These probes can be enabled wherever the application
or library is running, either in development or in production. You should define
probes that have a semantic meaning that is readily understood by your DTrace
user community. For example, you could define query-receive and query-respond probes for a web
server that correspond to a client submitting a request and the web server
responding to that request. These example probes are easily understood by most DTrace
users and correspond to the highest level abstractions for the application, rather than
lower level implementation details. DTrace users might use these probes to understand the
time distribution of requests. If your query-receive probe presented the URL request strings as
an argument, a DTrace user could determine which requests were generating the most
disk I/O by combining this probe with the io provider.

You should also consider the stability of the abstractions you describe when choosing
probe names and locations. Will this probe persist in future releases of the
application, even if the implementation changes? Does the probe make sense on all
system architectures or is it specific to a particular instruction set? This chapter
will discuss the details of how these decisions guide your static tracing definitions.