degio

https://sysdig.com/

It's not Open Source, but the sysdig cloud dynamic topology map does pretty much what you describe https://sysdig.com/product/.

(Disclosure: I work at sysdig)

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.

(one of the authors here)

Yes, this currently emits to file or syslog and you need to take care of the alerting. Of course, this is the very initial release and we plan to improve it. If you have a specific need or idea, feel free to open an issue or let us know on the mailing list.

off topic but I think interesting: Andy Tanenbaum is also the creator and maintainer of http://www.electoral-vote.com/, which I find to be one of best resources on american elections.

Blog post author here.

Yes, when you drill down using the mouse you will get the relevant system calls, including the buffers if they are I/O reads and writes.

Also, sysdig and csysdig have pretty advanced system call capture and filtering functionality. See this link for an introduction https://github.com/draios/sysdig/wiki/Sysdig%20User%20Guide

by the way, I can find a million alternative cloud based photo services, all with comparable features. On the other hand, there are very few desktop picture managers, especially on windows and linux.

One of the tool authors here. The answer is "it depends". We absolutely designed sysdig and csysdig to work on production systems. They both work by capturing system events, so their cpu usage depends on the number of system calls in the system. On machines with average workloads, I would expect csysdig's CPU usage to be comparable or slighly lower than htop. On machines that do a lot I/O, the CPU will probably be higher. Memeory usage is typically some tens of megabytes.

sysdig(http://www.sysdig.org/)

winpcap(http://www.winpcap.org/)

Yes, I did pre-warm the volumes before using them.

And yes, there are several interesting workloads that I didn't test, including read only and read+write. It's potential material for another blog post.

OP here. Unfortunately the ansi palette is pretty limited so I didn't have a lot of flexibility in the color choice. That said, this can definitely be improved. I can work on it if people find it useful.

In the meantime, it's very easy to tune the colors your own: just modify this line https://github.com/draios/sysdig/blob/master/userspace/sysdi... in your local version of the script, using this as a reference http://misc.flogisoft.com/_media/bash/colors_format/256_colo....

I found reading these comments very interesting.

From one point of view, I'm thinking "why did coreos need to be so aggressive?", and "boy, what a gift Solomon Hykes did to coreos by mismanaging this thing so badly", and "man, all of these guys look sort of immature to me".

From the other point of view, I'm respecting docker and coreos even more, as open source projects and as a companies, because it feels like there are real people behind them.

If this is the new wave of enterprise companies, I really like it. These are people like us, that engage with us and sometimes screw up, without hiding it. They are doing great things, and the fact that they are a bit immature is actually great.

I'm an entrepreneur myself, I've done enterprise software my whole life, and I always thought it's a shame that companies in this space are so distant from their users and have such little humanity.

Looks like things are changing.

And this is the sonic boom visualized by Schlieren photography: http://youtu.be/lbomsOPSSII

So here's a question for the readers: would you rather live/work in the Berkeley/Oakland area or in the south bay?

It's interesting how most of the comments focus on the technical aspects of what the guy built.

What I found interesting and inspiring is the time and passion that he puts in what he does. I really hope to still have something that makes me so passionate when I will be 72. It's a great way to live your life.

I wish I had this list when I started programming in Lua.

How important do you guys think AWS certifications are? This is a world changing at such a fast pace that I doubt companies would really care?

I mean overall, so that includes kernel crashes.

Kernelwise, the main thing to report is a couple of crashes on non-mainline kernels like openVZ.

I'm one of of the sysdig creators. Sysdig is a pretty young project (we released it around a month ago), so I can't promise it will be flawless in a production environment. However, we've had many installations under several different environments, and during the month after the release we had extremely few crash reports, which we've worked to fix right away.

No, we don't use kprobes at this point, all of our collection is done through tracepoints. Take a look at https://github.com/draios/sysdig/blob/master/driver/main.c for details. They tend to be very efficient, which is a very important requirement because of our "capture all" approach. And no urace/uprobes support yet. We're considering it as a feature for the future.

Of course, we create and update the state by inspecting the incoming stream of system calls. We traverse proc only once, when you start a capture, and the reason to do that is collecting info for the PIDs/FDs that existed before we start the system call collection. That way, you can for example create a filter on the IP address of a socket even if that socket was created before sysdig started.

It looks like you don't have enough privileges to read /proc. Are you using this as root?

I guess it's early to tell, but if the kernel folks don't object we would be happy to work at including our driver in the kernel.

As you suggested, we've updated the README with the content above.

Brendan, thanks for the feedback. It's really cool to hear comments like this from someone like you. We really respect your work in the field.

Good catch on topprocs_file, we'll have to find a better name for it.

In terms of overhead, we put a lot of effort in it and, as you pointed out, we're already extremely optimized. But we think we can do even better. For example, we don't have any kind of kernel-level filtering yet. Coming soon! :)

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.

dtrace and any other instrumentation tool for linux require a kernel module as well. Ours has the advantage of being very simple and (in theory!) more stable, because decoding, filtering and scripting run at user level, so you have less chances to crash the kernel.

I would also like to point out that the sysdig workflow is quite different from the drace one. In addition to supporting real-time investigation, sysdig lets you take a rich "snapshot" of the machine activity that you can analyzer later. From this point of view, I don't think sysdig is less powerful than dtrace. Quite the opposite. But we're eager to know what you think.

You're right, you can use this:

https://s3.amazonaws.com/download.draios.com/stable/install-...

We'll update the page in a second

Thanks.

To answer the question "what it does and how", sysdig captures system calls and other system level events using a linux kernel facility called tracepoints, which means much less overhead than strace.

It then "packetizes" this information, so that you can save it into trace files and filter it, a bit like you would do with tcpdump. This makes it very flexible to explore what processes are doing.

We also pack it with a set of scripts that make it easier to extract useful information and do troubleshooting.

We decided to offer bash-piping to make it simpler, but it's actually nothing more than a clean deb/rpm package.

And you have the option to install it manually if you want https://github.com/draios/sysdig/wiki/How%20to%20Install%20S....