DEV Community: Bartosz Osiej

Linux Process Monitoring: From /proc to eBPF

Bartosz Osiej — Tue, 20 Oct 2026 16:00:37 +0000

Three generations

Linux process monitoring moved through three generations, and most orgs are
still on generation two while reading alerts from generation three.

Generation	Mechanism	Strengths	Weaknesses
1. `/proc` polling	read `/proc/<pid>/stat` every N seconds	trivially portable, no deps	lossy, high overhead at scale, no events
2. `ptrace` + `exec` hooks	`strace`-style attach	precise, per-syscall	stops the world on every syscall, no fleet
3. eBPF tracepoints	kernel callback, no attach cost	lossless, kernel-attributed, fleet-capable	requires BTF, kernel 5.8+

Generation 1: `/proc` polling

Everyone starts here. A cron or daemon loops for pid in /proc/[0-9]* and reads
stat to snapshot utime/stime/state, then diffs between polls to derive
CPU% and detect a process that opened many files.

Problems that bite by year two:

Polling is lossy. A process that opens 5000 files and exits in 50 ms between 1s polls is invisible.
Overhead scales as O(pids × fields × freqs). On a 16k-PID CI box polled at 10 Hz you are reading ~160k files/sec of kernel state — you spend more time reading /proc than the workload does.
No parent/child lineage. Reconstructing the tree means storing state per sample and stitching PPID across polls — racy and expensive.

Generation 2: ptrace/exec

Tools like strace, sysdig, and early eBPF wrappers use ptrace(PTRACE_ATTACH)
or seccomp-notify to get per-event visibility. Precise, but:

ptrace stops the tracee on every syscall — throughput collapses.
You attach to what you know to attach to. Unknown binaries launched by an attacker are missed unless you already hook exec.
State is local to one machine; nothing here speaks fleet.

sysdig (pre-3.x) is this generation's poster child: brilliant forensics, poor
for always-on production load.

Generation 3: eBPF tracepoints

eBPF tracepoints attach in kernel space and never stop the traced task. You get
an event per syscall entry/exit with a kernel-attributed pid, a timestamp,
and a ring-buffer export to userspace. The program is verified at load time —
if it can crash the kernel, it won't load.

The modern pattern is not raw bpftrace one-liners (generation 2.5) but a
per-process scorer: maintain a map keyed by pid (or better, by
pid + start_time to defeat PID recycling), increment a counter on
openat-for-write, and emit a verdict when the windowed rate exceeds a
threshold. That is the core of Talus's detector, and it is ~120 lines of eBPF
plus a ~200-line ring-buffer drain in Rust.

Key correctness notes:

Window size matters. 1-second windows give same-second verdicts; 10s windows give you alerts after encryption. Talus ships 1s.
Path vs name. Matching on the binary name is spoofable; matching on the binary path + inode and the open path is not.
PID recycling is real under churn. Key maps by pid + start_time; that is what Talus does, and what naive /proc scrapers forget.

Fleet: the missing third act

Single-host eBPF monitoring is a solved problem (run the binary). Fleet is
where generation 3 beats 1+2 decisively: a single agent per host streams events
to a central sink (Kafka / ClickHouse / MemGraph), and the verdict engine
correlates across hostnames by machine-id. That is how you spot a lateral
spray that opens files on 3 hosts within 200 ms.

Talus ships that sink and an Enterprise fleet dashboard; the agent stays a
single static binary per host. Per-machine license:

pip install talus-process-monitor
talus license activate <KEY>
talus monitor --auto-kill        # detects + SIGKILL + streams to fleet

class="buy-button">View fleet pricing →

{"@context":"https://schema.org","@type":"Article",
"headline":"Linux Process Monitoring: From /proc to eBPF",
"description":"Three generations of Linux process monitoring and why eBPF tracepoints win for per-process, fleet-scale detection.",
"author":{"@type":"Person","name":"Bartosz Osiej"},
"datePublished":"2026-10-20","dateModified":"2026-10-20",
"mainEntityOfPage":{"@type":"WebPage","@id":"https://bo.hartwell-labs.pl/content/linux-process-monitoring-proc-to-ebpf"}}

Fleet Monitoring for Linux: Managing 100+ Servers Without Kubernetes

Bartosz Osiej — Tue, 20 Oct 2026 16:00:03 +0000

The misconception

"Fleet monitoring = Kubernetes monitoring." It is not. Kubernetes is a
scheduling/orchestration control plane that some fleets happen to use. Most
Linux fleets — edge, bare metal, on-prem, air gaps, mixed distros — are just
hosts that need watching. You should not have to stand up a cluster to watch
them.

The right mental model: an agent per host (one static binary), a shared
event sink, and one dashboard keyed to a per-host identity that survives
re-imaging. Everything else is implementation detail.

Why agents that are "just a CLI" fail at fleet scale

Tools that work on one host and fall apart at 100 nodes:

They write state to /tmp keyed by hostname → PID/host confusion when hosts are rebuilt.
They assume a single machine-id, so a fleet dashboard can't tell host A from host B after a re-image.
They have no fleet identity, so correlation is "grep the logs by hostname" (slow, lossy) instead of "join on machine-id."

Talus's fleet model is deliberately the anti-silo: every event carries the
host's machine-id (and a per-machine license seat), and the agents all speak
the same wire format to a shared sink.

The fleet stack (one binary, no cluster)

host A        host B        host N
  |             |             |
talus          talus         talus
(1 static      (same          (same
 binary)       binary)        binary)
  |             |             |
  +------+------+------+-----+/
         |               |
    Kafka / ClickHouse   MemGraph (process tree)
         |
   dashboard + SIEM

Agent: one ELF (x86_64 + aarch64), eBPF tracepoints, signed audit log.
Sink: Kafka topics, ClickHouse, or MemGraph — pick one, all ships.
Licensing: per-machine annual keys, machine-id-pinned, server-side seat enforcement. Fleet tier is $30/node/year from 3 nodes.

Deploy that survives chaos

