-
Notifications
You must be signed in to change notification settings - Fork 601
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for redis-clustering gem #2720
Conversation
@@ -33,6 +34,10 @@ | |||
NewRelic::Agent.logger.info('Installing Redis Instrumentation') | |||
if NewRelic::Agent::Instrumentation::Redis::Constants::HAS_REDIS_CLIENT | |||
RedisClient.register(NewRelic::Agent::Instrumentation::RedisClient::Middleware) | |||
|
|||
if defined?(Redis::Cluster::Client) | |||
return RedisClient.register(NewRelic::Agent::Instrumentation::RedisClient::ClusterMiddleware) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
redis-clustering doesn't need prepend
nor chain
instrumentation, those methods are instrumented in the ClusterMiddleware
.
# Until we decide to move our Redis instrumentation entirely off patches | ||
# keep the middleware instrumentation for the call and connect methods | ||
# limited to the redis-clustering instrumentation. | ||
# | ||
# Redis's middleware option does not capture errors as high in the stack | ||
# as our patches. Leaving the patches for call and connect on the main | ||
# Redis gem limits the feature disparity our customers experience. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see this as a way to have a clean break for new Redis instrumentation. However, it does provide an inferior experience for error handling. We can look more closely into monkey-patching these methods, but we'll need to patch methods differently than we do for the main Redis gem.
@@ -59,6 +59,8 @@ def test_records_metrics_for_connect | |||
end | |||
|
|||
def test_records_connect_tt_node_within_call_that_triggered_it | |||
skip_for_redis_clustering_gem |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the end, it seemed the least intrusive to add skips for the six tests that are not compatible with redis-clustering instrumentation:
- We can't test with
Redis::Cluster.new
because we don't have a cluster mode enabled service running for our tests, so we're faking the "cluster" testing regardless - We don't have a different configuration option for
redis-clustering
than we do forredis
, so the prepend/chain configurations seemed excessive - Skipping the tests feels easier to read and understand the feature disparity between the two gems quickly
Open to further discussion to take a different approach!
Co-authored-by: James Bunch <[email protected]>
…agent into redis-clustering
* Log the failure message at the debug level * Check for the presence of the #db method on the client config object using respond_to?
SimpleCov Report
|
The
redis-clustering
gem provides the ability to use Redis in cluster mode for Ruby. Cluster mode is enabled by default for AWS Elasticache Redis clusters.The
redis-clustering
move was part of the large refactor of the Redis gem in the 5.0 release. It can leverage RedisClient middleware to instrument code.This PR provides the following:
db
method that is compatible with the Redis gem for all our supported versions, renamed tonr_db
NewRelic::Agent::Instrumentation::RedisClient::ClusterMiddleware
, that provides instrumentation for thecall
andconnect
methods.call
andconnect
methods because they are invoked too late to capture certain errors. Keeping module prepending for these methods keeps feature parity for users of newer Redis versionsResolves #2444