13.1 Choosing the Probe Points

DTrace enables developers to embed static probe points in application code, including both complete applications and shared libraries. You can enable these probes wherever the application or library is running, either in development or 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 that is submitting a request and the web server that is responding to the 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 can 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. For example, will the 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 discusses how these decisions can guide your static tracing definitions.