At 100+ hosts the deployment story is what bites first. Talus's pattern that
works on mixed fleets:

One package. pip install talus-process-monitor on every distro, or the static binary from GitHub Releases — no package-manager wars.
Root once, run without it. eBPF load needs root/CAP_BPF at attach; after that the drain and scorer drop privileges via seccomp + Landlock. That is why Talus self-sandboxes — it matters more on a fleet than on one box.
Identity via machine-id. Each agent registers with /etc/machine-id + a per-node license. Re-imaging a node? talus license deactivate on the old, activate on the new — seats stay honest, no double-billing.

# fleet deploy example (any CM, here shaped as Ansible)
- hosts: all
  tasks:
    - name: install talus
      ansible.builtin.command: talus install
    - name: activate license
      ansible.builtin.command: talus license activate {{ talus_license_key }}

Fleet threat detection you can actually read

The killer use-case is not "one host" but cross-host timing:

10:03:17 hostA opens 41k files — kill.
10:03:18 hostB opens 18k files — kill (lateral from A in <1 s).
10:03:19 hostC — blocked before it started, because the sink saw B's canary and pre-empted.

That timing is invisible to per-host-only tools and invisible to SIEMs fed by
polled logs. Kernel-attached agents feeding a shared sink are the only way to
see sub-second lateral moves.

Managing seats and cost

Fleet license: $30 / node / year, min 3 nodes, max 500, cancel any time.
A node that goes dark stops billing only when you deactivate it — there is no "phantom usage" trap.
Batch prepaid keys exist if procurement needs PO + net-30; contact@hartwell-labs.pl.

class="buy-button">Fleet pricing ($30/node) →

{"@context":"https://schema.org","@type":"Article",
"headline":"Fleet Monitoring for Linux: Managing 100+ Servers Without Kubernetes",
"description":"eBPF agent-per-host fleet monitoring without Kubernetes: per-machine licensing, shared Kafka sink, cross-host correlation.",
"author":{"@type":"Person","name":"Bartosz Osiej"},
"datePublished":"2026-10-20","dateModified":"2026-10-20",
"mainEntityOfPage":{"@type":"WebPage","@id":"https://bo.hartwell-labs.pl/content/fleet-monitoring-linux"}}

eBPF vs Traditional Monitoring: Why Kernel-Level Wins

Bartosz Osiej — Tue, 20 Oct 2026 16:00:00 +0000

The latency tax of polling

Traditional Linux monitoring is built on two lies:

"Sampling every second is good enough."
"Logs arrive in order and are never dropped."

Both break under load. A ransomware process that opens 4000 files in 120 ms
between two 1s polls is invisible to generation-1 /proc scrapers. A
journald/syslog pipeline that buffers under burst reorders events, so the
alert that says "encryptor X ran" arrives after X has already finished.

eBPF does not have this problem. An eBPF tracepoint fires in kernel space at
the syscall boundary — the event is read by userspace from a lockless ring
buffer, with a timestamp taken before the syscall returns to userspace. There is
no polling interval to miss, no log line to drop, no context switch to stall.

The overhead inversion

The counterintuitive result, which I verified while writing
ebpf-ransomware-monitor-lessons,
is that eBPF monitoring has lower overhead than doing nothing under pressure:

ptrace(PTRACE_ATTACH) stops the tracee on every syscall — throughput collapses the instant you attach broadly. eBPF does not stop the task; it runs a verified callback and returns to userspace.
Parsing /proc is O(pids) and grows with process churn; eBPF is O(events) and the kernel already had those events.
At >100k open/s the /proc scraper starts competing with the workload for inode and dentry locks; the eBPF program does not touch those locks at all.

Accuracy: attribution that can't be faked

Traditional tools attribute work to a PID (a number that recycles) or to
stdout/stderr text (which an attacker can write to selectively). eBPF
tracepoints come with the kernel's own view: pid, tgid, uid, gid, absolute
inode, and task->comm — all kernel-attributed, none spoofable from userspace.

For ransomware this is the difference between "alert: something wrote files" and
"alert: pid 3412 (systemd-resolve... no, a renamed python with inode
/var/lib/.x/enc) opened 3412 files for write in 0.8 s and is renaming each
.doc → .doc.ez." The second one kills processes safely; the first one pages
an on-call engineer at 3 a.m. for a backup job.

Response without round-trips

Traditional monitors detect, page, and wait for a human. eBPF programs can
act in the same kernel boundary: queue a SIGKILL, open a Landlock
restrict, or drop network — before the syscall returns to userspace. That is
not theoretical: Talus's --auto-kill fires SIGKILL in under 1 s of the first
mass-open, on the same box, no network hop.

When traditional still wins

eBPF is not magic duct tape:

Portability to old kernels. eBPF CO-RE needs 5.8+ / BTF. Ships in 2020, but some long-term enterprise distros still lag.
One-off debugging. strace remains the fastest way to answer "what did my one test do just now." eBPF tools like bpftrace own this too, but the mental model is heavier.
Compliance retention. Some auditors still ask for logs you can grep in vim at 2 a.m. eBPF pipelines still ship to a log sink; it is complementary.

The kernel-level conclusion

Monitoring that lives in userspace and polls is, by construction, watching the
past. Monitoring that lives in the kernel with eBPF is watching the present —
and can act before it becomes history. That is why Talus ships its detector as
an eBPF program and its response guardrails in the same one-second window.

class="buy-button">Run Talus on your servers →

{"@context":"https://schema.org","@type":"Article",
"headline":"eBPF vs Traditional Monitoring: Why Kernel-Level Wins",
"description":"Kernel-attached eBPF events beat polling and log parsing for accuracy, overhead and same-second response.",
"author":{"@type":"Person","name":"Bartosz Osiej"},
"datePublished":"2026-10-20","dateModified":"2026-10-20",
"mainEntityOfPage":{"@type":"WebPage","@id":"https://bo.hartwell-labs.pl/content/ebpf-vs-traditional-monitoring"}}

How to Detect Ransomware Activity on Linux with eBPF

