Ruby agent release notesRSS

v9.13.0

La version 9.13.0 améliore la prise en charge des fonctions AWS Lambda, ajoute l’instrumentation expérimentale d’OpenSearch, met à jour la détection du framework, masque un avertissement d’obsolescence de Bundler, corrige la détection du répartiteur Falcon, corrige un bug lors de l’installation de l’instrumentation de Redis, et résout un problème de simultanéité spécifique à JRuby.

• Fonctionnalité : améliorer l’instrumentation de la fonction AWS Lambda

Lorsqu’il est utilisé via la dernière couche Ruby New Relic pour AWS Lambda, l’agent offre désormais une prise en charge améliorée de l’instrumentation de la fonction Lambda AWS.

• L’instrumentation de l’agent pour les fonctions AWS Lambda prend désormais en charge le tracing distribué.

• Les invocations déclenchées par le web sont désormais identifiées comme étant basées sur le "web" lorsqu’un appel API Gateway est impliqué, avec la prise en charge des versions 1.0 et 2.0 d’API Gateway.

• La méthode HTTP, l’URI, et le code d’état des appels web sont enregistrés.

• L’agent reconnaît et crée désormais des rapports sur 12 ressources AWS distinctes capables de déclencher l’invocation d’une fonction Lambda : ALB, API Gateway V1, API Gateway V2, CloudFront, CloudWatch Scheduler, DynamoStreams, Firehose, Kinesis, S3, SES, SNS, et SQS.

• Le type de la ressource de déclenchement et son ARN seront enregistrés pour chaque ressource, et pour nombre d’entre elles, des attributs supplémentaires spécifiques à la ressource seront également enregistrés. Par exemple, les invocations de fonction Lambda déclenchées par l’activité d’un bucket S3 entraîneront désormais l’enregistrement du nom du bucket S3. PR#2811

• Fonctionnalité : Ajout de l’instrumentation expérimentale OpenSearch

  L'agent va désormais automatiquement instrumenter le gem opensearch-ruby. Nous marquons cette instrumentation comme expérimentale, car davantage de travail est nécessaire pour la tester entièrement. L'instrumentation d'OpenSearch fournit une télémétrie similaire à Elasticsearch. Merci, @Earlopain d'avoir signalé le problème, et @praveen-ks pour un brouillon initial de l'instrumentation. Problème n° 2228 PR n° 2796

• Fonctionnalité : améliorer la précision de la détection du framework pour Grape et Padrino

  Auparavant, les applications utilisant le framework Grape définissaient ruby comme leur framework dans le Rapport d’environnement. Désormais, les applications Grape seront définies sur grape. De même, les applications utilisant le framework Padrino étaient définies sur sinatra. Désormais, elles seront définies sur padrino. Cela facilitera les vérifications de compatibilité d’agent de sécurité New Relic. Merci à @prateeksen d’avoir apporté cette modification. Issue#2777 PR#2789

• Fonctionnalité : masquer l’avertissement d’obsolescence de Bundler all_specs

  Bundler.rubygems.all_specs a été dépréciée au profit de Bundler.rubygems.installed_specs dans les versions 2+ de Bundler, ce qui a conduit l'agent à émettre des avertissements de dépréciation. La méthode a été mise à jour lorsque Bundler 2+ est détecté, et les avertissements sont désormais masqués. Merci à @jcoyne d'avoir signalé ce problème. Problème n° 2733 PR n° 2823

• Correction de bug : correction de la détection du répartiteur Falcon

  Auparavant, nous avons essayé d’utiliser l’espace d’objets pour déterminer si le serveur web Falcon était utilisé. Cependant, Falcon n’est ajouté à l’espace d’objets qu’après la génération du rapport d’environnement, ce qui donne un répartiteur nil. À présent, nous revenons à une stratégie antérieure qui découvrait le répartiteur en utilisant File.basename. Nous vous remercions, @prateeksen, d’avoir signalé ce problème, et d’avoir effectué des recherches sur le sujet. Problème n° 2778 PR n° 2795

• Correction de bug : résolution d’une erreur d’instrumentation Redis lorsque Redis::Cluster::Client est présent

  L’instrumentation de Redis contenait auparavant un bug qui générait une erreur lorsque Redis::Cluster::Client était présent, en raison de l’utilisation d’un return Ruby en dehors d’une méthode. Nous vous remercions vivement, @jdelStrother, non seulement pour avoir signalé ce bug, mais aussi pour nous en avoir indiqué la cause profonde. Problème n° 2814 PR n° 2816

