Visit AppSignal.com

Gem 2.0 released 🎉

Tom de Bruijn on

Welcome back appsignal gem user!

We just released gem version 2.0 which removes our dependency on ActiveSupport, improves our support for Grape namespaces and automatically detects if an application is running in a container system. We’ve also made sure to speed up our (already fast) gem and changed the way the AppSignal configuration is loaded.

ActiveSupport dependency removed

In previous versions of the gem, we relied on ActiveSupport::Notifications for instrumentation. This was a great fit for Rails apps, as they depend on ActiveSupport. For non-Rails apps, we added it as a dependency in the AppSignal gem.

Since version 1.3 our gem comes with our own instrumentation, Appsignal.instrument. And in version 2.0 we’ve removed the dependency on ActiveSupport, to allow for a more flexible implementation without the overhead of having an extra dependency.

From now on, we recommend using Appsignal.instrument for custom instrumentation. However, you can still use ActiveSupport::Notifications, but you have to make sure to depend on it yourself if you’re not using Rails. If you are, custom instrumentation will work like before without any changes.

Performance improvements

We improved the performance of the AppSignal gem! Now it’s even faster at generating the payloads that are sent to the AppSignal servers. It’s also creating fewer objects and allocating less memory, reducing garbage collection time.

For applications that use ActiveSupport instrumenting, AppSignal will also have a few milliseconds less overhead due to the more lightweight way we’re now listening for events.

Grape namespace support

When using namespaced routes in your Grape applications you might have missed a namespaced path in the URIs inside the AppSignal event tree. Routes like /api/accounts would instead be shown as /accounts, missing the namespace path. You can now see the whole path of the requests.

Container detection

Since 2.0, the gem automatically detects Docker and Heroku containers, so you don’t have to set the running_in_container configuration anymore. The gem will make sure to automatically stop the agent when your app shuts down, so it doesn’t stay alive longer than it should.

Now you don’t have to set this configuration anymore, the gem automatically detects Docker and Heroku containers for you. 🚀

Diagnose improvements

The appsignal diagnose command is our primary tool we use when we debug what’s wrong with a particular configuration. Now the diagnose output is even more complete and readable. It looks a lot better too!

appsignal diagnose

Try running appsignal diagnose if you think something is wrong with your setup and let us know if you need help.

Configuration load order changes

The configuration load order has been changed in this version. From now on environment variables will be the last type of configuration you can set. Previously the appsignal.yml configuration file was loaded last, possibly overriding any configuration you may have set in the environment. Something which is common for applications hosted systems like Heroku.

This load order wasn’t what we had in mind. Now the environment variables are loaded after the configuration file, overriding configuration from any previous step.

Read more about our configuration load order in our documentation.


Furthermore this release includes some other additions and refactorings of internals, such as:

See the change log for more details about these improvements, removed deprecations and more.

Be sure to get in touch with us if you run into problems after upgrading.

Enjoy!

10 latest articles

Go back

Subscribe to

Ruby Magic

Magicians never share their secrets. But we do. Sign up for our Ruby Magic email series and receive deep insights about garbage collection, memory allocation, concurrency and much more.