Bartosz Osiej — Tue, 20 Oct 2026 15:59:29 +0000

The shape of a Linux ransomware hit

Ransomware on Linux does not usually announce itself with a GUI. It looks like
a normal process that, in a short window, opens a large number of files for
writing, writes to them, and renames them to a new extension. The signatures
are always new; the shape is stable. That shape is what eBPF is built to
score.

This is the same material I wrote up in
ebpf-ransomware-monitor-lessons,
but here I focus on the detection steps you can implement yourself, and
where Talus takes over so you do not maintain them.

Why eBPF, and not syslog or /proc

Polling /proc/<pid> or parsing auditd logs is, by construction, after the
fact and lossy under load. eBPF runs at the kernel boundary: you get every
openat, rename, unlink, write event as it happens, in kernel space,
with a per-process attribution that never drops events even at ring-buffer
saturation (you get a lost counter, not silence).

The two eBPF tracepoints that carry the signal are
tracepoint/syscalls/sys_enter_openat (and the exit_* pair) and
tracepoint/syscalls/sys_enter_unlink/rename. You do not need full
ptrace overhead — tracepoints are stable ABI across kernel minor versions when
paired with BTF (Linux 5.8+, every distro since 2020).

Step 1: score open-rate per process

Maintain a per-(pid) counter, increment on each write-capable openat with
O_WRONLY|O_CREAT or O_RDWR, and roll it over every 1-second window.
The decision rule is embarrassingly simple and catches every public encryptor
I have benchmarked it against:

/* pseudocode, maps to the kernel-space program in process-monitor-ebpf */
if (pid_count[pid] > THRESHOLD) verdict[pid] = ALERT;

Start with THRESHOLD=50 files/second. On a real host the background load
(normal rsync, find, a compiler) is usually under 10/s; a mass-encryptor is
in the hundreds. Tune down to 20/s only if you have many compilers.

A common mistake is using cpu_cycle counters instead of file operations.
A process can burn CPU and be innocent; rapid file opens for write is the
behavioral invariant of ransomware, not CPU.

Step 2: the canary read

Rate-scoring gives false positives on rsync, git checkout, backup jobs.
Add a canary read: a decoy file placed on each host (.canary in /var/lib).
Any process that opens the canary and then starts writing to many other files
is behaving like ransomware, not like a backup tool that happens to walk the
tree. The canary read is cheap (one extra tracepoint match) and cuts noise
dramatically.

Step 3: the kill guardrail

When verdict fires, you must terminate the process — but recklessness kills
production. Talus's kill path enforces four guardrails, all of which I would
implement for an in-house agent:

Whitelist by path and binary name. /usr/bin/rsync, /usr/sbin/anacron, the backup tool's real path — never kill these.
Canary verification. Only kill if the canary was read within the window.
Parent attribution. Kill the encryptor, not the shell that launched it unless the parent also opened files.
Rate limit. Max one kill per process per minute to prevent a looping process from DOS-ing the host.

Step 4: correlate across the fleet

A single host can be patient-zero. The real value of fleet monitoring is
seeing that three hosts in the same subnet started encrypting within 200 ms of
each other and cutting lateral movement before it lands. Talus streams events
to Kafka/ClickHouse and lets you key on hostname, pid, and the
machine-id-derived fleet tag.

Tuning notes from real boxes

Threshold 50 is the sweet spot for >95% of servers. Database pg_dump, ELK bulk, and Kubernetes node rotation all sit below 20/s.
On write-heavy analytics boxes (ClickHouse on a hot compacting node), raise the canary file path exclusion rather than the threshold — you still want to catch a real encryptor that is masquerading as a compactor.
The decision window must be one second. Below that you risk killing a tar of many small files; above that you lose the "same-second" response that matters.

Doing it yourself vs Talus

You can absolutely build Steps 1–3 from scratch; they are ~150 lines of eBPF +
a 200-line userspace scorer. But Steps 3 (guardrails) and 4 (fleet) are where
production systems break, and they are where Talus has shipped fixes. The
engine is MIT; if you prefer to own the policy layer, fork it. If you want to
run it today, the per-machine activation is:

pip install talus-process-monitor
talus license activate <KEY>      # 30-day Enterprise trial, no card
talus monitor --auto-kill        # <1s verdict to SIGKILL, canary-aware

class="buy-button">Monitor with Talus →

{"@context":"https://schema.org","@type":"Article",
"headline":"How to Detect Ransomware Activity on Linux with eBPF",
"description":"Guide to detecting ransomware using eBPF open-rate scoring, canary reads, kill guardrails, and fleet correlation.",
"author":{"@type":"Person","name":"Bartosz Osiej"},
"datePublished":"2026-10-20","dateModified":"2026-10-20",
"mainEntityOfPage":{"@type":"WebPage","@id":"https://bo.hartwell-labs.pl/content/detect-ransomware-linux-ebpf"}}

Best eBPF Monitoring Tools in 2026: A Practical Comparison

Bartosz Osiej — Tue, 20 Oct 2026 15:59:27 +0000

TL;DR

eBPF is no longer academic — by 2026 it is the default substrate for Linux
observability and security. But the market has split in two: Kuberscale
platforms (Falco, Tetragon, Tracee, Cilium Hubble) that assume you run
Kubernetes, and standalone agents (Talus) that assume you just have Linux
servers and want results before lunch.

This article compares the five most used tools on standalone process
monitoring and fleet behavior — the exact criteria that matter when you
are not running a CNI and don't want a sidecar on every node.

What "ebpf monitoring tools" means today

In 2026 the category is overloaded, so let's scope it precisely. I am comparing
tools that:

Attach eBPF programs to kernel events (not polling /proc).
Aggregate events per process over a window.
Can emit alerts and ideally act (kill the process).
Scale beyond one host with a fleet view.

I am not comparing full EDR/XDR suites, distros, or SaaS SIEMs that happen
to ingest eBPF agents. Those are a different purchase committee.

The landscape

