Active Support notifications: spike/design work for an overhaul that will potentially require a major agent version bump
fallwith opened this issue · comments
As discussed on #2610, #2610's work done to provide an allowlist of Active Support notifications event names really only scratches the surface of what would be possible with a comprehensive notifications instrumentation overhaul. Ruby on Rails is our most significant instrumented library and we use notification subscriptions to power all of our Rails instrumentation. So any work done in this area has a very high return on investment as far as customer value and adoption goes.
At a high level, we can challenge the current siloing of instrumentation based on Rails libraries (one silo per library) and explore a more holistic approach for notifications based instrumentation. Our agent and therefore its silo pattern predates Rails' support for notifications, so it is understandable that the same siloing continued when notifications came along. And certainly there may be more pros than cons to siloing. But we should do some research and develop some proofs of concept for testing that could help us either appreciate or challenge the siloing pattern.
We could explore at least all of the following:
- Performing subscriptions that apply to multiple Rails libraries, and leaving us with fewer subscriptions overall (saves a bit of memory if nothing else).
- Revisit our common-across-all-libraries
startandstopevent processing methods to see if anything more can be done than we are currently accomplishing with basic class inheritance. - Permit customers to define allowlists and denylists of either complete or partial event names that would be applicable across all Rails event types for all libraries.
- Performance benefits that come from more specific subscription patterns than our current "give me all the events for this Rails library" approach taken with each subscription.
