Hello! I would like to kick off an instrumentation working group for Rails. I work at Skylight and so this is obviously a topic that we are quite interested in.
Over the years, we have accumulated a few patches in our agent that we would like to upstream into Rails. For example, here is a pull request we submitted recently to provide better information about the layout in views instrumentation.
Most of the change are relatively minor and uncontroversial. However, to avoid breaking other consumers of the instrumentation APIs and to avoid any conflict-of-interest, I would like to make an open call to maintainers of other instrumentation libraries, so that we can get more eyes on these reviews and discuss any potential breakage.
To start, I suggest that anyone who is interested in discussing or reviewing such these changes/issues could reply to this thread with a short introduction and your GitHub handle, the latter is needed so others would know who to ping on GH when submitting a PR in this area.
Beyond the initial scope of upstreaming our patches – and I invite other maintainers to do the same too – I think there are probably more work we can do together in this area. For instance, I know @samsaffron has some specific ideas for improvements in this area as well. I’ve created the “instrumentation” tag in rubyonrails-core for this purpose, so feel free to start new topics under that if you have anything to propose.
Thank you for taking the time to start this! I’m Chris Schneider @ ScoutAPM (@cschneid on GitHub). We are cross-language, but our original and still largest customer base is using Rails.
We make relatively light use of the official instrumentation APIs, preferring instead to take full control, for better or worse, and monkey patch our way into key spots in both Rails itself, and 3rd party libraries. This has certainly caused issues in the past with compatibility with other gems that also insert themselves in similar ways, but the detail and control we obtain has generally been worth it. If the instrumentation APIs could expand to encompass more data, it would allow us to minimize that more dangerous approach, but I haven’t taken a close look at what that would require.
I’ll be watching the new instrumentation tag, and taking a look at what we do that would make for a good patch to Rails.
We take a similar approach to what @cschneid described to provide exception tracking in Rails. We do not currently do APM, but are definitely interested in instrumentation APIs.
I’ve subscribed to the tag. Thanks for organizing this!
Hi, Thijs from AppSignal here. Also happy you took this initiative! We rely on AS notifications partly, and also monkey patch a fair bit. Looking forward to collaborating!
David here from Sentry. I’m going to be observing from the distance but will pull in some other Sentry folks.
We’re mostly interested in high performance APIs to aid with what we can already do by patching frameworks. I’d love want to see Ruby perform at least at Pythons level from a reflection-style-in-production data collection POV, and am interested in seeing what we can do to create more native hooks within the ecosystem as a whole. While the core of our product has been error monitoring (across every runtime these days), we’ve spent the last year investing into a tracing-based architecture to expand that dataset to broader performance concerns.
In general, hoping we can get the Skylight folks to continue pulling in their expertise to make the core great!
It certainly alleviates most of the overhead concerns many frameworks (including rails instrumentation) have given it leans directly on accurately named method names and pure Ruby based module inclusion.
Testing can be a bit challenging and removing instrumentation once added is a huge adventure. That said I think everyone on this topic should have a look and a think about the pattern.
