Instrumenting Rails

Rails is already telling you everything — you just aren't listening

Every SQL query, every controller action, every cache hit or miss inside a running Rails app fires an event through ActiveSupport::Notifications — Rails' built-in pub/sub bus. You don't have to add anything to get these events; Rails emits them whether you're watching or not. subscribe is how you start watching: give it an event name and a block, and that block runs every time the event fires, anywhere in the app.

This is the same idea as the Python course's observability module (three pillars: logs, metrics, traces) — this lesson is that same idea, one layer down, using the instrumentation Rails ships with instead of a Python library.

The event names follow a action.library pattern: sql.active_record fires for every query, and process_action.action_controller fires once per controller action (with the render time, DB time, and status baked in). Each sql.active_record payload carries the query and how long it took, so subscribing and checking the duration is exactly how you'd catch a slow query in production without ever attaching a profiler.