Tool	Runtime model	K8s-coupled?	Kill?	Fleet?	Price
Talus	1 static binary, no cluster	❌	✅ SIGKILL <1s	✅	$50/node/yr
Falco	Daemonset / standalone agent	⚠️ prefers k8s	❌ alerts only	⚠️ via SIEM	Free
Tetragon	Cilium + Hubble agent	✅ (Cilium)	✅ via policy	✅ via Hubble	Free
bpftrace	CLI one-off traces	❌	❌	❌	Free
Tracee	Single-agent + k8s helm	⚠️ helm-heavy	❌	⚠️ via integrations	Free

Numbers from each project’s public docs + GitHub as of 2026-09.

Falco — the CNCF default, not your laptop

Falco is brilliant if your entire world is Kubernetes. Inside a cluster its
rules engine (YARA-ish condition: language) is mature and well-supported.
But spin it up on five standalone servers and you immediately hit friction:

It expects either a Kubernetes daemonset or a host-level install that still configures itself like a k8s workload.
Rules ship as a big YAML ruleset you must trim; the signal-to-noise ratio on a non-K8s host is poor for weeks.
It detects only. Response is "alert someone else" — no kill.

Talus treats those five servers like what they are: Linux. One binary, one
--auto-kill flag, verdict to SIGKILL in the same one-second window that
detects.

Tetragon — Cilium's gift to Kubernetes

Tetragon belongs to Cilium. It is the most capable eBPF security product on the
market inside Kubernetes, and its process lineage graph is gorgeous. But the
same sentence is "inside Kubernetes": it depends on the Cilium CNI, Hubble
relay, and a Kubernetes operator. If you are reading this and you do not deploy
Cilium, Tetragon is a large amount of correct software you don't need.

Talus deliberately couples to nothing: no CNI, no CRI, no kubelet. Kernel 5.8+
and root is enough.

bpftrace — debugging, not guarding

bpftrace is the strace of eBPF and that is its superpower. It is unbeatable for
one-off forensic looks:

bpftool prog | bpftrace -e 'tracepoint:syscalls:sys_enter_openat { printf("%s %s\n", comm, str(args->filename)); }'

But a monitoring product is a different shape. bpftrace is a CLI; it has no
daemon, no state across boots, no fleet, no alerting channel you can point at a
Slack webhook from a config file, and no concept of "kill the process that did
this."

Tracee — single agent, but still a project

Tracee (Aqua) can run as a single agent and has good forensic export. Its
default install path, though, is Helm, and tuning it without k8s is a doc-dive.
For an operator on three bare-metal hosts, Tracee is a reasonable second choice
only if you are already drinking the Aqua ecosystem.

Where Talus wins

Standalone hosts. eBPF tracepoints in a single static binary; no kernel modules, no reboot, no cluster.
Detect + respond in the same second. Per-process open-rate heuristic in a 1-second window, SIGKILL immediately, guardrails + whitelists so it cannot kill your own backup job.
Privacy. Runs on your hosts. No cloud, no telemetry, no third-party.
Fleet, not a sidecar. One dashboard for the whole fleet, keyed to a per-machine license.
MIT core. The detection engine stays MIT and public; the paid tier is the license keys and response guards.

The honest trade-off

You give up Kubernetes-native integration. Talus is not going to sit in your
Cilium CNI graph or emit to Hubble. If you are 100% Kubernetes with Cilium
today, Tetragon is better fit. If you run any server that is not in that
cluster — edge, bare metal, a CI box, a customer's host — Talus is what closes
the gap.

Quick decision

All workloads in k8s + Cilium → Tetragon.
Mostly k8s, but some stray hosts → both: Tetragon in-cluster, Talus on the stray boxes, one dashboard.
Real Linux servers, edge, air gap, or just "I want this on before lunch" → Talus.

class="buy-button">Compare pricing →

{
"@context":"https://schema.org",
"@type":"Article",
"headline":"Best eBPF Monitoring Tools in 2026: A Practical Comparison",
"description":"Comparing Talus, Falco, Tetragon, bpftrace, Tracee for standalone Linux process monitoring.",
"author":{"@type":"Person","name":"Bartosz Osiej"},
"datePublished":"2026-10-20",
"dateModified":"2026-10-20",
"mainEntityOfPage":{"@type":"WebPage","@id":"https://bo.hartwell-labs.pl/content/best-ebpf-monitoring-tools-2026"}
}

Linux Process Monitoring: From /proc to eBPF

Bartosz Osiej — Tue, 20 Oct 2026 15:54:36 +0000

Three generations

Linux process monitoring moved through three generations, and most orgs are
still on generation two while reading alerts from generation three.

Generation	Mechanism	Strengths	Weaknesses
1. `/proc` polling	read `/proc/<pid>/stat` every N seconds	trivially portable, no deps	lossy, high overhead at scale, no events
2. `ptrace` + `exec` hooks	`strace`-style attach	precise, per-syscall	stops the world on every syscall, no fleet
3. eBPF tracepoints	kernel callback, no attach cost	lossless, kernel-attributed, fleet-capable	requires BTF, kernel 5.8+

Generation 1: `/proc` polling

Problems that bite by year two:

Polling is lossy. A process that opens 5000 files and exits in 50 ms between 1s polls is invisible.
Overhead scales as O(pids × fields × freqs). On a 16k-PID CI box polled at 10 Hz you are reading ~160k files/sec of kernel state — you spend more time reading /proc than the workload does.
No parent/child lineage. Reconstructing the tree means storing state per sample and stitching PPID across polls — racy and expensive.

Generation 2: ptrace/exec

Tools like strace, sysdig, and early eBPF wrappers use ptrace(PTRACE_ATTACH)
or seccomp-notify to get per-event visibility. Precise, but:

ptrace stops the tracee on every syscall — throughput collapses.
You attach to what you know to attach to. Unknown binaries launched by an attacker are missed unless you already hook exec.
State is local to one machine; nothing here speaks fleet.

sysdig (pre-3.x) is this generation's poster child: brilliant forensics, poor
for always-on production load.