• Correction de bug : résolution du problème de simultanéité de JRuby lors de l'accès au hacher de configuration

  La classe de configuration interne de l’agent maintient un hacher qui est occasionnellement reconstruit. Lors de la reconstruction, certaines valeurs d’instrumentation déterminées dynamiquement au préalable sont préservées au profit de l’ agent de sécurité New Relic Ruby. Après des rapports de clients JRuby concernant des problèmes de simultanéité liés à l’accès au hacher pendant sa modification, deux correctifs distincts ont été intégrés précédemment dans la logique de reconstruction du hacher : une opération Hash#dup et un bloc synchronize do. Mais des erreurs ont encore été signalées. Nous restons nous-mêmes incapables de reproduire ces erreurs de simultanéité malgré l’utilisation des mêmes versions exactes de JRuby et de tous les logiciels signalés. Après avoir confirmé que le code d’accès au hacher en question n’est nécessaire que pour l’agent de sécurité Ruby (qui fonctionne uniquement dans des environnements de test de sécurité dédiés de non-production), nous avons introduit un nouveau correctif pour les clients JRuby qui ignorera tout simplement le code problématique lorsque JRuby est en jeu, mais pas l’agent de sécurité. PR#2798

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 on newrelic_rpm. This is the first version of newrelic_rpm compatible with newrelic_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:

  # Gemfile
    gem 'newrelic_rpm'               # New Relic APM observability agent
    gem 'newrelic-infinite_tracing'  # New Relic Infinite Tracing
  
    group :security do
      gem 'newrelic_security', require: false        # New Relic security agent
    end

  Copier

  In order to run the security agent, you need to update your configuration. At a minimum, security.agent.enabled and security.enabled must be set to true. They are false 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_settings
      license_key: <%= ENV['NEW_RELIC_LICENSE_KEY'] %>
      app_name: "Example app"
  
    development:
      <<: *default_settings
      app_name: <%= app_name %> (Development)
  
    security:
      <<: *default_settings
      security.enabled: true
      security.agent.enabled: true
  
    production:
      <<: *default_settings

  Copier

  The 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) detection
  security.detection.rxss.enabled	true	If true, enables RXSS (reflected cross-site scripting) detection
  security.detection.deserialization.enabled	true	If true, enables deserialization detection
  security.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 through RedisClient::Middleware. Previously, the agent only instrumented the call_pipelined method through this approach, but now users of the redis-clustering gem will also have instrumentation registered for connect and call methods. In addition, the way the database_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#2720

• Bugfix: 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, and write_fragment. As with instrumentation for Action Controller itself, these notifications are enabled by default and can be disabled by setting :disable_action_controller to true in the agent's newrelic.yml configuration file. PR#2745

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

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#2864

• Bugfix: Remove Rails::Command::RakeCommand from the default list of autostart.denylisted_constants

  The default value for the autostart.denylisted_constants configuration was changed in 9.10.0 to include Rails::Command::RunnerCommand and Rails::Command::RakeCommand. The inclusion of Rails::Command::RakeCommand prevented the agent from starting automatically when Solid Queue was started using bin/rails solid_queue:start. We recognize there are many commands nested within Rails::Command::RakeCommand and have decided to remove it from the default list. We encourage users who do not want the agent to run on Rails::Command::RakeCommand to add the constant to their configuration. This can be accomplished by adding the following to your newrelic.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"

  Copier

  Thank you, @edariedl, for reporting this issue. Issue#2677 PR#2694

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

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#2544

• Bugfix: 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 an expected: 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 the notice_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#2619

• Bugfix: Do not start the agent automatically when rails runner or rails db commands are run

  PR#2239 taught the agent how to recognize bin/rails based contexts that it should not automatically start up in. But bin/rails runner and bin/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 the bin/rails context to our attention and for letting us know about the bin/rails runner and bin/rails db outliers that still needed fixing. PR#2623

  Older 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"

  Copier

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 future ArgumentErrors.

• Bugfix: Add 'request.temperature' to ruby-openai chat completion summaries

  Previously, the agent was not reporting the request.temperature attribute on LlmChatCompletionSummary events through ruby-openai instrumentation. We are now reporting this attribute.

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 to true 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 with llm.. 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 calculating token_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