He didn't mention this in this snippet, but the BCC (BPF Compiler Collection) intends to make this much simpler[1]. In particular it lets you write a tracer in Python (with the BPF program written in C) that attaches the BPF program to whatever types of probe points you like. So while internally there might be all this fragmentation a user shouldn't have to deal with it as much.
[1]: https://github.com/iovisor/bcc
In Give me 15 minutes and I'll change your view of Linux tracing [video]iovisor
bcc
C2016–2026
iovisor / bcc
bcc
BCC - Tools for BPF-based Linux IO analysis, networking, monitoring, and more
64Distinct people
78Mentions
0Explicit recommenders
22.7KGitHub stars
What to know before exploring
What it is
BCC - Tools for BPF-based Linux IO analysis, networking, monitoring, and more
GitHub
Where it is used
The last source check was inconclusive. This does not establish whether a product uses it.
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
- bpftrace/bpftrace · linked in 5 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 10:02:05 AM 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 year78 dated mentions
Observed mentions: 2016-02-03 15:03:57 UTC to 2026-08-10 08:04:42 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 16 | 6 | 10 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 10 | 0 | 10 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 13 | 4 | 9 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 7 | 1 | 6 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 6 | 0 | 6 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 8 | 1 | 7 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 2 | 0 | 2 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
BPF Compiler Collection (BCC)
BCC is a toolkit for creating efficient kernel tracing and manipulation
programs, and includes several useful tools and examples. It makes use of
extended BPF (Berkeley Packet Filters), formally known as eBPF, a new feature
that was first added to Linux 3.15. Much of what BCC uses requires Linux 4.1
and above.
eBPF was described by Ingo Molnár as:
One of the more interesting features in this cycle is the ability to attach eBPF programs (user-defined, sandboxed bytecode executed by the kernel) to kprobes. This allows user-defined instrumentation on a live kernel image that can never crash, hang or interfere with the kernel negatively.
BCC makes BPF programs easier to write, with kernel instrumentation in C
(and includes a C wrapper around LLVM), and front-ends in Python and lua.
It is suited for many tasks, including performance analysis and network
traffic control.
Screenshot
This example traces a disk I/O kernel function, and populates an in-kernel
power-of-2 histogram of the I/O size. For efficiency, only the histogram
summary is returned to user-level.
# ./bitehist.py
Tracing... Hit Ctrl-C to end.
^C
kbytes : count distribution
0 -> 1 : 3 | |
2 -> 3 : 0 | |
4 -> 7 : 211 |********** |
8 -> 15 : 0 | |
16 -> 31 : 0 | |
32 -> 63 : 0 | |
64 -> 127 : 1 | |
128 -> 255 : 800 |**************************************|
The above output shows a bimodal distribution, where the largest mode of
800 I/O was between 128 and 255 Kbytes in size.
See the source: bitehist.py. What this traces,
what this stores, and how the data is presented, can be entirely customized.
This shows only some of many possible capabilities.
Installing
See INSTALL.md for installation steps on your platform.
FAQ
See FAQ.txt for the most common troubleshoot questions.
Reference guide
See docs/reference_guide.md for the reference guide to the bcc and bcc/BPF APIs.
Contents
Some of these are single files that contain both C and Python, others have a
pair of .c and .py files, and some are directories of files.
Tracing
Examples
examples/tracing/bitehist.py: Block I/O size histogram. Examples.
examples/tracing/disksnoop.py: Trace block device I/O latency. Examples.
examples/hello_world.py: Prints "Hello, World!" for new processes.
examples/tracing/mysqld_query.py: Trace MySQL server queries using USDT probes. Examples.
examples/tracing/nodejs_http_server.py: Trace Node.js HTTP server requests using USDT probes. Examples.
examples/tracing/stacksnoop: Trace a kernel function and print all kernel stack traces. Examples.
tools/statsnoop: Trace stat() syscalls. Examples.
examples/tracing/task_switch.py: Count task switches with from and to PIDs.
examples/tracing/tcpv4connect.py: Trace TCP IPv4 active connections. Examples.
examples/tracing/trace_fields.py: Simple example of printing fields from traced events.
examples/tracing/undump.py: Dump UNIX socket packets. Examples
examples/tracing/urandomread.py: A kernel tracepoint example, which traces random:urandom_read. Examples.
examples/tracing/vfsreadlat.py examples/tracing/vfsreadlat.c: VFS read latency distribution. Examples.
examples/tracing/kvm_hypercall.py: Conditional static kernel tracepoints for KVM entry, exit and hypercall Examples.
Tools
tools/argdist: Display function parameter values as a histogram or frequency count. Examples.
tools/bashreadline: Print entered bash commands system wide. Examples.
tools/bpflist: Display processes with active BPF programs and maps. Examples.
tools/capable: Trace security capability checks. Examples.
tools/compactsnoop: Trace compact zone events with PID and latency. Examples.
tools/criticalstat: Trace and report long atomic critical sections in the kernel. Examples
tools/deadlock: Detect potential deadlocks on a running process. Examples.
tools/drsnoop: Trace direct reclaim events with PID and latency. Examples.
tools/funccount: Count kernel function calls. Examples.
tools/inject: Targeted error injection with call chain and predicates Examples.
tools/klockstat: Traces kernel mutex lock events and display locks statistics. Examples.
tools/opensnoop: Trace open() syscalls. Examples.
tools/readahead: Show performance of read-ahead cache Examples.
tools/reset-trace: Reset the state of tracing. Maintenance tool only. Examples.
tools/stackcount: Count kernel function calls and their stack traces. Examples.
tools/syncsnoop: Trace sync() syscall. Examples.
tools/threadsnoop: List new thread creation. Examples.
tools/tplist: Display kernel tracepoints or USDT probes and their formats. Examples.
tools/trace: Trace arbitrary functions, with filters. Examples.
tools/ttysnoop: Watch live output from a tty or pts device. Examples.
tools/ucalls: Summarize method calls or Linux syscalls in high-level languages. Examples.
tools/uflow: Print a method flow graph in high-level languages. Examples.
tools/ugc: Trace garbage collection events in high-level languages. Examples.
tools/uobjnew: Summarize object allocation events by object type and number of bytes allocated. Examples.
tools/ustat: Collect events such as GCs, thread creations, object allocations, exceptions and more in high-level languages. Examples.
tools/uthreads: Trace thread creation events in Java and raw pthreads. Examples.
Memory and Process Tools
tools/execsnoop: Trace new processes via exec() syscalls. Examples.
tools/exitsnoop: Trace process termination (exit and fatal signals). Examples.
tools/killsnoop: Trace signals issued by the kill() syscall. Examples.
tools/kvmexit: Display the exit_reason and its statistics of each vm exit. Examples.
tools/
Read the full README on GitHubWhat Hacker News says
3 sourcesThere definitely isn't any overarching design. You see the same thing all throughout Linux's interfaces (containers are another great example). If you contrast this with the Solaris or BSD interfaces you notice that Linux has always been odd in this respect (DTrace, Jails/Zones, ZFS, pf, kqueue/eventports and so on).
Depending on your view you can view this as a positive or a negative. One view is to say that Linux is more collaborative, and only the "common core" interfaces are actually put into the kernel (with the higher levels being provided in userspace by vendors). A good example of this is the live patching code that came from a distilling of Red Hat's ksplice and SUSE's kgraft systems. You can track done most of Linux's features to this sort of development model.
illumos and BSD however, usually work far more like traditional soft
Read the rest
ware products. Some engineer goes off and implements a really interesting system that then gets put into a release. That's how ZFS, Jails, DTrace and so on were developed (in Sun) and I'm sure you can come up with other examples from BSD. The key point here is that this is a far more authoritarian model -- one set of engineers have decided on a system and developed it mostly in isolation. Linux doesn't permit that style of development because large patchsets need to be broken down over releases.
Personally I must say that I don't care for the Linux style of things, mainly because I feel it hampers OS innovation in some ways. But the upside is that the facilities are more like libraries than frameworks and so you're forced to design your abstractions in userspace. Is that good? I don't know.
Note that following along with the above theme, there is an overarching architecture for Linux's tracing tools (in userspace) in the form of bcc[1].
[1]: https://github.com/iovisor/bcc
I did write a tutorial; it's terse (on purpose) but a start: https://github.com/iovisor/bcc/blob/master/docs/tutorial_bcc...
I imagine we'll get more detailed tutorials over time, especially as the dust settles on the API/interface (it's still improving, plus people are working on alternate front-ends).
Lastly, I'm using bcc on a regular basis at Netflix, and usually find the tools that exist are sufficient (a couple of days ago I traced a resource leak using stackcount and trace). When there's something extra I need, I add a tool to bcc. So yes, we should make tooling easy, but I hope a lot of the time people find that a tool already exists for what they need.
In Linux EBPF Tracing Tools