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!
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:
Appsignal.instrument_sql
convenience method.- Log to STDOUT option for almost all parts of the agent.
- A fix for the
--name
option in theappsignal notify_for_deploy
command. - Fix JavaScript exceptions names without names resulting in an error themselves.
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!