Observability
Profiling: free-recall review
Retrieval beats re-reading. For each prompt, say or write a full answer from memory before you open the model answer — the effort of recall is what makes the material stick.
Reconstruct the unit’s core mechanisms — sampling vs instrumentation, the profile-type map, the flame-graph axis, continuous profiling, eBPF symbolization, and sampling’s blind spots — without looking back at the lessons.
- 01Why is a sampling profiler viable for always-on production profiling while an instrumentation profiler is not?
- 02Name the main profile types and the one question each answers.
- 03What does the x-axis of a flame graph actually encode, and what is the most expensive misread?
- 04What does continuous profiling give you operationally that on-demand profiling cannot, and roughly what does it cost?
- 05Why does an eBPF profiler symbolize Go and Rust cleanly but show [unknown] frames for Python and partial frames for the JVM?
- 06Give two sampling blind spots a senior engineer must keep in mind before trusting the absence of a peak in a flame graph.
If you could reconstruct each answer from memory, you hold the unit’s spine: sampling buys bounded overhead at the price of exactness; each profile type answers one question and the CPU/wall ratio routes you to the right one; the flame-graph x-axis is alphabetical, never time; continuous profiling makes the incident’s flame graph pre-saved at 2-5%; eBPF symbolization depends on the runtime; and sampling’s blind spots (sub-interval hot paths, low-count noise) mean a missing peak is never proof of a missing bottleneck.