You have likely been there. A process is acting strange, the logs show absolutely nothing useful, and strace just makes the app hang or crash because of the ptrace overhead. This is where most people give up and restart the service, hoping the issue clears itself. But that is just kicking the can down the road while you ignore the actual kernel events that are likely hiding in plain sight.

Why your current observability stack is missing the point

Most logs record what the application thinks it did. That is not the same as what the kernel actually executed. When a process hits a race condition or a silent permission denial at the syscall boundary, journald just sits there idling. Using eBPF tracing tools like opensnoop lets you watch exactly what file handles a process is opening in real-time, without having to attach a debugger that interrupts the process flow.

sudo opensnoop -p $(pgrep -n my-misbehaving-app)

• opensnoop tracks the open syscall across your entire system or filtered by PID
• It uses eBPF to hook directly into the kernel return path so it carries almost zero latency penalty
• You catch hidden file access errors like EACCES or ENOENT that logs never report

The beauty here is that you don’t need to rebuild your application with extra instrumentation or enable verbose debug logs that fill up your disk. Just point the trace at the PID and see the reality of what the kernel sees. If you are still relying purely on application-level logs, you are effectively running blind whenever the kernel decides to kill a request before your code even sees it. Keep a BCC tools package installed on your core servers for exactly these moments.