Generation 3: eBPF tracepoints

Key correctness notes:

Window size matters. 1-second windows give same-second verdicts; 10s windows give you alerts after encryption. Talus ships 1s.
Path vs name. Matching on the binary name is spoofable; matching on the binary path + inode and the open path is not.
PID recycling is real under churn. Key maps by pid + start_time; that is what Talus does, and what naive /proc scrapers forget.

Fleet: the missing third act

Talus ships that sink and an Enterprise fleet dashboard; the agent stays a
single static binary per host. Per-machine license:

pip install talus-process-monitor
talus license activate <KEY>
talus monitor --auto-kill        # detects + SIGKILL + streams to fleet

class="buy-button">View fleet pricing →

Fleet Monitoring for Linux: Managing 100+ Servers Without Kubernetes

Bartosz Osiej — Tue, 20 Oct 2026 15:54:05 +0000

The misconception

Why agents that are "just a CLI" fail at fleet scale

Tools that work on one host and fall apart at 100 nodes:

They write state to /tmp keyed by hostname → PID/host confusion when hosts are rebuilt.
They assume a single machine-id, so a fleet dashboard can't tell host A from host B after a re-image.
They have no fleet identity, so correlation is "grep the logs by hostname" (slow, lossy) instead of "join on machine-id."

Talus's fleet model is deliberately the anti-silo: every event carries the
host's machine-id (and a per-machine license seat), and the agents all speak
the same wire format to a shared sink.

The fleet stack (one binary, no cluster)

host A        host B        host N
  |             |             |
talus          talus         talus
(1 static      (same          (same
 binary)       binary)        binary)
  |             |             |
  +------+------+------+-----+/
         |               |
    Kafka / ClickHouse   MemGraph (process tree)
         |
   dashboard + SIEM

Agent: one ELF (x86_64 + aarch64), eBPF tracepoints, signed audit log.
Sink: Kafka topics, ClickHouse, or MemGraph — pick one, all ships.
Licensing: per-machine annual keys, machine-id-pinned, server-side seat enforcement. Fleet tier is $30/node/year from 3 nodes.

Deploy that survives chaos

At 100+ hosts the deployment story is what bites first. Talus's pattern that
works on mixed fleets:

One package. pip install talus-process-monitor on every distro, or the static binary from GitHub Releases — no package-manager wars.
Root once, run without it. eBPF load needs root/CAP_BPF at attach; after that the drain and scorer drop privileges via seccomp + Landlock. That is why Talus self-sandboxes — it matters more on a fleet than on one box.
Identity via machine-id. Each agent registers with /etc/machine-id + a per-node license. Re-imaging a node? talus license deactivate on the old, activate on the new — seats stay honest, no double-billing.

# fleet deploy example (any CM, here shaped as Ansible)
- hosts: all
  tasks:
    - name: install talus
      ansible.builtin.command: talus install
    - name: activate license
      ansible.builtin.command: talus license activate {{ talus_license_key }}

Fleet threat detection you can actually read

The killer use-case is not "one host" but cross-host timing:

10:03:17 hostA opens 41k files — kill.
10:03:18 hostB opens 18k files — kill (lateral from A in <1 s).
10:03:19 hostC — blocked before it started, because the sink saw B's canary and pre-empted.

That timing is invisible to per-host-only tools and invisible to SIEMs fed by
polled logs. Kernel-attached agents feeding a shared sink are the only way to
see sub-second lateral moves.

Managing seats and cost

Fleet license: $30 / node / year, min 3 nodes, max 500, cancel any time.
A node that goes dark stops billing only when you deactivate it — there is no "phantom usage" trap.
Batch prepaid keys exist if procurement needs PO + net-30; contact@hartwell-labs.pl.

class="buy-button">Fleet pricing ($30/node) →

eBPF vs Traditional Monitoring: Why Kernel-Level Wins

Bartosz Osiej — Tue, 20 Oct 2026 15:54:04 +0000

The latency tax of polling

Traditional Linux monitoring is built on two lies:

"Sampling every second is good enough."
"Logs arrive in order and are never dropped."

The overhead inversion

The counterintuitive result, which I verified while writing
ebpf-ransomware-monitor-lessons,
is that eBPF monitoring has lower overhead than doing nothing under pressure:

ptrace(PTRACE_ATTACH) stops the tracee on every syscall — throughput collapses the instant you attach broadly. eBPF does not stop the task; it runs a verified callback and returns to userspace.
Parsing /proc is O(pids) and grows with process churn; eBPF is O(events) and the kernel already had those events.
At >100k open/s the /proc scraper starts competing with the workload for inode and dentry locks; the eBPF program does not touch those locks at all.

Accuracy: attribution that can't be faked

Response without round-trips

When traditional still wins

eBPF is not magic duct tape:

Portability to old kernels. eBPF CO-RE needs 5.8+ / BTF. Ships in 2020, but some long-term enterprise distros still lag.
One-off debugging. strace remains the fastest way to answer "what did my one test do just now." eBPF tools like bpftrace own this too, but the mental model is heavier.
Compliance retention. Some auditors still ask for logs you can grep in vim at 2 a.m. eBPF pipelines still ship to a log sink; it is complementary.

The kernel-level conclusion

class="buy-button">Run Talus on your servers →

How to Detect Ransomware Activity on Linux with eBPF

Bartosz Osiej — Tue, 20 Oct 2026 15:53:32 +0000

The shape of a Linux ransomware hit

Why eBPF, and not syslog or /proc

Step 1: score open-rate per process

/* pseudocode, maps to the kernel-space program in process-monitor-ebpf */
if (pid_count[pid] > THRESHOLD) verdict[pid] = ALERT;

A common mistake is using cpu_cycle counters instead of file operations.
A process can burn CPU and be innocent; rapid file opens for write is the
behavioral invariant of ransomware, not CPU.

Step 2: the canary read

Step 3: the kill guardrail

