Skip to content
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

Instrumentation Middleware introduced too late for desired error reporting #66

Closed
kaylareopelle opened this issue Nov 12, 2022 · 2 comments

Comments

@kaylareopelle
Copy link

I'm excited to see the introduction of the Instrumentation and Middlewares API for this library! While updating the New Relic Ruby agent's Redis 5 instrumentation, I had an opportunity to test it out. (If you're curious, see: newrelic/newrelic-ruby-agent#1611)

Registering the middleware and writing the instrumentation for each method was a breeze, though it took me a while to notice its addition to the README. The methods chosen are the same methods the agent used for redis library instrumentation for years. The client object's accessibility from these methods also maintains parity with earlier versions, though accessing information like database name needed to be adjusted to client.db instead of just db.

The only issue I came up against was with error reporting. Where the middleware gets registered and instrumented leaves a much larger gap between earlier Redis operations than where the methods were located in version 4.8.0. In New Relic, this looked like the errors still getting reported on the overall request, but the individual segment where the error was raised (ex. the #get method call) wouldn't have the error.

We could still capture segment-level errors using our traditional method chaining/module prepending strategy.

This caused us to ultimately use the Middleware API only for #call_pipelined, because we couldn't get access to the command values through any other means.

Unfortunately, I don't have any solutions to offer at this time. Since my work on Redis instrumentation has wrapped up for now, I wanted to drop this here in case others have ideas or similar experiences, and to remind me of where these thoughts left off when I am able to circle back.

Thank you for your efforts maintaining this library and making instrumentation more accessible!

@casperisfine
Copy link
Collaborator

Where the middleware gets registered and instrumented leaves a much larger gap between earlier Redis operations than where the methods were located in version 4.8.0.

I'm sorry, I'm not sure I understand what you mean here. Do you mean it's instrumenting lower in the stack than before? If so, how is it a problem?

@casperisfine
Copy link
Collaborator

Closing as non-actionable. I'll re-open if you provide more information.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants