sysdig: kernel-level system visibility that understands containers

What sysdig replaces, and who ends up using it

The README makes the problem statement directly: system-level monitoring and troubleshooting still involves logging into a machine over SSH and using a set of dated tools with inconsistent interfaces, and many of those classic tools break down in containerized environments. sysdig unites the Linux toolkit into one interface. The README describes the tool as "strace + tcpdump + htop + iftop + lsof + ...awesome sauce", which is a fair summary of the scope: process tracing, packet capture, resource views and open-file inspection behind one command and one filter language.

The audience is narrower than that slogan suggests. sysdig installs into the Linux kernel and captures system calls and other OS events, so it is for people who own the host or at least have the privileges to load a kernel module on it. The container support is the differentiator the README leans on: inspection happens without instrumenting the containers themselves, so a workload you did not build and cannot modify is still observable from the outside. Platform teams debugging a misbehaving pod, SREs chasing a syscall that only fails under load, and security engineers looking at process and file activity on a node are the natural users. Someone who wants an application-level profiler, or who works exclusively on macOS or Windows hosts, is not.

The architecture: a kernel module feeding a userspace capture and filter engine

The mechanism is stated plainly in the README: sysdig instruments physical and virtual machines at the OS level by installing into the Linux kernel and capturing system calls and other OS events. The repository layout reflects the split. The userspace/ directory holds the userspace programs, and the top level carries CMakeLists.txt plus a cmake/ directory, so the build is CMake-driven. There is a docker/ directory for container packaging, scripts/ for build and packaging helpers, and a test/ directory alongside CMakeListsGtestInclude.cmake, which indicates GoogleTest-based tests.

The design decision worth noting is the trace file. sysdig can write system activity to trace files in the same way tcpdump and Wireshark do for networks, so a problem can be analyzed later without losing information. The README adds that rich system state is stored in the trace files, so captured activity can be put into full context. That is a real architectural commitment: the capture path has to record enough surrounding state (process, container, file descriptors, user) that a later reader can reconstruct what happened, and it means the cost of capture is paid in disk and I/O rather than only in CPU on the live path. It also means a trace is a portable artifact you can hand to a colleague or attach to an incident write-up, which is not true of a live top-style view.

The container awareness is not a separate agent. Because events are captured at the kernel boundary, the container a process belongs to is visible from the event stream itself. That is why the README can claim deep inspection into containers without instrumenting them. The trade-off is the usual one for kernel-level tooling: you see everything, including things you did not ask for, and the filter language becomes the thing you actually have to learn.

Installing sysdig and running a first capture

The README gives two paths. The first is a container, which is the fastest way to try it and the one shown in the README. The second is a deb or rpm package from the latest release for your distribution, with the install wiki linked for details. The container invocation is long because sysdig needs broad access to the host, and the README is explicit about the flags and mounts:

sudo docker run --rm -i -t --privileged --net=host \
    -v /var/run/docker.sock:/host/var/run/docker.sock \
    -v /dev:/host/dev \
    -v /proc:/host/proc:ro \
    -v /boot:/host/boot:ro \
    -v /src:/src \
    -v /lib/modules:/host/lib/modules:ro \
    -v /usr:/host/usr:ro \
    -v /etc:/host/etc:ro \
    docker.io/sysdig/sysdig

After the container starts you get a shell, and the README says to run the sysdig or csysdig tool from the container shell. So the first real use is simply starting the interactive UI:

csysdig

csysdig is described as a simple, intuitive and fully customizable curses UI for sysdig. Expect a terminal interface with views you can switch between, not a command that prints and exits. The README links a video introduction to csysdig if you want to see the views before installing anything.

If you prefer the command line, the README's own headline example is the bare invocation, which starts a live capture:

sysdig

For the package route, download the deb or rpm for your distribution from the latest release and install it with your normal package tooling. The README does not document the exact package names, so check the install wiki before scripting an unattended install. Whatever route you take, the privileges are the same: the container path uses --privileged and mounts /dev, /proc, /boot, /lib/modules, /usr and /etc from the host, which tells you what the tool expects to read.

Where sysdig is the wrong tool

The kernel dependency is the first failure mode. sysdig installs into the Linux kernel, so a host where you cannot load modules, a managed Kubernetes node with a locked-down kernel, or a distribution the module does not build against will stop you before you capture anything. The README does not document a fallback for that case, and it does not document rollback of the kernel component either. If your environment forbids kernel modules by policy, this is not the tool for the job regardless of how good the interface is.

