HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
draios
sysdig
C++2014–2025
draios / sysdig

sysdig

Linux system exploration and troubleshooting tool with first class support for containers

18Distinct people
28Mentions
0Explicit recommenders
8.3KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Linux system exploration and troubleshooting tool with first class support for containers

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year28 dated mentions

Observed mentions: 2014-04-03 16:56:34 UTC to 2025-06-15 16:47:30 UTC.

02468102014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 10 mentions; 1 submissions, 9 comments20142015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 4 mentions; 2 submissions, 2 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 6 mentions; 2 submissions, 4 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2025

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC1019
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC422
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC624
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC110
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC101
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC202
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC000
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC101
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC101
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC000
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC000
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC202

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
sysdig Dig Deeper Sysdig is a universal system visibility tool with native support for containers: ~$ sysdig Csysdig is a simple, intuitive, and fully customizable curses UI for sysdig: ~$ csysdig Getting Started Run Sysdig in a container: 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 And then run the sysdig or csysdig tool from the container shell! Or install the latest release with a deb or rpm package for your distribution. What does sysdig do and why should I use it? Sysdig is a simple tool for deep system visibility, with native support for containers. The best way to understand sysdig is to try it - its super easy! Or here's a quick video introduction to csysdig, the simple, intuitive, and fully customizable curses-based UI for sysdig: https://www.youtube.com/watch?v=UJ4wVrbP-Q8 Far too often, system-level monitoring and troubleshooting still involves logging into a machine with SSH and using a plethora of dated tools with very inconsistent interfaces. And many of these classic Linux tools breakdown completely in containerized environments. Sysdig unites your Linux toolkit into a single, consistent, easy-to-use interface. And sysdig's unique architecture allows deep inspection into containers, right out of the box, without having to instrument the containers themselves in any way. Sysdig instruments your physical and virtual machines at the OS level by installing into the Linux kernel and capturing system calls and other OS events. Sysdig also makes it possible to create trace files for system activity, similarly to what you can do for networks with tools like tcpdump and Wireshark. This way, problems can be analyzed at a later time, without losing important information. Rich system state is stored in the trace files, so that the captured activity can be put into full context. Think about sysdig as strace + tcpdump + htop + iftop + lsof + ...awesome sauce. Documentation / Support Visit the wiki for full documentation on sysdig and its APIs. For support using sysdig, please contact the official mailing list. Join the Community Contact the official mailing list for support and to talk with other users Follow us on Twitter This is our blog. There are many like it, but this one is ours. Join our Public Slack channel for sysdig announcements and discussions. Our code of conduct applies across all our projects and community places. License Terms The sysdig userspace programs and supporting code are licensed to you under the Apache 2.0 open source license. Developer Certification of Origin (DCO) The Apache 2.0 license tells you what rights you have that are provided by the copyright holder. It is important that the contributor fully understands what rights they are licensing and agrees to them. Sometimes the copyright holder isn't the contributor, such as when the contributor is doing work on behalf of a company. To make a good faith effort to ensure these criteria are met, we require the Developer Certificate of Origin (DCO) process to be followed. The DCO is an attestation attached to every contribution made by every developer. In the commit message of the contribution, the developer simply adds a Signed-off-by statement and thereby agrees to the DCO, which you can find at http://developercertificate.org. DCO Sign-Off Methods The DCO requires a sign-off message in the following format appear on each commit in the pull request: Signed-off-by: John Doe <john.doe@sysdig.com> You have to use your real name (sorry, no pseudonyms or anonymous contributions). The DCO text can either be manually added to your commit body, or you can add either -s or --signoff to your usual git commit commands. If you are using the GitHub UI to make a change, you can add the sign-off message directly to the commit message when creating the pull request. If you forget to add the sign-off you can also amend a previous commit with the sign-off by running git commit --amend -s. If you've pushed your changes to GitHub already you'll need to force push your branch after this with git push -f. Commercial Support Interested in a fully supported, fully distributed version of sysdig? Check out Sysdig Monitor! Open source sysdig is proudly supported by Sysdig Inc. Interested in what we're doing? Sysdig is hiring. Reporting a vulnerability Please refer to SECURITY.md.
Read the full README on GitHub

What Hacker News says

28 sources
FWIU, e.g. sysdig is justified atop whichever MAC system. In the SELinux MAC system on RHEL and Debian, in /etc/config/selinux, you have SELINUXTYPE=minimal|targeted|mls. RHEL (CentOS and Rocky Linux) and Fedora have SELINUXTYPE=targeted out-of-the-box. The compiled rulesets in /etc/selinux/targeted are generated when [...]. With e.g gnome-system-monitor on a machine with SELINUX=permissive|enforcing, you can right-click the column header in the process table to also display the 'Security context' column that's also visible with e.g. `ps -Z`. The stopdisablingselinux video is a good SELinux tutorial. I'm out of date on Debian/Ubuntu's policy set, which could also probably almost just be sed'ed from the current RHEL policy set. > * SELinux is deny by default, while in systemd you're playing whack-a-mole anyway, and are expected to add dire
Read the rest
ctives one by one until the application stops working. Unit logs usually make it obvious if something was denied.* DENY if not unconfined is actually the out-of-the-box `targeted` config on RHEL and Fedora. For example, Firefox and Chrome currently run as unconfined processes. While decent browsers do do their own process sandboxing, SELinux and/or AppArmor and/or 'containers' with a shared X socket file (and drop-privs and setcap and cgroups and namespaces fwtw) are advisable atop really any process sandboxing? Given that the task is to generate a hull of rules that allow for the observed computational workload to complete with least-privileges, if you enable like every rule and log every process hitting every rung on the way down while running integration tests that approximate the workload, you should end up with enough rule violations in the log to even dumbly generate a rule/policy set without the application developer's expertise around to advise on potential access violations to allow. From https://github.com/draios/sysdig : > "Sysdig instruments your physical and virtual machines at the OS level by installing into the Linux kernel and capturing system calls and other OS events. Sysdig also makes it possible to create trace files for system activity, similarly to what you can do for networks with tools like tcpdump and Wireshark. Probably also worth mentioning: "[BETA] Auditing Sysdig Platform Activities" https://docs.sysdig.com/en/docs/developer-tools/beta-auditin... A bit of SELinux: # /etc/selinux/config SELINUXTYPE=targeted SELINUX=permissive $# touch /.autorelabel # `restorecon /` at boot $# reboot $# setenforce 1 # redundant $ sudo aureport --avc $ journalctl --system -u auditd $ journalctl --system -o json-seq --reverse $ journalctl --system --grep "AVC" --reverse journalctl -fa _TRANSPORT=audit journalctl -fa _TRANSPORT=audit --grep AVC journalctl -a _TRANSPORT=audit --grep 'AVC avc: denied' -o json | pyline -m json 'json.dumps(json.loads(l), indent=2, sort_keys=True)'
In Systemd service sandboxing and security hardening (2020)

Showing the 15 most recent of 28 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.