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.
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.
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.
Identify Amazon Timestream when the amazon_timestream AR adapter is used
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)
Bumps newrelic_rpm from 8.16.0 to 9.2.0.
Release notes
Sourced from newrelic_rpm's releases.
Changelog
Sourced from newrelic_rpm's changelog.
... (truncated)
Commits
11c2da9Merge pull request #1948 from newrelic/upadate-actions-for-releasee405ac1Update permissions for actions34b3143Merge pull request #1944 from newrelic/update_release_permissionsf0154deAdd repository-projects permission to release.yml5873cc8Merge pull request #1942 from newrelic/prep_version_9_2_076af839Update CHANGELOG.md8e8841aWrite entry title in imperativee83c9b7Increment version to 9.2.064d0cd0Update cross_agent_tests GCP ID fixtures9180d15Merge pull request #1927 from newrelic/must_go_fasterDependabot 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)