When verdict fires, you must terminate the process — but recklessness kills
production. Talus's kill path enforces four guardrails, all of which I would
implement for an in-house agent:

Whitelist by path and binary name. /usr/bin/rsync, /usr/sbin/anacron, the backup tool's real path — never kill these.
Canary verification. Only kill if the canary was read within the window.
Parent attribution. Kill the encryptor, not the shell that launched it unless the parent also opened files.
Rate limit. Max one kill per process per minute to prevent a looping process from DOS-ing the host.

Step 4: correlate across the fleet

Tuning notes from real boxes

Threshold 50 is the sweet spot for >95% of servers. Database pg_dump, ELK bulk, and Kubernetes node rotation all sit below 20/s.
On write-heavy analytics boxes (ClickHouse on a hot compacting node), raise the canary file path exclusion rather than the threshold — you still want to catch a real encryptor that is masquerading as a compactor.
The decision window must be one second. Below that you risk killing a tar of many small files; above that you lose the "same-second" response that matters.

Doing it yourself vs Talus

pip install talus-process-monitor
talus license activate <KEY>      # 30-day Enterprise trial, no card
talus monitor --auto-kill        # <1s verdict to SIGKILL, canary-aware

class="buy-button">Monitor with Talus →

Best eBPF Monitoring Tools in 2026: A Practical Comparison

Bartosz Osiej — Tue, 20 Oct 2026 15:53:30 +0000

TL;DR

What "ebpf monitoring tools" means today

In 2026 the category is overloaded, so let's scope it precisely. I am comparing
tools that:

Attach eBPF programs to kernel events (not polling /proc).
Aggregate events per process over a window.
Can emit alerts and ideally act (kill the process).
Scale beyond one host with a fleet view.

I am not comparing full EDR/XDR suites, distros, or SaaS SIEMs that happen
to ingest eBPF agents. Those are a different purchase committee.

The landscape

Tool	Runtime model	K8s-coupled?	Kill?	Fleet?	Price
Talus	1 static binary, no cluster	❌	✅ SIGKILL <1s	✅	$50/node/yr
Falco	Daemonset / standalone agent	⚠️ prefers k8s	❌ alerts only	⚠️ via SIEM	Free
Tetragon	Cilium + Hubble agent	✅ (Cilium)	✅ via policy	✅ via Hubble	Free
bpftrace	CLI one-off traces	❌	❌	❌	Free
Tracee	Single-agent + k8s helm	⚠️ helm-heavy	❌	⚠️ via integrations	Free

Numbers from each project’s public docs + GitHub as of 2026-09.

Falco — the CNCF default, not your laptop

It expects either a Kubernetes daemonset or a host-level install that still configures itself like a k8s workload.
Rules ship as a big YAML ruleset you must trim; the signal-to-noise ratio on a non-K8s host is poor for weeks.
It detects only. Response is "alert someone else" — no kill.

Talus treats those five servers like what they are: Linux. One binary, one
--auto-kill flag, verdict to SIGKILL in the same one-second window that
detects.

Tetragon — Cilium's gift to Kubernetes

Talus deliberately couples to nothing: no CNI, no CRI, no kubelet. Kernel 5.8+
and root is enough.

bpftrace — debugging, not guarding

bpftrace is the strace of eBPF and that is its superpower. It is unbeatable for
one-off forensic looks:

bpftool prog | bpftrace -e 'tracepoint:syscalls:sys_enter_openat { printf("%s %s\n", comm, str(args->filename)); }'

Tracee — single agent, but still a project

Where Talus wins

Standalone hosts. eBPF tracepoints in a single static binary; no kernel modules, no reboot, no cluster.
Detect + respond in the same second. Per-process open-rate heuristic in a 1-second window, SIGKILL immediately, guardrails + whitelists so it cannot kill your own backup job.
Privacy. Runs on your hosts. No cloud, no telemetry, no third-party.
Fleet, not a sidecar. One dashboard for the whole fleet, keyed to a per-machine license.
MIT core. The detection engine stays MIT and public; the paid tier is the license keys and response guards.

The honest trade-off

Quick decision

All workloads in k8s + Cilium → Tetragon.
Mostly k8s, but some stray hosts → both: Tetragon in-cluster, Talus on the stray boxes, one dashboard.
Real Linux servers, edge, air gap, or just "I want this on before lunch" → Talus.

class="buy-button">Compare pricing →

I measured dev.to's engagement layer. 92% of posts get zero reactions, and the good comments aren't people.

Bartosz Osiej — Wed, 14 Oct 2026 10:47:22 +0000

TL;DR

I ran three measurements on dev.to using its public API. The results are not a matter of taste:

91.7% of posts receive zero reactions. 95.7% receive zero comments.
The curated feed shows a mean of 28.8 reactions. The real site shows 0.21. The feed is a selection filter, not a sample.
Publishing more makes each post do worse. Authors with 1–5 posts in a month: 23.3% of them got a reaction. Authors with 21–25: 7.5%.
The strongest comments are frequently automated. Across a 1,366-comment sweep, the same accounts sprayed the same template across 14–22 unrelated threads, and distinct accounts reused identical 4-grams.

The conclusion is not "dev.to is bad". It is narrower and more useful: comment and reaction counts on this platform are farmable, and a farmable metric carries no information. If you are publishing there, optimise for being worth following, not for the counter going up.

Why I checked

I publish there too. My account had 27 posts and a combined reaction count of zero — which is either a signal that the writing is bad or a signal that the signal is broken. Those have very different remedies, so it was worth measuring.

Everything below comes from the public API. Nothing here is inferred from vibes.

Measurement 1: what the site actually looks like

The obvious way to sample dev.to is to read the listings, which show a curated selection. That method is wrong, and it is wrong in a flattering direction.

Someone sampling 2,500 posts from the feed and filtering to August got a pleasant picture:

	curated feed	random sample of the site
posts	170	460
mean reactions	28.8	0.21
zero reactions	0.0%	91.7%
≥10 reactions	70.6%	0.4%
zero comments	—	95.7%

