Bump newrelic_rpm from 9.0.0 to 9.2.0

[dependabot]

Bumps newrelic_rpm from 9.0.0 to 9.2.0.

Release notes

Sourced from newrelic_rpm's releases.

9.2.0

No release notes provided.

9.2.0-pre

Prerelease for upcoming version 9.2.0.

CHANGELOG

9.1.0

No release notes provided.

9.1.0-pre

Pre-release for v9.1.0

Changelog

Sourced from newrelic_rpm's changelog.

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: The agent configuration will now reflect whether module prepending or method chaining was used for instrumentation

  For :'instrumentation.*' configuration parameters that are set to :auto (the default), the agent will automatically determine whether to use module prepending or method chaining. The agent will now update its in-memory configuration to give each relevant parameter a value of either :prepend or :chain so that the result of the determination can be introspected. This is intended to help 3rd party libraries that wish to further enhance the agent's instrumentation capabilities by prepending or chaining additional logic. Environment variable, YAML file, and server-side configuration based values are not impacted. PR#1930

• 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.

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 new enduser.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.

... (truncated)

Commits

• 11c2da9 Merge pull request #1948 from newrelic/upadate-actions-for-release
• e405ac1 Update permissions for actions
• 34b3143 Merge pull request #1944 from newrelic/update_release_permissions
• f0154de Add repository-projects permission to release.yml
• 5873cc8 Merge pull request #1942 from newrelic/prep_version_9_2_0
• 76af839 Update CHANGELOG.md
• 8e8841a Write entry title in imperative
• e83c9b7 Increment version to 9.2.0
• 64d0cd0 Update cross_agent_tests GCP ID fixtures
• 9180d15 Merge pull request #1927 from newrelic/must_go_faster
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[dependabot]

Superseded by #131.