Tracking Extensions to New Relic

Ruby extensionsAt New Relic, we strive to instrument the most common gems our Ruby customers use. However, there are always gaps – whether it’s a new library rising in popularity or a critical niche for your application, there’s always room for more instrumentation.

Thankfully, a lot of people in the community have stepped up to help us with that. There are at least a couple dozen gems that extend New Relic, bringing the monitoring goodness to other frameworks. But this great ecosystem means that changes in newrelic_rpm can potentially impact a whole other type of code. Libraries tend to use more of our internal APIs and exercise the agent in ways monitored applications rarely do.

The bottom line is that renaming, moving or removing classes and methods in the Ruby agent can easily break other libraries. Since our documentation doesn’t clearly spell out what is considered ‘public’ in our API (something else we’re working on!), it was difficult to tell what changes were safe.

Today we’ve taken a step toward fixing that. We’ve released a repository on GitHub called extends_newrelic_rpm. The repository links via git submodules to gems building off newrelic_rpm. It is seeded with the gems we’re aware of and we have a process watching rubygems.org for new gems that depend on us. We’re also happy to take pull requests if any gem gets missed in the sweep. While the Ruby agent team does not actively test or support these gems, we definitely use the repo when researching code renames and deletions.

Are you looking for additional instrumentation for New Relic? Have you authored a gem that adds valuable metrics into New Relic? Check out extends_newrelic_rpm and let us know how it’s working for you!

View posts by .

Interested in writing for New Relic Blog? Send us a pitch!