중요
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.15.0
Version 9.15.0 updates View Component instrumentation to use a default metric name when one is unavailable, adds a configuration option to associate the AWS account ID with the DynamoDB calls from the AWS SDK, resolves a bug in rdkafka instrumentation when using the karafka-rdkafka gem, resolves a bug in the ruby-kafka instrumentation, fixes a bug with Grape instrumentation, and addresses a bug preventing the agent from running in serverless mode in an AWS Lambda layer.
Feature: New configuration option cloud.aws.account_id
A new configuration option has been added,
cloud.aws.account_id
, that will allow New Relic to provide more details about certain calls made using the AWS SDK. For example, relationships between AWS services instrumented with New Relic's CloudWatch Metric Streams will have relationships formed in the service map with APM applications. Currently, the DynamoDB instrumentation is the only instrumentation that will make use of this configuration option, but this will be used in future instrumentation as well. PR#2904Feature: Use default
View/component
metric name for unidentified View ComponentsPreviously, when a View Component metric name could not be identified, the agent would set the name as
nil
. Now, the agent defaults to usingView/component
as the metric name when one can not be identified. PR#2907Bugfix: Instrumentation errors when using the karafka-rdkafka gem
Due to version differences between the rdkafka gem and karafka-rdkafka gem, the agent could encounter an error when it tried to install rdkafka instrumentation. This has now been resolved. Thank you to @krisdigital for bringing this issue to our attention. PR#2880
Bugfix: Stop calling deprecated all_specs method to check for the presence of newrelic-grape
In 9.14.0, we released a fix for calls to the deprecated
Bundler.rubygems.all_specs
, but the fix fell short for the agent's Grape instrumentation and deprecation warnings could still be raised. The condition has been simplified and deprecation warnings should no longer be raised. Thank you, @excelsior for bringing this to our attention. Issue#2885 PR#2906Bugfix: Instrumentation errors when using the ruby-kafka gem
Kafka::Consumer#each_message takes keyword arguments, while the prepended method is defined with a single splat positional argument. In Ruby >= 3.0, this signature mismatch raises an ArgumentError. Thank you @patrickarnett for providing this bugfix. PR#2915
Bugfix: Restore AWS Lambda layer operational functionality
Version 9.14.0 of the agent introduced an optimization related to how the agent handles boolean configuration parameters which inadvertently caused the agent to stop operating properly in an AWS Lambda layer context. Issue#2919PR#2920
중요
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.14.0
Version 9.14.0 adds Apache Kafka instrumentation for the rdkafka and ruby-kafka gems, introduces a configuration-based, automatic way to add custom instrumentation method tracers, correctly captures MIME type for ActionDispatch 7.0+ requests, properly handles Boolean coercion for newrelic.yml
configuration, fixes a JRuby bug in the configuration manager, fixes a bug related to Bundler.rubygems.installed_specs
, and fixes a bug to make the agent compatible with ViewComponent v3.15.0+.
Feature: Add Apache Kafka instrumentation for the rdkafka and ruby-kafka gems
The agent now has instrumentation for both the rdkafka and ruby-kafka gems. The agent will record transactions and message broker segments for produce and consume calls made using these gems. PR#2824 PR#2842
Feature: Add a configuration option to permit custom method tracers to be defined automatically
A new
:automatic_custom_instrumentation_method_list
configuration parameter has been added to permit the user to define a list of fully qualified (namespaced) Ruby methods for the agent to automatically add custom instrumentation for without requiring any code modifications to be made to the classes that define the methods.The list should be an array of
CLASS#METHOD
(for instance methods) and/orCLASS.METHOD
(for class methods) strings.Use fully qualified class names (using the
::
delimiter) that include any module or class namespacing.Here is some Ruby source code that defines a
render_png
instance method for anImage
class and anotify
class method for aUser
class, both within aMyCompany
module namespace:module MyCompanyclass Imagedef render_png# code to render a PNGendendclass Userdef self.notify# code to notify usersendendendGiven that source code, the
newrelic.yml
config file might request instrumentation for both of these methods like so:automatic_custom_instrumentation_method_list:- MyCompany::Image#render_png- MyCompany::User.notifyThat configuration example uses YAML array syntax to specify both methods. Alternatively, a comma-delimited string can be used instead:
automatic_custom_instrumentation_method_list: 'MyCompany::Image#render_png, MyCompany::User.notify'Whitespace around the comma(s) in the list is optional. When configuring the agent with a list of methods via the
NEW_RELIC_AUTOMATIC_CUSTOM_INSTRUMENTATION_METHOD_LIST
environment variable, this comma-delimited string format should be used:export NEW_RELIC_AUTOMATIC_CUSTOM_INSTRUMENTATION_METHOD_LIST='MyCompany::Image#render_png, MyCompany::User.notify'Feature: Collect just MIME type for ActionDispatch 7.0+ requests
Rails 7.0 introduced changes to the behavior of
ActionDispatch::Request#content_type
, adding extra request-related details the agent wasn't expecting to collect. Additionally, the agent's use ofcontent_type
was triggering deprecation warnings. The agent now usesActionDispatch::Request#media_type
to capture the MIME type. Thanks to @internethostage for letting us know about this change. Issue#2500 PR#2855Bugfix: Corrected Boolean coercion for
newrelic.yml
configurationPreviously, any String assigned to New Relic configurations expecting a Boolean value were evaluated as
true
. This could lead to unexpected behavior. For example, settingapplication_logging.enabled: 'false'
innewrelic.yml
would incorrectly evaluate toapplication_logging.enabled: true
due to the truthy nature of Strings.Now, the agent strictly interprets Boolean configuration values. It recognizes both actual Boolean values and certain Strings/Symbols:
'true'
,'yes'
, or'on'
(evaluates totrue
)'false'
,'no'
, or'off'
(evaluates tofalse
)
Any other inputs will revert to the setting's default configuration value. PR#2847
Bugfix: JRuby not saving configuration values correctly in configuration manager
Previously, a change made to fix a different JRuby bug caused the agent to not save configuration values correctly in the configuration manager when running on JRuby. This has been fixed. PR#2848
Bugfix: Update condition to verify Bundler.rubygems.installed_specs is available
To address a recent Bundler deprecation warning, we started using
Bundler.rubygems.installed_specs
instead ofBundler.rubygems.all_specs
in environments that seemed appropriate. We discovered the version constraint we used was too low. Now, rather than check the version, we check for the method usingrespond_to?
. PR#2853Bugfix: Support view_component v3.15.0+
Previously the agent had been making use of a private API to obtain a component identifier value. This private API was dropped in v3.15.0 of view_component, resulting in errors from the New Relic Ruby agent's continued attempts to use it. Many thanks to community member @navidemad for bringing this issue to our attention and supplying a bugfix with PR#2870.
중요
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.13.0
Version 9.13.0 enhances support for AWS Lambda functions, adds experimental OpenSearch instrumentation, updates framework detection, silences a Bundler deprecation warning, fixes Falcon dispatcher detection, fixes a bug with Redis instrumentation installation, and addresses a JRuby-specific concurrency issue.
- Feature: Enhance AWS Lambda function instrumentation
When utilized via the latest New Relic Ruby layer for AWS Lambda, the agent now offers enhanced support for AWS Lambda function instrumentation.
- The agent's instrumentation for AWS Lambda functions now supports distributed tracing.
- Web-triggered invocations are now identified as being "web"-based when an API Gateway call is involved, with support for both API Gateway versions 1.0 and 2.0.
- Web-based calls have the HTTP method, URI, and status code recorded.
- The agent now recognizes and reports on 12 separate AWS resources that are capable of triggering a Lambda function invocation: ALB, API Gateway V1, API Gateway V2, CloudFront, CloudWatch Scheduler, DynamoStreams, Firehose, Kinesis, S3, SES, SNS, and SQS.
- The type of the triggering resource and its ARN will be recorded for each resource, and for many of them, extra resource-specific attributes will be recorded as well. For example, Lambda function invocations triggered by S3 bucket activity will now result in the S3 bucket name being recorded. PR#2811
Feature: Add experimental OpenSearch instrumentation
The agent will now automatically instrument the
opensearch-ruby
gem. We're marking this instrumentation as experimental because more work is needed to fully test it. OpenSearch instrumentation provides telemetry similar to Elasticsearch. Thank you, @Earlopain for reporting the issue and @praveen-ks for an initial draft of the instrumentation. Issue#2228 PR#2796Feature: Improve framework detection accuracy for Grape and Padrino
Previously, applications using the Grape framework would set
ruby
as their framework within the Environment Report. Now, Grape applications will be set togrape
. Similarly, applications using the Padrino framework would be set tosinatra
. Now, they will be set topadrino
. This will help the New Relic security agent compatibility checks. Thank you, @prateeksen for making this change. Issue#2777 PR#2789Feature: Silence Bundler
all_specs
deprecation warningBundler.rubygems.all_specs
was deprecated in favor ofBundler.rubygems.installed_specs
in Bundler versions 2+, causing the agent to emit deprecation warnings. The method has been updated when Bundler 2+ is detected and warnings are now silenced. Thanks to @jcoyne for reporting this issue. Issue#2733 PR#2823Bugfix: Fix Falcon dispatcher detection
Previously, we tried to use the object space to determine whether the Falcon web server was in use. However, Falcon is not added to the object space until after the environment report is generated, resulting in a
nil
dispatcher. Now, we revert to an earlier strategy that discovered the dispatcher usingFile.basename
. Thank you, @prateeksen for reporting this issue and researching the problem. Issue#2778 PR#2795Bugfix: Fix for a Redis instrumentation error when Redis::Cluster::Client is present
The Redis instrumentation previously contained a bug that would cause it to error out when
Redis::Cluster::Client
was present, owing to the use of a Rubyreturn
outside of a method. Thanks very much to @jdelStrother for not only reporting this bug but pointing us to the root cause as well. Issue#2814 PR#2816Bugfix: Address JRuby concurrency issue with config hash accessing
The agent's internal configuration class maintains a hash that occassionally gets rebuilt. During the rebuild, certain previously dynamically determined instrumentation values are preserved for the benefit of the New Relic Ruby security agent. After reports from JRuby customers regarding concurrency issues related to the hash being accessed while being modified, two separate fixes went into the hash rebuild logic previously: a
Hash#dup
operation and asynchronize do
block. But errors were still reported. We ourselves remain unable to reproduce these concurrency errors despite using the same exact versions of JRuby and all reported software. After confirming that the hash access code in question is only needed for the Ruby security agent (which operates only in non-production dedicated security testing environments), we have introduced a new fix for JRuby customers that will simply skip over the troublesome code when JRuby is in play but the security agent is not. PR#2798
중요
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.12.0
Version 9.12.0 adds support for the newrelic_security
agent, introduces instrumentation for the LogStasher gem, improves instrumentation for the redis-clustering
gem, and updates the Elasticsearch instrumentation to only attempt to get the cluster name once per client, even if it fails.
Feature: Add support for the newrelic_security agent
New Relic Interactive Application Security Testing (IAST) can help you prevent cyberattacks and breaches on your applications by probing your running code for exploitable vulnerabilities.
The
newrelic_security
gem provides this feature for Ruby. It depends onnewrelic_rpm
. This is the first version ofnewrelic_rpm
compatible withnewrelic_security
.At this time, the security agent is intended for use only within a dedicated security testing environment with data that can tolerate modification or deletion. The security agent is available as a separate Ruby gem,
newrelic_security
. It is recommended that this separate gem only be introduced to a security testing environment by leveraging Bundler grouping like so:# Gemfilegem 'newrelic_rpm' # New Relic APM observability agentgem 'newrelic-infinite_tracing' # New Relic Infinite Tracinggroup :security dogem 'newrelic_security', require: false # New Relic security agentendIn order to run the security agent, you need to update your configuration. At a minimum,
security.agent.enabled
andsecurity.enabled
must be set totrue
. They arefalse
by default. Similar to the gem installation, we recommend you set these configurations for a special security testing environment only.Here's an example using
newrelic.yml
:common: &default_settingslicense_key: <%= ENV['NEW_RELIC_LICENSE_KEY'] %>app_name: "Example app"development:<<: *default_settingsapp_name: <%= app_name %> (Development)security:<<: *default_settingssecurity.enabled: truesecurity.agent.enabled: trueproduction:<<: *default_settingsThe following configuration relate to the
newrelic_security
gem:Configuration name Default Behavior security.agent.enabled false
If true
, the security agent is loaded (a Ruby 'require' is performed)security.enabled false
If true
, the security agent is started (the agent runs in its event loop)security.mode 'IAST'
Defines the mode for the security agent to operate in. Currently only 'IAST' is supported security.validator_service_url 'wss://csec.nr-data.net'
Defines the endpoint URL for posting security related data security.detection.rci.enabled true
If true
, enables RCI (remote code injection) detectionsecurity.detection.rxss.enabled true
If true
, enables RXSS (reflected cross-site scripting) detectionsecurity.detection.deserialization.enabled true
If true
, enables deserialization detectionsecurity.application_info.port nil
An Integer representing the port the application is listening on. This setting is mandatory for Passenger servers. Other servers should be detected by default. Feature: Add instrumentation for LogStasher
The agent will now record logs generated by LogStasher. Versions 1.0.0 and above of the LogStasher gem are supported. PR#2559
Feature: Add instrumentation for redis-clustering
Version 5.x of the
redis
gem moved cluster behavior into a different gem,redis-clustering
. This gem can access instrumentation registered throughRedisClient::Middleware
. Previously, the agent only instrumented thecall_pipelined
method through this approach, but now users of theredis-clustering
gem will also have instrumentation registered forconnect
andcall
methods. In addition, the way thedatabase_name
attribute is set for Redis datastore spans is now compatible with all versions of Redis supported by the New Relic Ruby agent. Thank you, @praveen-ks for bringing this to our attention. Issue#2444 PR#2720Bugfix: Update Elasticsearch instrumentation to only attempt to get the cluster name once per client
Previously, the agent would attempt to get the cluster name every time a call was made if it was not already captured. This could lead to a large number of failures if the cluster name could not be retrieved. Now, the agent will only attempt to get the cluster name once per client, even if it fails. Thank you, @ascoppa for bringing this to our attention. Issue#2730 PR#2743
Feature: Produce metrics for 4 additional Action Controller Rails notifications
Four additional Action Controller related Rails notifications are now subscribed to by the agent to produce telemetry. These 4 are
exist_fragment?
,expire_fragment
,read_fragment
, andwrite_fragment
. As with instrumentation for Action Controller itself, these notifications are enabled by default and can be disabled by setting:disable_action_controller
totrue
in the agent'snewrelic.yml
configuration file. PR#2745
중요
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.11.0
Version 9.11.0 introduces instrumentation for the aws-sdk-sqs gem, fixes a bug related to expected errors not bearing a "true" value for the "expected" attribute if expected as a result of an HTTP status code match and changes the way Stripe instrumentation metrics are named to prevent high-cardinality issues.
Feature: Add instrumentation for SQS
The agent has added instrumentation for the aws-sdk-sqs gem. The agent will now record message broker spans for SQS client calls made with the aws-sdk-sqs gem. PR#2679
Bugfix: HTTP status code based expected errors will now have an "expected" value of "true"
Previously when an error was treated as expected by the agent as a result of a matching HTTP status code being found in the :'error_collector.expected_status_codes' configuration setting, the error would not appear with an "expected" attribute value of "true" in the errors in the errors inbox. PR#2710
Bugfix: Stripe metric names will no longer include full request paths to limit the unique name count
The Stripe instrumentation introduced in agent version v9.5.0 produced instrumentation metric names that used the full Stripe request path. For any significant Stripe usage, this could quickly lead to very large number of distinct metric names. Now only the API version and the category part of the request path are included in the metric name which still includes the "Stripe" opener and method (ex: "get") closer. Thanks to @jdelStrother and @jsneedles for bringing this issue to our attention and providing terrific information explaining the problem and potential paths to resolution. PR#2716
중요
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.10.2
Version 9.10.2 fixes a bug related to the new DynamoDB instrumentation and removes Rails::Command::RakeCommand
from the default list of denylisted constants.
Bugfix: DynamoDB instrumentation logging errors when trying to get account_id
When trying to access data needed to add the
account_id
to the DynamoDB span, the agent encountered an error when certain credentials classes were used. This has been fixed. Thanks to @kichik for bringing this to our attention. PR#2864Bugfix: Remove
Rails::Command::RakeCommand
from the default list ofautostart.denylisted_constants
The default value for the
autostart.denylisted_constants
configuration was changed in 9.10.0 to includeRails::Command::RunnerCommand
andRails::Command::RakeCommand
. The inclusion ofRails::Command::RakeCommand
prevented the agent from starting automatically when Solid Queue was started usingbin/rails solid_queue:start
. We recognize there are many commands nested withinRails::Command::RakeCommand
and have decided to remove it from the default list. We encourage users who do not want the agent to run onRails::Command::RakeCommand
to add the constant to their configuration. This can be accomplished by adding the following to yournewrelic.yml
file:autostart.denylisted_constants: "Rails::Command::ConsoleCommand,Rails::Command::CredentialsCommand,Rails::Command::Db::System::ChangeCommand,Rails::Command::DbConsoleCommand,Rails::Command::DestroyCommand,Rails::Command::DevCommand,Rails::Command::EncryptedCommand,Rails::Command::GenerateCommand,Rails::Command::InitializersCommand,Rails::Command::NotesCommand,Rails::Command::RakeCommand,Rails::Command::RoutesCommand,Rails::Command::RunnerCommand,Rails::Command::SecretsCommand,Rails::Console,Rails::DBConsole"Thank you, @edariedl, for reporting this issue. Issue#2677 PR#2694
중요
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.10.1
- Bugfix: Incompatibility with Bootstrap
Version 9.10.1 fixes an incompatibility between the agent and the Bootstrap gem caused by agent v9.10.0's introduction of a lib/bootstrap.rb
file. Thank you to @dorner for reporting the bug and identifying the 'bootstrap' name collision as the root cause. BUG#2675 PR#2676
중요
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.10.0
Version 9.10.0 introduces instrumentation for DynamoDB, adds a new feature to automatically apply nonces from the Rails content security policy, fixes a bug that would cause an expected error to negatively impact a transaction's Apdex, and fixes the agent's autostart logic so that by default rails runner
and rails db
commands will not cause the agent to start.
Feature: Add instrumentation for DynamoDB
The agent has added instrumentation for the aws-sdk-dynamodb gem. The agent will now record datastore spans for DynamoDB client calls made with the aws-sdk-dynamodb gem. PR#2642
Feature: Automatically apply nonces from the Rails content security policy
To auto-inject browser monitoring with the New Relic Ruby agent, you either need to set your content security policy to 'unsafe-inline' or provide a nonce. Previously, the only way to provide a nonce was by using the
NewRelic::Agent.browser_timing_header
API. Now, when a Rails application uses the content security policy configuration to add a nonce, the nonce will be automatically applied to the browser agent. A new configuration option,browser_monitoring.content_security_policy_nonce
, toggles this feature. It is on by default. Thank you @baldarn for submitting this feature! PR#2544Bugfix: Expected errors related to HTTP status code, class, and message won't impact Apdex
The agent is supposed to prevent observed application errors from negatively impacting Apdex if the errors are either ignored or expected. There are two ways for the agent to expect an error: via the
notice_error
API receiving anexpected: true
argument or via matches made against user-configured lists for expected HTTP status codes (:'error_collector.expected_status_codes'
), expected error classes (:'error_collector.expected_classes'
), or expected error messages (:'error_collector.expected_messages'
). Previously, only errors expected via thenotice_error
API were correctly prevented from impacting Apdex. Expected errors set by configuration incorrectly impacted Apdex. This behavior has been fixed and now both types of expected errors will correctly not impact Apdex. Thanks very much to @florianpilz for bringing this issue to our attention. PR#2619Bugfix: Do not start the agent automatically when
rails runner
orrails db
commands are runPR#2239 taught the agent how to recognize
bin/rails
based contexts that it should not automatically start up in. Butbin/rails runner
andbin/rails db
commands would still see the agent start automatically. Those 2 contexts will now no longer see the agent start automatically. Thank you to @jdelStrother for both bringing thebin/rails
context to our attention and for letting us know about thebin/rails runner
andbin/rails db
outliers that still needed fixing. PR#2623Older agent versions that are still supported by New Relic can update to the new list of denylisted constants by having the following line added to the
newrelic.yml
configuration file:autostart.denylisted_constants: "Rails::Command::ConsoleCommand,Rails::Command::CredentialsCommand,Rails::Command::Db::System::ChangeCommand,Rails::Command::DbConsoleCommand,Rails::Command::DestroyCommand,Rails::Command::DevCommand,Rails::Command::EncryptedCommand,Rails::Command::GenerateCommand,Rails::Command::InitializersCommand,Rails::Command::NotesCommand,Rails::Command::RakeCommand,Rails::Command::RoutesCommand,Rails::Command::RunnerCommand,Rails::Command::SecretsCommand,Rails::Console,Rails::DBConsole"
중요
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.9.0
Version 9.9.0 introduces support for AWS Lambda serverless function observability, adds support for Elasticsearch 8.13.0, and adds the 'request.temperature' attribute to chat completion summaries in ruby-openai instrumentation.
Feature: Serverless Mode for AWS Lambda
The Ruby agent is now capable of operating in a quick and light serverless mode suitable for observing AWS Lambda function invocations. For serverless use, the agent is delivered by a New Relic Lambda layer that can be associated with a Lambda function. All reported data will appear in New Relic's dedicated serverless UI views. Only AWS based Lambda functions are supported for now, though support for other cloud hosted serverless offerings may be added in future depending on Ruby customer demand. The serverless functionality is only intended for use with the official New Relic Ruby layers for Lambda. Any existing workflows that involve the manual use of the Ruby agent in an AWS Lambda context without a New Relic layer should not be impacted.
Feature: Add support for Elasticsearch 8.13.0
Elasticsearch 8.13.0 increased the number of arguments used in the method the agent instruments,
Elastic::Transport::Client#perform_request
. Now, the agent supports a variable number of arguments for the instrumented method to prevent futureArgumentError
s.Bugfix: Add 'request.temperature' to ruby-openai chat completion summaries
Previously, the agent was not reporting the
request.temperature
attribute onLlmChatCompletionSummary
events through ruby-openai instrumentation. We are now reporting this attribute.
중요
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.8.0
Version 9.8.0 introduces instrumentation for ruby-openai, adds the option to store tracer state on the thread-level, hardens the browser agent insertion logic to better proactively anticipate errors, and prevents excpetions from being raised in the Active Support Broadcast logger instrumentation.
Feature: Add instrumentation for ruby-openai
Instrumentation has been added for the ruby-openai gem, supporting versions 3.4.0 and higher (PR#2442). While ruby-openai instrumentation is enabled by default, the configuration option
ai_monitoring.enabled
is disabled by default and controls all AI monitoring.ai_monitoring.enabled
must be set totrue
in order to receive ruby-openai instrumentation. High-Security Mode must be disabled in order to receive AI monitoring.Calls to embedding and chat completion endpoints are automatically traced. These events can be enhanced with the introduction of two new APIs. Custom attributes can also be added to LLM events using the API
NewRelic::Agent.add_custom_attributes
, but they must be prefixed withllm.
. For example,NewRelic::Agent.add_custom_attributes({'llm.user_id': user_id})
.Feature: Add AI monitoring APIs
This version introduces two new APIs that allow users to record additional information on LLM events:
NewRelic::Agent.record_llm_feedback_event
- Records user feedback events.NewRelic::Agent.set_llm_token_count_callback
- Sets a callback proc for calculatingtoken_count
attributes for embedding and chat completion message events.
Visit RubyDoc for more information on each of these APIs.
Feature: Store tracer state on thread-level
A new configuration option,
thread_local_tracer_state
, stores New Relic's tracer state on the thread-level, as opposed to the default fiber-level storage. This configuration is turned off by default. Our thanks go to community member @markiz who contributed the idea, code, configuration option, and tests for this new feature! PR#2475.Bugfix: Harden the browser agent insertion logic
With Issue#2462, community member @miry explained that it was possible for an HTTP response headers hash to have symbols for values. Not only would these symbols prevent the inclusion of the New Relic browser agent tag in the response body, but more importantly they would cause an exception that would bubble up to the monitored web application itself. With PR#2465 symbol based values are now supported and all other potential future exceptions are now handled. Additionally, the refactor to support symbols has been shown through benchmarking to give the processing of string and mixed type hashes a slight speed boost too.
Bugfix: Prevent Exception in Active Support Broadcast logger instrumentation
Previously, in certain situations the agent could cause an exception to be raised when attempting to interact with a broadcast log event. This has been fixed. Thanks to @nathan-appere for reporting this issue and providing a fix! PR#2510