Digging Deep with ActiveSupport::Notifications
summary
ActiveSupport::Notifications (Rails 3+) provides evented instrumentation: you fire instruments and register subscribers that receive name, start/end, id and a payload hash; block form yields automatic duration and exception name/message. Rails already emits process_action.action_controller (controller, action, format, status, view/db timing) and SQL.active_record (every query, SQL, duration, name), so you can log to Papertrail, send metrics to StatsD or New Relic, stash explain plans for slow queries, toggle per-customer collection with rollout, and beware subscribers run synchronously unless you replace the dispatcher.
AI-written summary · about
chapters (19)
- 0:00Introduction
- 1:09What are ActiveSupport::Notifications
- 3:17Why it matters
- 5:02Subscribers and instrumentation
- 8:36Rails events to use now
- 10:19Controller events examples
- 12:51Tracking ActiveRecord queries
- 14:56Turning insights into action
- 15:38Sending data to monitoring
- 18:25Performance considerations
- 21:35Conditional instrumentation with Rollout
- 23:21Notifications with Campfire
- 24:24Simpler instrumentation syntax
- 25:07LogSubscriber for cleaner code
- 26:51Using outside Rails
- 27:55Gems using this pattern
- 29:40Projects using notifications
- 31:48Best practices
- 33:10Summary
related talks
17mActiveSupport::Notifications and Live Status Pages
32mMake an Event of It
01h 39mHow to instrument your Rails app with OpenTelemetry
21mBuilding a Performance Analytics Tool with ActiveSupport
42mPowerful Rails Features You Might Not Know
32mWhat’s my App *Really* Doing in Production?
26mRails Performance Monitoring 101: A Primer for Developers
28mMonitoring Rails apps using Open Source