![]() This may cause other initializers to behave differently. This fix provides an option to split initialization into two parts: load add_method_tracer before application-defined initializers and start the agent after application-defined initializers. However, this had the side-effect of forcing some framework libraries to load before initializers ran, preventing any configuration values related to these libraries from being applied. This allowed initializers to reference the add_method_tracer API. In Rails, the agent previously loaded before any application-defined initializers. We appreciate your help! Issue#1650 PR#1673īugfix: Defer agent startup in Rails until after application-defined initializers have run Thank you very much to our community members and for bringing this issue to our attention, for helping us determine how to best reproduce it, and for testing out the update. Secondly, the agent will no longer crash or impact the monitored application in the event that the database index cannot be obtained. Firstly, support for RedisClient versions older than v0.11 has been added to get at the database index value. Version 8.14.0 adds two related improvements. With versions of RedisClient older than v0.11, the agent could cause the monitored application to crash when attempting to determine the Redis database index. With version 8.13.0 of the agent, support was added for the redis-rb gem v5+ and the new RedisClient gem. PR#1659īugfix: Support older versions of the RedisClient gem, handle unknown Redis database index Creating custom events is simple and now reporting instrumentation for them to New Relic is simple as well. When the new active_support_custom_events_names configuration parameter is set equal to an array of custom event names to subscribe to, the agent will now subscribe to each of the names specified and report instrumentation for the events when they take place. Support for Rails ActiveSupport::Notifications for custom events Many thanks to for contributing this optimisation and the benchmarks to support it! PR#1693 Doing so has resulted in a performance gain for the generation of GUIDs. Given that those 16^16 and 32^32 operations are expected, it makes sense to calculate their results up front and store them in constants to be referred to later. The agent leverages random numbers in its GUID (globally unique identifier) generation and would previously always freshly calculate the result of 16^16 or 32^32 before generating a random number. Thank you very much for your contribution, ! PR#1653 Community member spotted and corrected this change in order to restore the desired changelog lookup functionality while retaining all of the previous cleanup. The recipe code was significantly cleaned up with PR#1498 which inadvertently changed the way the recipe handles the changelog for a deployment. ![]() The New Relic Ruby agent offers a Capistrano recipe for recording app deployments. Version 8.14.0 of the agent restores desired Capistrano-based changelog lookup functionality when a deployment is performed, speeds up GUID generation, delivers support for instrumenting Rails custom event notifications, fixes potential compatibility issues with the RedisClient gem, and fixes bugs related to initialization in Rails.ĭeployment Recipe: Restore desired Capistrano-based changelog lookup behavior Read more about keeping your agent up to date.Īs of this release, the oldest supported version is 6.8.0.359 v8.14.0 If your organization has established practices that prevent you from upgrading to the latest version, ensure that your agents are regularly updated to a version at most 90 days old. We recommend updating to the latest agent version as soon as it's available.
0 Comments
Leave a Reply. |