Notes
Support for synthetic monitors
The Ruby agent now gives you additional information for requests from synthetic monitors. More transaction traces and events give you a clearer look into how your application is performing around the world.
For more details, see https://docs.newrelic.com/docs/synthetics/new-relic-synthetics/getting-s...
Support for multiple job per fork gems with Resque
The resque-jobs-per-fork and resque-multi-job-forks gems alter Resque to fork every N jobs instead of every job. This previously caused issues for the Ruby agent, but those have been resolved. These gems are fully supported.
Running Resque with the FORK_PER_JOB=false environment variable setting is also supported now.
For more details on our Resque support, see https://docs.newrelic.com/docs/agents/ruby-agent/background-jobs/resque-...
Support agent when starting Resque Pool from Rake task
When running resque-pool with its provided rake tasks, the agent would not start up properly. Thanks Tiago Sousa for the fix!
Fix for DelayedJob + Rails 4.x queue depth metrics
The Ruby agent periodically records DelayedJob queuedepth as a metric, but this didn't work properly in Rails 4.x applications. This has been fixed. Thanks Jonathan del Strother for his help with the issue!
Fix for failure in background transactions with rules.ignore_url_regexes
The recently added feature for ignoring transactions via URL regexes caused errors for non-web transactions. This has been fixed.
Rename the TransactionNamer.name method to TransactionNamer.name_for
The internal TransactionNamer class had a class method called 'name', with a different signature than the existing Class#name method and could cause problems when trying to introspect instances of the class.
Thanks to Dennis Taylor for contributing this fix!
Notes
Rails 4.2 ActiveJob support
A new version of Rails is coming! One of the highlight features is ActiveJob, a framework for interacting with background job processors. This release of the Ruby agent adds instrumentation to give you insight into ActiveJob, whether you're just testing it out or running it for real.
Metrics are recorded around enqueuing ActiveJobs, and background transactions are started for any ActiveJob performed where the agent didn't already provide specific instrumentation (such as DelayedJob, Resque and Sidekiq).
Since Rails 4.2 is still in beta we'd love to hear any feedback on this instrumentation so it'll be rock solid for the general release!
Ruby 2.2.0-preview1 updates
Ruby 2.2.0 is on its way later in the year, and the Ruby agent is ready for it. Updates to the GC stats and various other small changes have already been applied, and our automated tests are running against 2.2.0 so the agent will be ready on release day.
Ignoring transactions by URL
While you could always ignore transactions by controller and action, the Ruby agent previously lacked a way to ignore by specific URLs or patterns without code changes. This release adds the config setting,
rules.ignore_url_regexes
to ignore specific transactions based on the request URL as well. For more information, see the documentation at: https://docs.newrelic.com/docs/agents/ruby-agent/installation-configurat...Better dependency detection in non-Rack applications
The Ruby agent runs dependency detection at key points in the Rack and Rails lifecycle, but non-Rails apps could occasionally miss out instrumenting late loaded libraries. The agent now runs an additional dependency detection during manual_start to more seamlessly install instrumentation in any app.
Excluding /newrelic routes from developer mode
Recent changes to track time in middleware resulted in New Relic's developer mode capturing its own page views in the list. This has been fixed. Thanks to Ignatius Reza Lesmana for the report!
Spikes in external time
Timeouts during certain external HTTP requests could result in incorrect large spikes in the time recorded by the agent. This has been fixed.
Recognize browser_monitoring.auto_instrument setting in non-Rails apps
The
browser_monitoring.auto_instrument
config setting disables auto-injection of JavaScript into your pages, but was not properly obeyed in Sinatra and other non-Rails contexts. This has been fixed.Failures to gather CPU thread time on JRuby
JRuby running on certain JVM's and operating systems (FreeBSD in particular) did not always support the method being used to gather CPU burn metrics. This would result in a failure during those transactions. This has been fixed.
Fix for rare race condition in Resque instrumentation
A race condition in the agent's Resque instrumentation that could cause rare Resque job failures in high-throughput Resque setups has been fixed. This bug would manifest as an exception with the following error message: "RuntimeError: can't add a new key into hash during iteration" and a backtrace leading through the PipeChannelManager class in the agent.
Importante
The end-of-life date for this agent version is July 29, 2019. To update to the latest agent version, see Update the agent. For more information, see End-of-life policy.
Notes
Per-dyno data on Heroku
When running on Heroku, data from the agent can now be broken out by dyno name, allowing you to more easily see what's happening on a per-dyno level. Dynos on Heroku are now treated in the same way that distinct hosts on other platforms work.
By default, 'scheduler' and 'run' dyno names will be aggregated into
scheduler.*
andrun.*
to avoid unbounded growth in the number of reported hostnames.Read more about this feature on our Heroku docs page: https://docs.newrelic.com/docs/agents/ruby-agent/miscellaneous/ruby-agen...
HTTP response codes in Insights events
The Ruby agent will now capture HTTP response codes from Rack applications (including Rails and Sinatra apps) and include them under the httpResponseCode attribute on events sent to Insights.
Stricter limits on memory usage of metrics and SQL traces
The agent now imposes stricter limits on the number of distinct SQL traces and metrics that it will buffer in memory at any point in time, leading to more predictable memory consumption even in exceptional circumstances.
Improved reliability of thread profiling
Several issues that would previously have prevented the successful completion and transmission of thread profiles to New Relic's servers have been fixed.
These issues were related to the use of recursion in processing thread profiles, and have been addressed by both limiting the maximum depth of the backtraces recorded in thread profiles, and eliminating the agent's use of recursion in processing profile data.
Allow tracing Rails view helpers with add_method_tracer
Previously, attempting to trace a Rails view helper method using add_method_tracer on the view helper module would lead to a NoMethodError when the traced method was called (undefined method `trace_execution_scoped'). This has been fixed.
This issue was an instance of the Ruby 'dynamic module inclusion' or 'double inclusion' problem. Usage of add_method_tracer now no longer relies upon the target class having actually picked up the trace_execution_scoped method from the NewRelic::Agent::MethodTracer module.
Improved performance of queue time parsing
The number of objects allocated while parsing the frontend timestamps on incoming HTTP requests has been significantly reduced.
Thanks to Aleksei Magusev for the contribution!
Importante
The end-of-life date for this agent version is July 29, 2019. To update to the latest agent version, see Update the agent. For more information, see End-of-life policy.
Notes
Allow agent to use alternate certificate stores
When connecting via SSL to New Relic, the Ruby agent verifies its connection via a certificate bundle shipped with the agent. This caused problems with certain proxy configurations, so the
ca_bundle_path
setting in newrelic.yml can now override the default cert bundle location.For more information, see custom SSL certificates
Rails 4.2 beta in tests
Although still in beta, a new version of Rails is on its way! We're already running our automated test suites against the beta to ensure New Relic is ready the day the next Rails is released.
ActiveRecord 4 cached queries fix
Queries against the ActiveRecord 4.x query cache were incorrectly being counted as database time by the agent.
Fix for error in newrelic.yml loading
If your application used a
RAILS_ENV
value that was not listed in newrelic.yml recent agent versions would return a NameError rather than a helpful message. This has been fixed. Thanks Oleksiy Kovyrin for the patch!
Importante
The end-of-life date for this agent version is July 29, 2019. To update to the latest agent version, see Update the agent. For more information, see End-of-life policy.
Notes
Fix to prevent proxy credentials transmission
This update prevents proxy credentials set in the agent config file from being transmitted to New Relic.
Importante
The end-of-life date for this agent version is July 29, 2019. To update to the latest agent version, see Update the agent. For more information, see End-of-life policy.
Notes
Added API for ignoring transactions
This release adds three new API calls for ignoring transactions:
NewRelic::Agent.ignore_transaction
NewRelic::Agent.ignore_apdex
NewRelic::Agent.ignore_enduser
ignore_transaction
ignores a transaction completely: nothing about it will be reported to New Relic.ignore_apdex
ignores only the Apdex metric for a single transaction.ignore_enduser
disables Javascript injection for browser monitoring for the current transaction.These methods differ from the existing
newrelic_ignore_*
method in that they may be called during a transaction based on some dynamic runtime criteria, as opposed to at the class level on startup.For more information, see ignoring specific transactions.
Improved SQL obfuscation
SQL queries containing string literals ending in backslash
\
characters were not correctly obfuscated by the Ruby agent prior to transmission to New Relic. In addition, SQL comments were left un-obfuscated. This has been fixed, and the test coverage for SQL obfuscation has been improved.newrelic_ignore*
methods now work when called in a superclassThe
newrelic_ignore*
family of methods previously did not apply to subclasses of the class from which it was called, meaning that Rails controllers inheriting from a single base class wherenewrelic_ignore
had been called would not be ignored. This has been fixed.Fix for rare crashes in
Rack::Request#params
on Sinatra appsCertain kinds of malformed HTTP requests previously caused unhandled exceptions in the Ruby agent's Sinatra instrumentation, in the
Rack::Request#params
method. This has been fixed.Improved handling for rare errors caused by timeouts in Excon requests
In some rare cases, the agent would emit a warning message in its log file and abort instrumentation of a transaction if a timeout occurred during an Excon request initiated from within that transaction. This has been fixed.
Improved behavior when the agent is misconfigured
When the agent is misconfigured by attempting to shut it down without it ever having been started, or by attempting to disable instrumentation after instrumentation has already been installed, the agent will no longer raise an exception, but will instead log an error to its log file.
Fix for
ignore_error_filter
not working in some configurationsThe
ignore_error_filter
method allows you to specify a block to be evaluated in order to determine whether a given error should be ignored by the agent. If the agent was initially disabled, and then later enabled with a call tomanual_start
, theignore_error_filter
would not work. This has been fixed.Fix for Capistrano 3 ignoring
newrelic_revision
New Relic's Capistrano recipes support passing parameters to control the values recorded with deployments, but user-provided
:newrelic_revision
values were incorrectly overwritten. This has been fixed.Agent errors logged with ruby-prof in production
If the ruby-prof gem was available in an environment without New Relic's developer mode enabled, the agent would generate errors to its log. This has been fixed.
Tighter requirements on naming for configuration environment variables
The agent would previously assume any environment variable containing
NEWRELIC
was a configuration setting. It now looks for this string as a prefix only.Thanks to Chad Woolley for the contribution!
Importante
The end-of-life date for this agent version is July 29, 2019. To update to the latest agent version, see Update the agent. For more information, see End-of-life policy.
Notes
Ruby 1.8.7 users: upgrade or add JSON gem now
Ruby 1.8.7 is end-of-lifed, and not receiving security updates, so we strongly encourage all users with apps on 1.8.7 to upgrade.
If you're not able to upgrade yet, be aware that a coming release of the Ruby agent will require users of Ruby 1.8.7 to have the 'json' gem available within their applications in order to continue sending data to New Relic.
Support for new Cross Application Trace view
This release enhances cross application tracing with a visualization of the cross application calls that a specific Transaction Trace is involved in. The new visualization helps you spot bottlenecks in external services within Transaction Traces and gives you an end-to-end understanding of how the transaction trace is used by other applications and services. This leads to faster problem diagnosis and better collaboration across teams. All agents involved in the cross application communication must be upgraded to see the complete graph. You can view cross application traces from in the Transaction Trace drill-down.
High-security mode v2
The Ruby agent now supports v2 of New Relic's high-security mode. To enable it, you must add 'high_security: true' to your newrelic.yml file, and enable high-security mode through the New Relic web interface. The local agent setting must be in agreement with the server-side setting, or the agent will shut down and no data will be collected.
Customers who already had the server-side high-security mode setting enabled must add 'high_security: true' to their agent configuration files when upgrading to this release.
For details on high-security mode, see: http://docs.newrelic.com/docs/accounts-partnerships/accounts/security/hi...
Improved memcached instrumentation
More accurate instrumentation for the 'cas' command when using version 1.8.0 or higher of the memcached gem. Previous versions of the agent would count all time spent in the block given to 'cas' as memcache time, but 1.8.0 or higher allows us to more accurately measure just the time spent talking to memcache.
Many thanks to Francis Bogsanyi for contributing this change!
Improved support for Rails apps launched from outside the app root directory
The Ruby agent attempts to resolve the location of its configuration file at runtime relative to the directory that the host process is started from.
In cases where the host process was started from outside of the application's root directory (for example, if the process is started from from '/'), it will now also attempt to locate its configuration file based on the value of Rails.root for Rails applications.
Better compatibility with ActionController::Live
Browser Application Monitoring auto-injection can cause request failures under certain circumstances when used with ActionController::Live, so the agent will now automatically detect usage of ActionController::Live, and not attempt auto-injection for those requests (even if auto-instrumentation is otherwise enabled).
Many thanks to Rodrigo Rosenfeld Rosas for help diagnosing this issue!
Fix for occasional spikes in external services time
Certain kinds of failures during HTTP requests made by an application could have previously resulted in the Ruby agent reporting erroneously large amounts of time spent in outgoing HTTP requests. This issue manifested most obviously in spikes on the 'Web external' band on the main overview graph. This issue has now been fixed.
Fix 'rake newrelic:install' for Rails 4 applications
The newrelic:install rake task was previously not working for Rails 4 applications and has been fixed.
Thanks to Murahashi Sanemat Kenichi for contributing this fix!
Importante
The end-of-life date for this agent version is July 29, 2019. To update to the latest agent version, see Update the agent. For more information, see End-of-life policy.
Notes
Rack middleware instrumentation
The Ruby agent now automatically instruments Rack middlewares!
This means that the agent can now give you a more complete picture of your application's response time, including time spent in middleware. It also means that requests which previously weren't captured by the agent because they never made it to the bottom of your middleware stack (usually a Rails or Sinatra application) will now be captured.
After installing this version of the Ruby agent, you'll see a new 'Middleware' band on your application's overview graph, and individual middlewares will appear in transaction breakdown charts and transaction traces.
The agent can instrument middlewares that are added from a config.ru file via Rack::Builder, or via Rails' middleware stack in Rails 3.0+.
This instrumentation may be disabled with the disable_middlware_instrumentation configuration setting.
For more details, see the documentation for this feature:
Capistrano 3.x support
Recording application deployments using Capistrano 3.x is now supported.
Many thanks to Jennifer Page for the contribution!
Better support for Sidekiq's Delayed extensions
Sidekiq jobs executed via the Delayed extensions (e.g. the #delay method) will now be named after the actual class that #delay was invoked against, and will have their job arguments correctly captured if the sidekiq.capture_params configuration setting is enabled.
Many thanks to printercu for the contribution!
Improved Apdex calculation with ignored error classes
Previously, a transaction resulting in an exception that bubbled up to the top level would always be counted as failing for the purposes of Apdex calculations (unless the transaction name was ignored entirely). Now, exceptions whose classes have been ignored by the error_collector.ignore_errors configuration setting will not cause a transaction to be automatically counted as failing.
Allow URIs that are not parseable by stdlib's URI if addressable is present
There are some URIs that are valid by RFC 3986, but not parseable by Ruby's stdlib URI class. The Ruby agent will now attempt to use the addressable gem to parse URIs if it is present, allowing requests against these problematic URIs to be instrumented.
Many thanks to Craig R Webster and Amir Yalon for their help with this issue!
More robust error collection from Resque processes
Previously, traced errors where the exception class was defined in the Resque worker but not in the Resque master process would not be correctly handled by the agent. This has been fixed.
Allow Sinatra apps to set the New Relic environment without setting RACK_ENV
The NEW_RELIC_ENV environment variable may now be used to specify the environment the agent should use from its configuration file, independently of RACK_ENV.
Many thanks to Mario Izquierdo for the contribution!
Better error handling in Browser Application Monitoring injection
The agent middleware that injects the JavaScript code necessary for Browser Application Monitoring now does a better job of catching errors that might occur during the injection process.
Allow disabling of Net::HTTP instrumentation
Most instrumentation in the Ruby agent can be disabled easily via a configuration setting. Our Net::HTTP instrumentation was previously an exception, but now it can also be disabled with the disable_net_http configuration setting.
Make Rails constant presence check more defensive
The Ruby agent now guards against the (rare) case where an application has a Rails constant defined, but no Rails::VERSION constant (because Rails is not actually present).
Many thanks to Vladimir Kiselev for the contribution!
Importante
The end-of-life date for this agent version is July 29, 2019. To update to the latest agent version, see Update the agent. For more information, see End-of-life policy.
Notes
Better handling for Rack applications implemented as middlewares
When using a Sinatra application as a middleware around another app (for example, a Rails app), or manually instrumenting a Rack middleware wrapped around another application, the agent would previously generate two separate transaction names in the New Relic UI (one for the middleware, and one for the inner application).
As of this release, the agent will instead unify these two parts into a single transaction in the UI. The unified name will be the name assigned to the inner-most traced transaction by default. Calls to NewRelic::Agent.set_transaction_name will continue to override the default names assigned by the agent's instrumentation code.
This change also makes it possible to run X-Ray sessions against transactions of the 'inner' application in cases where one instrumented app is wrapped in another that's implemented as a middleware.
Support for mongo-1.10.0
The Ruby agent now instruments version 1.10.0 of the mongo gem (versions 1.8.x and 1.9.x were already supported, and continue to be).
Allow setting configuration file path via an option to manual_start
Previously, passing the :config_path option to NewRelic::Agent.manual_start would not actually affect the location that the agent would use to look for its configuration file. This has been fixed, and the log messages emitted when a configuration file is not found should now be more helpful.
Importante
The end-of-life date for this agent version is July 29, 2019. To update to the latest agent version, see Update the agent. For more information, see End-of-life policy.
Notes
Better support for forking and daemonizing dispatchers (e.g. Puma, Unicorn)
The agent should now work out-of-the box with no special configuration on servers that fork or daemonize themselves (such as Unicorn or Puma in some configurations). The agent's background thread will be automatically restarted after the first transaction processed within each child process.
This change means it's no longer necessary to set the 'restart_thread_in_children setting' in your agent configuration file if you were doing so previously.
Rails 4.1 support
Rails 4.1 has shipped, and the Ruby agent is ready for it! We've been running our test suites against the release candidates with no significant issues, so we're happy to announce full compatibility with this new release of Rails.
Ruby VM measurements
The Ruby agent now records more detailed information about the performance and behavior of the Ruby VM, mainly focused around Ruby's garbage collector. This information is exposed on the new 'Ruby VM' tab in the UI. For details about what is recorded, see:
Separate in-transaction GC timings for web and background processes
Previously, an application with GC instrumentation enabled, and both web and background processes reporting in to it would show an overly inflated GC band on the application overview graph, because data from both web and non-web transactions would be included. This has been fixed, and GC time during web and non-web transactions is now tracked separately.
More accurate GC measurements on multi-threaded web servers
The agent could previously have reported inaccurate GC times on multi-threaded web servers such as Puma. It will now correctly report GC timings in multi-threaded contexts.
Improved ActiveMerchant instrumentation
The agent will now trace the store, unstore, and update methods on ActiveMerchant gateways. In addition, a bug preventing ActiveMerchant instrumentation from working on Ruby 1.9+ has been fixed.
Thanks to Troex Nevelin for the contribution!
More robust Real User Monitoring script injection with charset meta tags
Previous versions of the agent with Real User Monitoring enabled could have injected JavaScript code into the page above a charset meta tag. By the HTML5 spec, the charset tag must appear in the first 1024 bytes of the page, so the Ruby agent will now attempt to inject RUM script after a charset tag, if one is present.
More robust connection sequence with New Relic servers
A rare bug that could cause the agent's initial connection handshake with New Relic servers to silently fail has been fixed, and better logging has been added to the related code path to ease diagnosis of any future issues.
Prevent over-counting of queue time with nested transactions
When using add_transaction_tracer on methods called from within a Rails or Sinatra action, it was previously possible to get inflated queue time measurements, because queue time would be recorded for both the outer transaction (the Rails or Sinatra action) and the inner transaction (the method given to add_transaction_tracer). This has been fixed, so only the outermost transaction will now record queue time.