DTrace en Ubuntu, ¿cómo hacerlo?

Como autor de dtrace4linux, déjame responder.

En esencia, dtrace en Linux/macOS/FreeBSD/Solaris es el mismo - todos estamos basados en el mismo código fuente con los mismos objetivos. Debido a que no hay mantenedor central, los códigos son efectivamente bifurcaciones, con Solaris siendo considerado el maestro. La principal diferencia de código fuente es el pegamento para cada plataforma.

DTrace es una combinación de varias cosas:

• controlador del núcleo
• espacio de usuario " dtrace" command
• mecanismos de función de sonda (por ejemplo, syscall, fbt)
• lenguaje de scripting

Mira el seguimiento de syscall es bastante sencillo:

$ dtrace -n syscall::open:
.....

Esto atrapa cada llamada abierta al sistema, sin importar quién la ejecutó. Si conoces Unix, sabes que la llamada de sistema es aproximadamente:

open(char *filename, int flags, [int perms])

Entonces, arg0 es la cadena "filename". Pero aquí es donde las cosas difieren. La función C lib es la anterior, pero esto se asigna a una llamada al sistema, que es algo así como:

open(int someflags, char *filename, int userflags, int perms)

Así que el nombre del archivo no está en arg0, sino en arg1. (Disculpas si lo anterior es incorrecto - creo que open() es lo mismo en el núcleo y el espacio de usuario, pero esto no es cierto, por ejemplo, para la familia de funciones stat()).

Aquí es donde surgen algunos de los problemas de "portabilidad" de DTrace: si usa una guía de Solaris para dtrace, y trata de ejecutar algunos de los scripts o ejemplos, puede que encuentre que no funcionan igual. En teoría, esto es culpa de Linux (mi), y dtrace4linux debe ser modificado a esconde esto.

Eso se aplica a las llamadas de sistema.

Ahora veamos fbt. Fbt es solo un seguimiento de funciones, cualquier función, con cualquier parámetro. Puede rastrear la función linux que implementa la llamada open() syscall (se llama sys_open [posiblemente]). Si atrapa esta función:

$ dtrace -n fbt::sys_open:

Entonces tienes que mirar el código fuente del kernel para ver qué es arg0, arg1, arg2, etc. Y es casi seguro que es diferente a Solaris o macOS-su detalle de implementación de Linux.

Pero es posible que desee acceder a algún argumento, por ejemplo, para obtener alguna estructura de datos interna del núcleo (TCP, controlador de disco, controlador USB, etc.). Solaris proporciona " proveedores "que son formas de mayor nivel para acceder a estructuras de datos que sabiendo que "arg3 es una 'estructura foo*'". Sin estos proveedores, los scripts serían totalmente dependientes de opsys y sin portabilidad. A la mayoría de las personas no les importa cómo se ve una estructura "tcp", pero quieren acceso a campos clave como pktin, pktout, rcvbytes, sndbytes.

En resumen dtrace4linux y Solaris dtrace proporciona una capa de portabilidad para permitir el acceso a estas características o estructuras, pero ni dtrace4linux ni Solaris intentan hacer un trabajo completo para proporcionar portabilidad a través de las miles de estructuras en cada núcleo.

En general, puede tomar scripts de tutorial de solaris y usarlos para tratar de entender lo que no funciona, pero intentar usarlos 'tal cual' lo frustrará si no sabe qué buscar.

Considero dtrace4linux como "no está mal" y "no es lo suficientemente bueno" para ocultar estas diferencias. (dtrace4linux está a la par con macOS - si usa los tutoriales de Solaris, algunos pueden no funcionar en Mac o FreeBSD).