Free — no signup required

Introduction: The Black Box Problem

2 min read

The Visibility Gap

You have deployed your application. It is running slow.

Think of your observability tools like instruments in a hospital. A heart rate monitor tells you that something is wrong. A patient chart tells you what symptoms occurred. A timeline of events tells you when things happened. But none of them tell you why the heart is racing — for that, you need an imaging scan that looks inside.

That is exactly the gap in traditional observability:

  • Metrics tell you that CPU usage is 95%.
  • Logs tell you what requests are happening.
  • Traces tell you how long requests take end-to-end.

But none of them tell you why the CPU is at 95%. Is it the garbage collector? Is it JSON parsing? Is it a catastrophically slow regular expression? You are staring at the outside of a black box.

Enter eBPF Profiling

Traditionally, to answer the "why" question, you had to stop the application, attach a heavy debugger, restart it, and then try to reproduce the issue — often in a staging environment that behaves differently from production. By the time you have set up the tooling, the spike is gone.

eBPF (Extended Berkeley Packet Filter) changes this entirely. eBPF is a technology built into the Linux kernel that allows you to run small, safe, sandboxed programs inside the kernel itself — without modifying kernel source code and without loading kernel modules. Think of it as a programmable hook that the kernel exposes to trusted observers.

With eBPF-based profiling, you can observe every function call your CPU executes across the entire operating system — across every process, every container, every language runtime — with zero code changes to your application and negligible performance overhead (typically under 1% CPU). It is the equivalent of X-ray vision for your server: you can see through the walls of every container and into the bones of every process.

Why This Matters for SRE and Platform Engineering

The shift eBPF enables is from reactive debugging (something broke, now investigate) to continuous visibility (always know what every process is doing). This is the foundation of modern performance engineering. When you can see inside every service at all times, you stop guessing and start knowing.

Interview Tip

Interviewers often ask: "What is the difference between tracing and profiling?" Tracing follows a single request through a distributed system (latency per hop). Profiling samples all running code to find which functions consume the most resources across all requests. They are complementary: tracing tells you which service is slow; profiling tells you which function inside that service is the cause.

This is one of 18 chapters

Every chapter is free — Kubernetes, Terraform, SRE, distributed systems, and more — with fast daily review built in.

Sign up free