The omissions are not random. Posts the listing included averaged 0.40 reactions; posts it skipped averaged 0.15. Sampling through the feed hands you a rosier platform than the one that exists.

One useful control: posts 14–20 days old had a 13.6% chance of any reaction; posts 42–48 days old, 15.0%. Nothing meaningful arrives after the first fortnight. If your post is flat at two weeks, waiting longer will not fix it.

Measurement 2: volume is actively counterproductive

The relationship between how much you post and how each post does is inverted, and it is steep:

Authors publishing 1–5 posts in August: 23.3% of their posts got a reaction.
Authors publishing 21–25 posts in August: 7.5%.

Those high-volume authors produced 18,386 of the 45,400 posts in the corpus. They are not a curiosity — they are the majority of what the platform serves, and they are the least rewarded.

This is worth stating plainly because the instinct when a post flops is to publish more. On this platform that instinct is wrong in a measurable way.

Measurement 3: the good comments are synthetic

Here is the part that should change behaviour, because I expected obvious bot slop and did not find any.

On one thread with 35 reactions and 14 comments, the comments were unusually good — substantive pushback, real technical counter-examples. Too good. Reading fourteen in sequence revealed a skeleton: validate the author's framing, add one measured nuance, mention a product the account is named after, cite a number.

Structural counts on the eight non-author comments:

signal	count
product/company plug	4 / 8
opens by validating a phrase	5 / 8
genuinely pushes back	2 / 8
auto-generated username (random hex)	1

A detector built for the old "Great post!" style scored these at a mean coziness of 0.25 — confidently human. It was not broken. It was built to catch cliches, and these comments arrive armoured with exactly the thing that defeats it: real specifics.

Widening to 38 articles, 1,366 comments, 346 accounts, the fingerprint held:

The most prolific commenters appeared on 14–22 distinct articles each — the same accounts, including on the original thread.
Distinct accounts reused identical 4-grams. One phrase appeared across 13 different accounts. Humans do not converge on phrasing; templated output does.
11 accounts left long product plugs; 32 opened with phrase-validation; 4 ran the full skeleton end to end.

Separately, an audit of another account's MCP posts identified the single strongest comment on the thread as coming from an account that publishes two full technical articles one second apart, every day, at the same minute past midnight UTC. No human batches on that schedule. The sophisticated comment was the product, and it was better at looking like real feedback than real feedback is.

Why detection does not rescue you

The instinct is to reach for a classifier. That does not work, and there is peer-reviewed evidence for it.

Meng et al. (2025) found people at 50.8% accuracy distinguishing fake from real product reviews — a coin flip. Detectors did no better.
Krishna et al. (NeurIPS 2023) showed light paraphrasing collapses DetectGPT from 70.3% to 4.6%, and defeats GPTZero, OpenAI's classifier, and watermarking.
Liang et al. (Patterns 2023) showed detectors are biased against non-native English writers and trivially bypassable by prompting.

Specificity is camouflage. The "real technical detail" that makes a synthetic comment feel human is the same mechanism that blinds the detector.

What actually survived

One result, and it is the only one I found that held up. In a within-author comparison — each writer against their own baseline, to strip out audience size — every stylistic effect collapsed to roughly zero:

title pattern	effect on reactions
first person ("I", "my")	−0.08
listicle / numbered list	−0.08
question mark	−0.08
colon	0.00

The phrasing was never doing the work. It was a marker of which kind of account was posting. What survived was the tag choice and whether anyone was already reading you.

So the strategy inverts: do not optimise the post, build the reason to read the next one. That means a profile with a real website on it, an identity, and a reason to follow. The post is the entry point, not the asset.

The uncomfortable part

The bots are a demand signal. Nobody funds a content operation against one keyword cluster, twice a day, indefinitely, for nothing. That cluster converts into affiliate revenue, lead generation, or SEO authority someone intends to sell. Automated capital farming a topic is downstream evidence the topic has money in it.

The inversion is that once the commentary layer is mostly machines, the genuine builders are not a slice of the audience — they are the whole of it, and they are rare. Which is why the number to watch is not reactions. It is whether the people who come back brought something specific with them.

All measurements above use dev.to's public API and are reproducible by anyone with the same queries. The scripts are public: analyze_devto.py and sweep_devto.py.

A free AI chat that costs me nothing: BYOK on Cloudflare Workers AI

Bartosz Osiej — Tue, 13 Oct 2026 16:53:29 +0000

TL;DR

There is no free tier that stays free. The usual answer is to buy credits and hope. There is another: make the user pay, using their own key. Workers AI gives out tokens; you relay the request. You pay $0, you never store a credential you didn't already hand you, and the abuse story collapses into "revoke your own token."

This is the architecture I used for the chat on ai.hartwell-labs.pl. It took an afternoon. The auth was twenty lines. The thing that actually broke me twice was something else entirely.

The shape

A Worker with no AI binding at all. It never touches a model on your behalf — it forwards the caller's own credentials:

async function handleChat(request) {
  const body = await request.json();
  const cfg = body.config;          // { provider, apiKey, accountId, model }

  if (!cfg.apiKey || cfg.apiKey.length < 8) return bad(400, "no_key");

  // Optional: confirm the token can actually list accounts
  const a = await fetch(
    "https://api.cloudflare.com/client/v4/accounts?per_page=1",
    { headers: { authorization: `Bearer ${cfg.apiKey}` } }
  );
  const ad = await a.json();
  if (!ad.success) return bad(400, "bad_token", ad.errors?.[0]?.message);

  const upstream = await fetch(BUILDERS[cfg.provider](cfg), {
    method: "POST",
    headers: { "content-type": "application/json", ...HEADERS[cfg.provider](cfg) },
    body: JSON.stringify({ model: cfg.model, stream: true, messages: body.messages }),
  });
  return new Response(upstream.body, { status: upstream.status, headers: { "content-type": "text/event-stream" } });
}

That is genuinely the whole backend. Token lives in localStorage, goes up with each request, comes back down with the stream. The Worker holds nothing between calls.

