
Sysdig Inspect: A GUI for System Call Analysis - knoxa2511
https://sysdig.com/blog/sysdig-inspect/
======
joshbaptiste
Thanks to BPF devs and system folks like Brendan Gregg Linux tracing on the
4.x kernels can rival Solaris/FreeBSD + Dtrace. So my question is where does
Sysdig fit in the tracing equation here?

~~~
viraptor
Does Linux perf / bpf tracing allow dealing with userland these days? I wish I
could start reading info from live python and ruby like I can with dtrace, but
I haven't really seen a way to do that yet.

~~~
aseipp
Yes it does. You can use Userland Statically Defined Trace Points (USDTs) in
order to augment arbitrary applications with probe points that can be
monitored by tools like BCC 'trace'.

The library that provides the API for these trace points is SystemTap
(sys/sdt.h), which is -- AFAICS -- the primary method of USDT instrumenting on
Linux. Conveniently, SystemTap's USDT API is the exact same as DTrace's API:
you can simply use sprinkle `DTRACE_PROBEn` calls around and it will work fine
on either, use the 'dtrace' tool to generate code from a provider, etc etc.
Their dtrace tool is just a thin script that's compatible with the FreeBSD
variant.

(The nice part about this is that you _should_ just be able to relax e.g. your
autoconf checks from enabling DTRACE_PROBEn calls on FreeBSD/Solaris to
include Linux as well, so migration should be smooth)

Check out some info here[1].

Alternatively, for "simple" cases where you do not need provider support (e.g.
inputs to the trace points), if the executable just has enough symbol
information for function names, or the symbol names are exported _anyway_ ,
you can generally glean some relevant information. For example, the following
command uses the 'funclatency' tool to dump a latency histogram of every
function call to any function with the word 'poke' in its name, for the
application named 'app' in the CWD:

    
    
        sudo /usr/share/bcc/tools/funclatency -F -T \
          $(pwd)/app:*poke* \
          -p $(pidof app)
    

NB: It is also worth noting that 'perf' on Linux has some form of uprobes
support; e.g. it can probe functions based on the symbol name, but only for
the events/interfaces it has available, I believe.

[1] [http://blogs.microsoft.co.il/sasha/2016/03/30/usdt-probe-
sup...](http://blogs.microsoft.co.il/sasha/2016/03/30/usdt-probe-support-in-
bpfbcc/)

------
bastijn
Was fooled a moment into thinking you had no pricing information on your page.
Realized it was there but just not accessible via your menu. My advice, add
pricing to your menu. It is one of the first things I search on new products
before I try it. Should be accessible from any page in case a reader is
interested and wants to check if he can afford your tooling.

~~~
apurvadave
Sysdig Inspect is fully open source. [https://github.com/draios/sysdig-
inspect](https://github.com/draios/sysdig-inspect)

Sysdig's commercial security and monitoring products do have pricing pages
within the top navigation as well :
[https://sysdig.com/product/monitor/pricing/](https://sysdig.com/product/monitor/pricing/)

~~~
bastijn
Fooled twice :). I do not see pricing in the menu though. I indeed found the
page by browsing to another page but my first expectation was to literally
find “pricing” in the menu. That page could than start with the open source
pricing statement (free) followed by their payed options. Or that is what
these kind of products typically do.

~~~
apurvadave
Odd - I'll take a look at the navigation issue, and thanks for the feedback on
the open source pricing statement.

~~~
apurvadave
For some reason pricing isn’t showing up on the nav of the mobile site ,
whereas it does on desktop. Apologies for that. We’ll fix it shortly.

------
linedash
The main issue I've had is with the awful documentation. They give a good
chunk of examples - but I was unable to easily locate a simple listing of all
the different ways of referencing things.

For a tool like this; quality documentation really is a must. And it isn't.

------
canada_dry
Looks very interesting!

A quick scan of the docs, it looks like we can extend the filtering via LUA
("chisels"). No python love?

~~~
mmjaa
Wouldn't it be the case that adding Python won't deliver the performance
needed? I think the choice of Lua is probably because it has to be performant.

