DTrace Hangout 05 January 2017
Notes kindly taken and forwarded by Domagoj Stolfa
- Attended by James, Samuel and Domagoj.
- We've mainly discussed the probe matching code, as I am experimenting with hashes to match which DTrace probe needs to be fired from the probe context, as well as the proposed architecture of the in-kernel distributed DTrace operation.
- One of the things that was discussed was bulk-transfering data from probes, bulk probe creation in the case of remote servers, as well as different things such as dynamic probe creation(in the sense that an instance might advertise it's probes to the host, and the host probes that are currently being traced match the advertised ones).
Example:
# dtrace -n 'vm-db-[0-9]*:syscall:::entry/execname == "postgresql"/'
matches vm-db-0, vm-db-1.
Somewhere in the future, one creates a new virtual machine, vm-db-2, which then advertises it's probes towards the host. DTrace should match those probes, too.
- James suggested that there might be a way to filter the probes that would be fired back to the host DTrace and explored an initial possiblity of using speculative tracing for such a purpose.
- Additionally, some security aspects were discussed, such as leakage of information and how things are handled in the kernel.
- Samuel suggested stress testing the implementation to ensure there are no edgecases where it would panic the system, as well as perhaps coming up with a way of handling which providers would be advertised towards the host(perhaps only advertising a provider and it's probes when they're actually needed?).
- Another thing that was discussed was the possiblity of having an easy way of creating(perhaps it exists?) running DTrace at boot and having it commit the script results in the file.