Two details that matter more than the auth code:

Account discovery removes a step. /client/v4/accounts?per_page=50 with the user's token returns their accounts. You auto-select the first, store it, and never show a picker. The user pastes a token and starts typing. One interaction, not three.

Failure messages are the product. Cloudflare answers a bad token with 6003: Invalid request headers / 6111: Invalid format for Authorization header — which is a genuinely terrible thing to show a human who has pasted the wrong kind of credential. Map it to something actionable:

if (msg.includes("Invalid format for Authorization header")) {
  return bad(400, "bad_token",
    "Token format invalid — use a scoped API Token (not Global API Key). " +
    "Create at: dash.cloudflare.com → My Profile → API Tokens → " +
    "Create Token → Account · Workers AI · Read");
}

Most people who paste a Global API Key into an OAuth-shaped field are not going to read an error code. They will read that sentence.

The bug that cost me an hour

The model emits structured directives — this one edits a rich-text notepad in the browser:

Zapisuję.
[notepad action=new doc="Zakupy"]
- mleko
- chleb
[/notepad]

The client strips the tags and applies them. Simple, and it worked fine in testing with a complete response.

It failed in production, live, in the one place I never tested: while the bytes were still arriving.

Streaming means you re-render on every chunk. At some instant the accumulated buffer is:

Zapisuję.

- mleko
- chleb
[/notepad

The closing tag is half-formed. Every sensible "strip the complete directive" regex fails to match, because a complete directive is by definition not what's on screen yet. So the note contents — the part the user explicitly asked to be filed away — flash through the chat as a stray bullet list.

The fix is to give up on parsing completeness and delete everything after the opening tag:

function stripDirectives(t) {
  return String(t || "")
    .replace(/\[notepad\b[^\]]*\][\s\S]*?\[\/notepad\]/gi, "")  // complete block
    .replace(/\[notepad\b[^\]]*\][\s\S]*$/gi, "")             // partial — from the tag to EOF
    .replace(/\[notepad\b[^\]]*\]/gi, "")
    .replace(/\[\/notepad\]/gi, "")
    .trim();
}

The second rule is the whole lesson. In a stream, an unterminated construct is not "not yet valid" — it is already visible. Treat anything from the opening delimiter onward as untrusted, every frame, and overwrite your buffer rather than patching it. Any renderer that accumulates and incrementally parses will eventually show you a half-built structure to the user.

What it costs

The free tier is 10,000 neurons per day. @cf/meta/llama-3.3-70b-instruct-fp8-fast against a ~700-word system prompt plus a short exchange costs roughly 1,200–1,500 neurons per turn. I found this the honest way: the suite passed all morning, then returned

AiError: you have used up your daily free allocation of 10,000 neurons

on every single call. Latency sat at 5–10 seconds per turn — fast enough to feel real, slow enough that a user will notice. Both numbers are worth publishing, because "free AI chat" otherwise sounds like a promise instead of a budget.

BYOK doesn't make the model free. It makes the bill yours — which is the only version of "free" that survives contact with a real user base.

Worker source for the chat lives at ai.hartwell-labs.pl. Everything else I write is public — github.com/BartoszOsiej.

DEV Community: Bartosz Osiej

Linux Process Monitoring: From /proc to eBPF

Three generations

Generation 1: /proc polling

Generation 2: ptrace/exec

Generation 3: eBPF tracepoints

Fleet: the missing third act

Fleet Monitoring for Linux: Managing 100+ Servers Without Kubernetes

The misconception

Why agents that are "just a CLI" fail at fleet scale

The fleet stack (one binary, no cluster)

Deploy that survives chaos

Fleet threat detection you can actually read

Managing seats and cost

eBPF vs Traditional Monitoring: Why Kernel-Level Wins

The latency tax of polling

The overhead inversion

Accuracy: attribution that can't be faked

Response without round-trips

When traditional still wins

The kernel-level conclusion

How to Detect Ransomware Activity on Linux with eBPF

The shape of a Linux ransomware hit

Why eBPF, and not syslog or /proc

Step 1: score open-rate per process

Step 2: the canary read

Step 3: the kill guardrail

Step 4: correlate across the fleet

Tuning notes from real boxes

Doing it yourself vs Talus

Best eBPF Monitoring Tools in 2026: A Practical Comparison

TL;DR

What "ebpf monitoring tools" means today

The landscape

Falco — the CNCF default, not your laptop

Tetragon — Cilium's gift to Kubernetes

bpftrace — debugging, not guarding

Tracee — single agent, but still a project

Where Talus wins

The honest trade-off

Quick decision

Linux Process Monitoring: From /proc to eBPF

Three generations

Generation 1: /proc polling

Generation 2: ptrace/exec

Generation 3: eBPF tracepoints

Fleet: the missing third act

Fleet Monitoring for Linux: Managing 100+ Servers Without Kubernetes

The misconception

Why agents that are "just a CLI" fail at fleet scale

The fleet stack (one binary, no cluster)

Deploy that survives chaos

Fleet threat detection you can actually read

Managing seats and cost

eBPF vs Traditional Monitoring: Why Kernel-Level Wins

The latency tax of polling

The overhead inversion

Accuracy: attribution that can't be faked

Response without round-trips

When traditional still wins

The kernel-level conclusion

How to Detect Ransomware Activity on Linux with eBPF

The shape of a Linux ransomware hit

Why eBPF, and not syslog or /proc

Step 1: score open-rate per process

Step 2: the canary read

Step 3: the kill guardrail

Step 4: correlate across the fleet

Tuning notes from real boxes

Doing it yourself vs Talus

Best eBPF Monitoring Tools in 2026: A Practical Comparison

TL;DR

What "ebpf monitoring tools" means today

The landscape

Falco — the CNCF default, not your laptop

Tetragon — Cilium's gift to Kubernetes

bpftrace — debugging, not guarding

Tracee — single agent, but still a project

Where Talus wins

The honest trade-off

Generation 1: `/proc` polling

Generation 1: `/proc` polling