The privilege model is the second constraint. The documented container invocation uses --privileged and --net=host and mounts host /dev, /proc, /boot, /lib/modules, /usr and /etc. That is a lot of host surface for a debugging tool, and it is not something you leave running as a permanent service on a shared cluster without thinking about who can reach that container. The README presents this as the getting-started path, not as a hardened deployment recipe.

The third case is scope. sysdig captures system calls and OS events. If the question is why a function is slow inside your application, a profiler answers it more directly. If the question is why a request is slow across five services, distributed tracing answers it more directly. sysdig is strongest when the answer lives in the kernel boundary: a file that cannot be opened, a process that keeps respawning, a container reaching a socket it should not. The README also points anyone who wants a fully supported, fully distributed version at Sysdig Monitor, which is an admission that the open source tool is a single-host instrument, not a fleet product.

How it compares with eBPF-based tracers

The obvious alternative in the same problem space is an eBPF-based tracer, and the difference is architectural rather than cosmetic. sysdig's README describes installing into the Linux kernel and capturing system calls and other OS events, with trace files as a first-class output. An eBPF tracer loads programs into the kernel at runtime and, in the common case, streams aggregated events to userspace rather than writing a full capture to disk.

That changes what you can do after the fact. sysdig's trace file model means you can capture on a production host during an incident and analyze the file later, with the surrounding system state preserved. An eBPF tracer that emits only aggregates gives you the aggregate and nothing to re-query. The counterpoint is operational: eBPF programs are verified by the kernel before they load, which constrains what they can do but also avoids shipping a separate kernel module that has to be rebuilt for each kernel version. sysdig's module approach is the older model and carries that maintenance cost.

The README does not benchmark either approach. The practical question is whether you need a replayable capture. If you do, the trace file is the reason to pick sysdig. If you need a lightweight always-on agent with no module to build, an eBPF tracer fits better. Note also that the same vendor maintains Falco, an eBPF-era project in the same family, so the two approaches coexist rather than one replacing the other.

Maintenance, licensing and what a fork costs you

The repository is not archived, and the last push was on 2026-04-13. The most recent release listed is 0.41.4 on 2026-01-29, preceded by 0.41.3 on 2025-12-10 and 0.41.2 on 2025-12-03. The version numbering and the release cadence are the concrete maintenance signal here; the README itself says nothing about a support window or a release policy.

On licensing, the README states that the sysdig userspace programs and supporting code are licensed under the Apache 2.0 open source license, and the repository root carries a COPYING file. The repository metadata reports the licence as NOASSERTION, which is a classifier result rather than a statement by the project, so the README and COPYING are the sources to read. Apache 2.0 covers the userspace code. The README does not address the kernel module's licence in the text available here, and the top level does carry a NOTICES file, so read COPYING and NOTICES together before you redistribute anything or ship it inside a product. This is a description of what the files say, not legal advice.

Contributions come with a process cost. The README requires the Developer Certificate of Origin: every commit in a pull request needs a Signed-off-by line with your real name, and the README explicitly rejects pseudonyms or anonymous contributions. You can add it manually or use -s or --signoff on git commit, and if you forget, git commit --amend -s followed by git push -f fixes it. If you plan to run a patched fork rather than upstream your changes, you avoid the DCO entirely, but you then own the kernel module rebuild for every kernel your fleet runs. That is the real upgrade cost of this project, and it is paid in build engineering rather than in licence fees.

Editorial conclusion

Adopt sysdig when you need kernel-level syscall and container visibility on a Linux host you control, and when the ability to save a trace file for later analysis matters. Do not adopt it if you cannot load a kernel module, if you need a supported product with a vendor SLA, or if you only want a UI: the README points at Sysdig Monitor for the fully supported, fully distributed version. Verify first that your kernel and distribution combination is covered by the install wiki, that you can run the container with --privileged and the /dev, /proc, /boot, /lib/modules, /usr and /etc mounts the README lists, and that your team is comfortable with the DCO sign-off requirement if you intend to send patches back.

Frequently asked questions

Official sources

1. draios/sysdig on GitHub
2. Issues
3. Project website
4. README
5. Releases