Stop eBPF from hiding the silent killers in your syscalls

Technical Briefing | 8/10/2026

You probably think your logs tell the whole story. I used to think that too, until I spent three days hunting a race condition that never actually hit the disk. The problem is that standard logging only catches what the application chooses to report. If a syscall returns an error but the application developer didn’t bother to log it, you’re just staring at a ghost in the machine. That is where eBPF stops being a buzzword and starts being a shovel.

When the logs lie to you

Most of the time, your stack is just fine. But when you are tracking down an intermittent ‘permission denied’ or a weird ‘file not found’ error that happens once every few thousand requests, standard auditd rules will burn your CPU to a crisp. You need to hook into the kernel’s own view of events. By attaching a probe directly to the syscall interface, you can see exactly what the kernel sees, regardless of whether the user-space process is trying to hide its tracks or just failing to report the failure.

bpftrace -e 'tracepoint:syscalls:sys_enter_openat { printf("process %s called openat for file %s\n", comm, str(args->filename)); }'

• Use bpftrace to filter by specific PIDs if you only care about one problematic worker process
• Watch the return values instead of just entry points to see which calls actually hit a wall
• Keep your probe programs short to avoid stalling the kernel execution path

This isn’t about setting up a heavy monitoring suite you will ignore for six months. It is about grabbing a surgical tool when the application logs hit a dead end. Next time you have a process acting up and the application logs show absolutely nothing useful, stop grepping /var/log and start looking at what the kernel is doing. It might save you from another night of frantic debugging.