The Problem: "It's Slow, but Why?"
Imagine your car's dashboard only has a single warning light labeled "Problem." You know something is wrong, but you have no idea if it's the engine, the brakes, or the fuel pump. Traditional Linux monitoring tools like top, htop, and free are that single warning light. They tell you that your CPU usage is high or your memory is full — but they rarely tell you why.
Is the database slow because of bad disk I/O? Is the web server slow because it's waiting on a network connection? Is a background process constantly failing and restarting, consuming CPU in short bursts that top never catches?
The Linux kernel is the massive, complex engine running everything on your system. Normally, it's a black box: you can see its outputs (CPU %, memory used, load average) but not its internal mechanics. Observability is the discipline of opening that box and watching the gears turn in real-time — without stopping the engine. It's about moving from "the server is slow" to "the mysqld process is blocked waiting on file descriptor 45, which maps to a slow network socket to IP 10.0.0.5, and it's been waiting an average of 340ms per query."
This lesson traces the evolution of Linux observability tooling — from the blunt instrument of strace, through the packet-level visibility of tcpdump, to the revolutionary programmable kernel observability enabled by eBPF. Each tool exists on a spectrum of overhead, specificity, and power. Knowing which to reach for, and when, is a core SRE and platform engineering skill.