The design is actually quite different.

From the architectural point of view, sysdig is closer to tcpdump/wireshark than to systemtap/ktap.

systemtap/ktap work similarly to dtrace: - a script is loaded into a user level process - the process compiles the script and dispatches it to a kernel module - the kernel module hooks the script into specific places in the kernel - the kernel module sends the results back to userspace where the user can see them

sysdig works this way: - the kernel module hooks into specific places in the kernel (using tracepoints), captures everything, and puts it into a shared memory buffer - the buffer is accessed from the user-level sysdig process that reconstructs state (so it knows that fd 23 means /etc/passwd) - filtering is applied - scripting in Lua is applied - the whole thing is optionally saved to disk so you can analyze later

Both approaches have pros and cons. We think that the sysdig approach creates a more natural workflow, ideal for troubleshooting and system administration tasks. Plus, writing scripts in Lua, with access to its rich libraries, is quite fun. :)

I want to give more details in a future blog post, so stay tuned.