重要
We recommend updating to the latest agent version as soon as it's available. If you can't upgrade to the latest version, update your agents to a version no more than 90 days old. Read more about keeping agents up to date.
See the New Relic Ruby agent EOL policy for information about agent releases and support dates.
v9.5.0
Version 9.5.0 introduces Stripe instrumentation, allows the agent to record additional response information on a transaction when middleware instrumentation is disabled, introduces new :'sidekiq.args.include'
and :'sidekiq.args.exclude:
configuration options to permit capturing only certain Sidekiq job arguments, updates Elasticsearch datastore instance metrics, and fixes a bug in NewRelic::Rack::AgentHooks.needed?
.
Feature: Add Stripe instrumentation
Stripe calls are now automatically instrumented. Additionally, new
:'stripe.user_data.include'
and:'stripe.user_data.exclude'
configuration options permit capturing customuser_data
key-value pairs that can be stored in Stripe events. Nouser_data
key-value pairs are captured by default. The agent currently supports Stripe versions 5.38.0+. PR#2180Feature: Report transaction HTTP status codes when middleware instrumentation is disabled
Previously, when
disable_middleware_instrumentation
was set totrue
, the agent would not record the value of the response code or content type on the transaction. This was due to the possibility that a middleware could alter the response, which would not be captured by the agent when the middleware instrumentation was disabled. However, based on customer feedback, the agent will now report the HTTP status code and content type on a transaction when middleware instrumentation is disabled. PR#2175Feature: Permit capturing only certain Sidekiq job arguments
New
:'sidekiq.args.include'
and:'sidekiq.args.exclude'
configuration options have been introduced to permit fine grained control over which Sidekiq job arguments (args) are reported to New Relic. By default, no Sidekiq args are reported. To report any Sidekiq options, the:'attributes.include'
array must include the string'jobs.sidekiq.args.*'
. With that string in place, all arguments will be reported unless one or more of the new include/exclude options are used. The:'sidekiq.args.include'
option can be set to an array of strings. Each of those strings will be passed toRegexp.new
and collectively serve as an allowlist for desired args. For job arguments that are hashes, if a hash's key matches one of the include patterns, then both the key and its corresponding value will be included. For scalar arguments, the string representation of the scalar will need to match one of the include patterns to be captured. The:'sidekiq.args.exclude'
option works similarly. It can be set to an array of strings that will each be passed toRegexp.new
to create patterns. These patterns will collectively serve as a denylist for unwanted job args. Any hash key, hash value, or scalar that matches an exclude pattern will be excluded (not sent to New Relic). PR#2177newrelic.yml
examples:Any string in the
:'sidekiq.args.include'
or:'sidekiq.args.exclude'
arrays will be turned into a regular expression. Knowledge of Ruby regular expression support can be leveraged but is not required. If regular expression syntax is not used, inexact matches will be performed and the string "Fortune" will match both "Fortune 500" and "Fortune and Glory". For exact matches, use regular expression anchors.# Include any argument whose string representation matches either "apple" or "banana"# The "apple" pattern will match both "green apple" and "red apple"sidekiq.args.include:- apple- banana# Exclude any arguments that match either "grape", "orange", or "pear"sidekiq.args.exclude:- grape- orange- pear# Exclude any argument that is a 9 digit numbersidekiq.args.exclude:- '\d{9}'# Include anything that starts with "blue" but exclude anything that ends in "green"sidekiq.args.include- '^blue'sidekiq.args.exclude- 'green$'Bugfix: Update Elasticsearch datastore instance metric to use port instead of path
Previously, the Elasticsearch datastore instance metric (
Datastore/instance/Elasticsearch/<host>/*
) used the path as the final value. This caused a metrics grouping issue for some users, as every document ID created a unique metric. Now, the datastore instance metric has been updated to use the port as the final value. This also has the benefit of being more accurate for datastore instance metrics, as this port is directly associated with the already listed host.Bugfix: Resolve inverted logic of NewRelic::Rack::AgentHooks.needed?
Previously,
NewRelic::Rack::AgentHooks.needed?
incorrectly used inverted logic. This has now been resolved, allowing AgentHooks to be installed whendisable_middleware_instrumentation
is set to true. PR#2175
重要
We recommend updating to the latest agent version as soon as it's available. If you can't upgrade to the latest version, update your agents to a version no more than 90 days old. Read more about keeping agents up to date.
See the New Relic Ruby agent EOL policy for information about agent releases and support dates.
v9.4.2
Version 9.4.2 of the agent re-addresses the 9.4.0 issue of NoMethodError
seen when using the uppy-s3_multipart
gem.
Bugfix: Resolve NoMethodError
Ruby agent 9.4.1 attempted to fix a
NoMethodError
introduced in 9.4.0. A missingrequire
prevented a method from scoping appropriately and has now been added. Thanks to @spickermann and @ColinOrr for working with us to get this resolved. PR#2167
重要
We recommend updating to the latest agent version as soon as it's available. If you can't upgrade to the latest version, update your agents to a version no more than 90 days old. Read more about keeping agents up to date.
See the New Relic Ruby agent EOL policy for information about agent releases and support dates.
v9.4.1
Version 9.4.1 of the agent resolves a NoMethodError
introduced in 9.4.0.
Bugfix: Resolve NoMethodError
Ruby agent 9.4.0 introduced Roda instrumentation, which caused a
NoMethodError
to be raised when attempting to name a Roda transaction. This has been fixed. Thanks to @spickermann for reporting this issue. PR#2167
重要
We recommend updating to the latest agent version as soon as it's available. If you can't upgrade to the latest version, update your agents to a version no more than 90 days old. Read more about keeping agents up to date.
See the New Relic Ruby agent EOL policy for information about agent releases and support dates.
v9.4.0
Version 9.4.0 of the agent adds Roda instrumentation, adds a new allow_all_headers
configuration option to permit capturing all HTTP headers, introduces improved error tracking functionality by associating a transaction id with each error, and uses more reliable network timeout logic.
Feature: Add Roda instrumentation
Roda is a now an instrumented framework. The agent currently supports Roda versions 3.19.0+. PR#2144
Feature: New allow_all_headers configuration option
A new
allow_all_headers
configuration option brings parity with the Node.js agent to capture all HTTP request headers.This configuration option:
- Defaults to
false
- Is not compatible with high security mode
- Requires Rack version 2 or higher (as does Ruby on Rails version 5 and above)
- Respects all existing behavior for the
attributes.include
andattributes.exclude
configuration options - Captures the additional headers as attributes prefixed with
request.headers.
This work was done in response to a feature request submitted by community member @jamesarosen. Thank you very much, @jamesarosen! Issue#1029
- Defaults to
Feature: Improved error tracking transaction linking
Errors tracked and sent to the New Relic errors inbox will now be associated with a transaction id to enable improved UI/UX associations between transactions and errors. PR#2035
Feature: Use Net::HTTP native timeout logic
In line with current Ruby best practices, make use of Net::HTTP's own timeout logic and avoid the use of
Timeout.timeout()
when possible. The agent's data transmissions and cloud provider detection routines have been updated accordingly. PR#2147
重要
We recommend updating to the latest agent version as soon as it's available. If you can't upgrade to the latest version, update your agents to a version no more than 90 days old. Read more about keeping agents up to date.
See the New Relic Ruby agent EOL policy for information about agent releases and support dates.
v9.3.1
Version 9.3.1 of the agent fixes NewRelic::Agent.require_test_helper
.
Bugfix: Fix NewRelic::Agent.require_test_helper
Version 9.3.0 of the agent made a change to the files distributed with the gem. This change unintentionally broke the
NewRelic::Agent.require_test_helper
API by removing thetest/agent_helper.rb
file. The file has been added back to the gem. This change also removes thelib/new_relic/build.rb
file from the list because it is no longer created with our current release process.Our thanks go to @ajesler for reporting this issue and writing a test for the bug. Issue#2113, PR#2115, Issue#2117, PR#2118
Source Documentation: update the Rack spec URL
Community member @olleolleolle noticed that our source code was referencing a now defunct URL for the Rack specification and submitted PR#2121 to update it. He also provided a terrific recommendation that we automate the checking of links to proactively catch defunct ones in future. Thanks, @olleolleolle!
重要
We recommend updating to the latest agent version as soon as it's available. If you can't upgrade to the latest version, update your agents to a version no more than 90 days old. Read more about keeping agents up to date.
See the New Relic Ruby agent EOL policy for information about agent releases and support dates.
v9.3.0
Version 9.3.0 of the agent adds log-level filtering, adds custom attributes for log events, and updates instrumentation for Action Cable. It also provides fixes for how Fiber
args are treated, Code-Level Metrics, unnecessary files being included in the gem, and NewRelic::Agent::Logging::DecoratingFormatter#clear_tags!
being incorrectly private.
Feature: Filter forwarded logs based on level
Previously, all log events, regardless of their level, were forwarded to New Relic when log forwarding was enabled. Now, you may specify the lowest log level you'd like forwarded to New Relic.
Configuration name Default Behavior Valid values application_logging.forwarding.log_level
debug
Sets the minimum log level for events forwarded to New Relic debug
,info
,warn
,error
,fatal
,unknown
This setting uses Ruby's Logger::Severity constants integer values to determine precedence.
Feature: Custom attributes for logs
You can now add custom attributes to log events forwarded to New Relic! You can pass these attributes using an API and/or a configuration option.
Configuration name Default Behavior application_logging.forwarding.custom_attributes
{}
A hash with key/value pairs to add as custom attributes to all log events forwarded to New Relic. If sending using an environment variable, the value must be formatted like: "key1=value1,key2=value2"
Call the API using NewRelic::Agent.add_custom_log_attributes
and passing your attributes as a hash. For example, you could call: NewRelic::Agent.add_custom_log_attributes(dyno: ENV['DYNO'], pod_name: ENV['POD_NAME'])
, to add the attributes dyno
and pod_name
to your log events.
Attributes passed to the API or the configuration will be added to all log events.
Thanks to @rajpawar02 for raising this issue and @askreet for helping us with the solution. Issue#1141, PR#2084, PR#2087
Feature: Instrument transmit_subscription-related Action Cable actions
This change subscribes the agent to the Active Support notifications for:
transmit_subscription_confirmation.action_cable
transmit_subscription_rejection.action_cable
Bugfix: Removed unwanted files from being included in file_list in gemspec
Previously, the agent was including some files in the gem that were not needed but added to the size of the gem. These files will no longer be included. Thanks to @manuraj17 for the contribution! PR#2089
Bugfix: Report Code-Level Metrics for Rails controller methods
Controllers in Rails automatically render views with names that correspond to valid routes. This means that a controller method may not have a corresponding method in the controller class. Code-Level Metrics now report on these methods and don't log false warnings. Thanks to @jcrisp for reporting this issue. PR#2061
Bugfix: Code-Level Metrics for ActiveRecord models
Classes that inherit from ActiveRecord were not reporting Code-Level Metrics due to an error in the agent when identifying the class name. This has been fixed and Code-Level Metrics will now report for ActiveRecord models. Thanks to @abigail-rolling for reporting this issue. PR#2092.
Bugfix: Private method
clear_tags!
for NewRelic::Agent::Logging::DecoratingFormatterAs part of a refactor included in a previous release of the agent, the method
NewRelic::Agent::Logging::DecoratingFormatter#clear_tags!
was incorrectly made private. This method is now public again. Thanks to @dark-panda for reporting this issue. PR#Bugfix: Fix the way args are handled for Fibers
Previously, the agent treated Fiber args the same as it was treating Thread args, which is not correct. Args are passed to
Fiber#resume
, and notFiber.new
. This has been fixed, and the agent will properly preserve args for both Fiber and Thread classes. This also caused an error to occur when using Async 2.6.2, due to mismatching initalize definitions for Fiber prepended modules. This has been fixed as well. Thanks to @travisbell for bringing this to our attention. PR#2083
重要
We recommend updating to the latest agent version as soon as it's available. If you can't upgrade to the latest version, update your agents to a version no more than 90 days old. Read more about keeping agents up to date.
See the New Relic Ruby agent EOL policy for information about agent releases and support dates.
v9.2.2
Version 9.2.2 of the agent fixes a bug with the Transaction#finished?
method.
Bugfix: Transaction#finished? no longer throws a NoMethodError when initial_segment is nil
This change adds a safe navigation operator to
Transaction#finished?
to preventNoMethodErrors
when a transaction does not have any segments. Our thanks goes to @JulienDefrance for reporting this issue. PR#1983
重要
We recommend updating to the latest agent version as soon as it's available. If you can't upgrade to the latest version, update your agents to a version no more than 90 days old. Read more about keeping agents up to date.
See the New Relic Ruby agent EOL policy for information about agent releases and support dates.
v9.2.1
Version 9.2.1 fixes a bug causing the agent to continue storing data on finished transactions, and a bug preventing errors from being expected.
Bugfix: Finished transactions continue to store data on different threads
Previously, when a new thread was spawned the agent would continue using the current transaction to record data on, even if this transaction had finished already in a different thread. Now the agent will only use the current transaction in the new thread if it is not yet finished. Thank you to @fcheung for reporting this bug and providing us with an extremely helpful reproduction to debug. PR#1969
Bugfix: Expected Errors passed to notice_error are expected again
A bug was introduced in 9.1.0 that caused to agent not to mark errors as expected if the error was passed in to
notice_error
using theexpected: true
parameter. This has been fixed and errors will now be marked as expected, as expected. Thank you very much to @eiskrenkov for finding this bug and contributing a fix for it! PR#1954
重要
We recommend updating to the latest agent version as soon as it's available. If you can't upgrade to the latest version, update your agents to a version no more than 90 days old. Read more about keeping agents up to date.
See the New Relic Ruby agent EOL policy for information about agent releases and support dates.
v9.2.0
Version 9.2.0 of the agent introduces some performance improvements for working with high numbers of nested actions, and deprecates instrumentation for the memcached
and memcache-client
gems (with dalli
still being supported).
Feature: Enhance performance for handling high numbers of nested actions
With Issue#1910, community members @parkerfinch and @travisbell informed us of some CPU spikes and process hangs seen only when using the agent's thread instrumentation, which was enabled by default with v9.0. When thread instrumentation is enabled, instrumented actions taking place within threads are seen and reported on by the agent whereas they would have previously gone unnoticed. This is a great improvement to the agent's usefulness in an async context, and also makes it easier for higher numbers of nested actions to be observed. For example, if an instrumented background job framework (Sidekiq, Resque) kicks off a job that the agent notices and then that job in turn performs actions such as database queries that the agent also instruments, nested actions are seen. However, with very high (10,000+) numbers of actions nested within a single instrumented outer action, the agent would struggle to efficiently crunch through all of the collected data at the time when the outer action finished. The agent should now be much more efficient when any observed action with lots of nested actions is finished. Our performance testing was conducted with hundreds of thousands of nested actions taking place, and we hope that the benefits of thread tracing can now be enjoyed without any drawbacks. Thanks very much @parkerfinch and @travisbell! PR#1927
Feature: Deprecate memcached and memcache-client instrumentation
Instrumentation for the memcached and memcache-client libraries is deprecated and will be removed during the next major release.
重要
We recommend updating to the latest agent version as soon as it's available. If you can't upgrade to the latest version, update your agents to a version at most 90 days old. Read more about keeping agents up to date.
See the New Relic Ruby agent EOL policy for information about agent releases and support dates.
v9.1.0
Version 9.1.0 of the agent delivers support for two new errors inbox features: error fingerprinting and user tracking, identifies the Amazon Timestream data store, removes Distributed Tracing warnings from agent logs when using Sidekiq, fixes bugs, and is tested against the recently released JRuby 9.4.2.0.
Feature: Error fingerprinting - supply your own errors inbox group names
Are your error occurrences grouped poorly? Set your own error fingerprint via a callback function. A new
set_error_group_callback
public API method has been added that will accept a user defined proc. The proc will be invoked for each noticed error and whenever it returns a string, that string will be used as the error group name for the error and will take precedence over any server-side grouping that takes place with the New Relic errors inbox. This gives users much greater control over the grouping of their errors.The customer defined proc will be expected to receive exactly one input argument, a hash. The hash contains the following:
Key Value :error
The Ruby error class instance. Offers #class
,#message
, and#backtrace
:customAttributes
Any customer defined custom attributes for the current transaction :'request.uri'
The current request URI if available :'http.statusCode'
The HTTP status code (200, 404, etc.) if available :'http.method'
The HTTP method (GET, PUT, etc.) if available :'error.expected'
Whether (true) or not (false) the error was expected :'options'
The options hash passed to NewRelic::Agent.notice_error
The callback only needs to be set once per initialization of the New Relic agent.
Example usage:
proc = proc { |hash| "Access" if hash[:'http.statusCode'] == 401 }NewRelic::Agent.set_error_group_callback(proc)Feature: User tracking - associate errors with a user id
You can now see the number of users impacted by an error group. Identify the end user with a new
set_user_id
public API method that will accept a string representation of a user id and associate that user id with the current transaction. Transactions and errors will then have a newenduser.id
agent attribute associated with them. This will allow agent users to tag transactions and errors as belonging to given user ids in support of greater filtering and alerting capabilities.Identify Amazon Timestream when the amazon_timestream AR adapter is used
When the agent sees the activerecord-amazon-timestream-adapter gem being used, it will now identify the data store as "Timestream". Thanks very much to @wagner for contributing this enhancement! PR#1872
Bugfix: Remove Distributed Tracing related warnings from agent logs when headers are not present in Sidekiq
Previously, the agent would log a warning to
newrelic_agent.log
every time it attempted to accept empty Distributed Tracing headers from Sidekiq jobs which could result in an excessive number of warnings. Now the agent will no longer create these warnings when using Sidekiq. PR#1834Bugfix: Log request headers in debug-level logs instead of human-readable Objects
Previously, the agent sometimes received children of the
NewRelic::Agent::HTTPClients::AbstractRequest
class as an argument whenNewRelic::Agent::Transaction::DistributedTracers#log_request_headers
was called. This caused debug-level log messages that print the request headers to show human-readable Objects (ex.#<NewRelic::Agent::HTTPClients::HTTPClientRequest:0x00007fd0dda983e0>
) instead of the request headers. Now, the hash of the request headers should always be logged. PR#1839Bugfix: Fix undefined method
controller_path
logged in Action Controller InstrumentationPreviously, the agent could log an error when trying to determine the metric name in the Action Controller instrumentation if the controller class did not respond to
controller_path
. This has been resolved and the agent will no longer call this method unless the class responds to it. Thank you to @gsar for letting us know about this issue. PR#1844Bugfix: Fix Transaction#finish exception and decrease log level for related warning during async transactions
Previously, the agent would raise a non-fatal error when a segment without a parent was unfinished when the transaction completed. This error was raised while constructing a
warn
-level log message. Now that Thread instrumentation is on by default, this log message emits more frequently and is less concerning. In cases where we see a Thread, Fiber, or concurrent-ruby segment in a transaction, the message will be degraded to adebug
-level. Thanks to @NielsKSchjoedt for creating the issue and @boomer196 for testing solutions. PR#1876CI: Target JRuby 9.4.2.0
The agent is now actively being tested against JRuby 9.4.2.0. NOTE that this release does not contain any non-CI related changes for JRuby. Old agent versions are still expected to work with newer JRubies and the newest agent version is still expected to work with older JRubies.