"First, events are captured in the kernel by a small driver, called sysdig-probe, which leverages a kernel facility called tracepoints."
That makes it sound like it's quite similar to the ftrace kernel tracer by instrumenting the various event tracepoints (/sys/kernel/debug/tracing/available_events) conveniently strewn throughout the kernel source--is this indeed the case?
Alternatively, is sysdig doing something differently? {k,u}probes? Sampling similar to, perhaps say, perf's capabilities?
The Linux tracing/profiling landscape is murky enough (littered with tools like SystemTap, LTTng, and so forth) and I'd like to know where this tool fits into an analysis work-flow--and more importantly, what's it's using (at a low-level) to gather data.
The tracing capabilities are then tuned for monitoring and troubleshooting. So keeping the overhead as low as possible and making it usable on production environments.
This is really cool, though it seems a bit silly to present such high-resolution data using a command-line interface. I guess it's easier to use over SSH?
I find it brilliant, personally. Users of sysdig tend to be sysadmin or devops with a strong *nix background, so the CLI sounds like 'from the comfort of your command line" to them.
I second the "From the comfort of your command line" feeling. I feel like many tools today are unnecessarily tied to a web browser, which makes for harsh context switching; and often worse usability. Sysdig is a killer product, and (crucial to me) is open source. I'm sure the cloud service is excellent as well.
I think the world missed an opportunity around about the '90s. Instead of evolving, command lines stagnated and got sidelined by terrible GUIs that are only now evolving to get out of people's way.
We should have developed command lines with graphics and hypertext. Thus you could do `ls` and double-click on one of the resulting files to open it. Browse the web with wget.
Of course users don't want to learn lots of commands. But notice how Windows 7 onwards and most linux desktops have a "fuzzy search" that really is a kind of command line.
There has been many attempts, but they've universally not gotten things "right enough" to gain much traction. E.g. Mozilla's XMLTerm [1] was one such experiment.
Anyways, if i am to speculate then GUI took over because of discoverability and ease of translation. A CLI is damn hard to translate. With a GUI you change the labels, and thats it. And finding something in a menu or similar was, before programs grew into massive behemoths, simpler than trying to guess what command, for most outside the english speaking world, named in a foreign language, to give to get something done.
Most people would just use X or VNC today, but I agree having more graphic integration reliably available in the shell is interesting.
Apart from various experimental support for new mechanisms in various terminal apps, there are two old formats that is supported reasonably widely: ReGIS [1] and Sixel [2]
The issue there is standards. How do your program talk to the kernel and hardware such that all this gets drawn? Especially in a modern multitasking environment, where no single binary, outside of the kernel, has complete control of the hardware.
Anyone else actually tried this? I was impressed with the video and thought I'd give it a stab, but the mouse drag to drill-down isn't working for me in 0.11.0.
author here. Please take a look at the solution proposed in this issue https://github.com/draios/sysdig/issues/599. If it doesn't work for you, feel free to comment in the issue.
From the home page sysdig "capture[s] system state and activity", but by leveraging specifically what?
From https://sysdig.com/blog/sysdig-vs-dtrace-vs-strace-a-technic...:
"First, events are captured in the kernel by a small driver, called sysdig-probe, which leverages a kernel facility called tracepoints."
That makes it sound like it's quite similar to the ftrace kernel tracer by instrumenting the various event tracepoints (/sys/kernel/debug/tracing/available_events) conveniently strewn throughout the kernel source--is this indeed the case?
Alternatively, is sysdig doing something differently? {k,u}probes? Sampling similar to, perhaps say, perf's capabilities?
The Linux tracing/profiling landscape is murky enough (littered with tools like SystemTap, LTTng, and so forth) and I'd like to know where this tool fits into an analysis work-flow--and more importantly, what's it's using (at a low-level) to gather data.
I'd appreciate any and all clarification.
Cheers.