a plan for redis instrumentation

[trentm]

Currently we have:

• @opentelemetry/instrumentation-redis which instruments redis@2 (last release 2017-08-08) and redis@3 (last release 2021-04-20), and
• @opentelemetry/instrumentation-redis-4 which instruments redis@4 (active)
• nothing instruments redis@5 (first release 2025-04-30)

Proposal

tl;dr: We move to one @opentelemetry/instrumentation-redis that instruments redis@4 and redis@5. We drop support for instrumenting older versions of redis.

Details for the legacy package:

• "plugins/node/opentelemetry-instrumentation-redis" is moved to "archive/instrumentation-redis-legacy/"
• We open an issue specifically about the instrumentation support for redis@2 and redis@3 no longer getting releases. This remains open for a period of time (3 months? 6 months?) where users can give feedback on whether they still use/need this instrumentation -- indicating if they are willing to be or find a maintainer/code-owner for the instrumentation.
• At the end of that period, OTel JS maintainers decide if there is a need to revive the instrumentation. If so, it returns as plugins/node/instrumentation-redis-legacy with the package name @opentelemetry/instrumentation-redis-legacy. If not, the "archive/..." code is replaced with just a README.md similar to the archived "browser-extension-autoinjection".

Details for the current @opentelemetry/instrumentation-redis-4 package:

• "plugins/node/opentelemetry-instrumentation-redis-4" stays in the same dir (in anticipation of chore: rename workspace dirs to match the base of the package name #2223 being revived, and avoiding two directory moves).
• However, it changes to being published as @opentelemetry/instrumentation-redis.
• @opentelemetry/auto-instrumentations-node updates to this new release and removes @opentelemetry/instrumentation-redis-4 -- effectively dropping support for redis@2 and redis@3.
• The @opentelemetry/instrumentation-redis-4 package in npm is marked deprecated with a pointer to the new package and issue explaining the move.
• Separately, support for redis@5 is added to the new @opentelemetry/instrumentation-redis package.
• (Possibly the new package release could jump a number of minor versions as a signal of significant change, e.g. from 0.48.0 to 0.100.0 or something.)
• The @opentelemetry/redis-common package is deprecated, moved to the "archive/" dir, and its (small) code is moved into the modern instr-redis package.

Open questions:

• Q1: Do we want to do a single release of @opentelemetry/instrumentation-redis-legacy so that it is relatively straightforward for a user to install both the legacy and modern redis instrumentations in the same app (without having the use npm package aliases) to instrument old and modern versions of redis?

Troubleshooting:

• A user with manual OTel bootstrap code that uses instr-redis and instr-redis-4 and naively updates to latest will get double instrumentation of redis@4. We could consider a final release of instr-redis-4 that disables itself by default.
• Users that update to the latest auto-instrumentations-node and that have getNodeAutoInstrumentations({'@opentelemetry/instrumentation-redis-4': ...}) will have that config no longer apply. We could update getNodeAutoInstrumentations to support the old ...-redis-4 configuration key with a deprecation warning for a period of time.

Alternatives considered

• I briefly considered updating instrumentation-redis to support redis 2, 3, and 4 by merging in the code in "plugins/node/opentelemetry-instrumentation-redis-4". I think this would be straightforward. However, given how old redis 2 and 3 are, it seemed like a waste of time. Redis 3 is four years old at this point. Is there value in supporting it? In addition, some of the same coordination with auto-instrumentation-node above would need to be done. I'm not totally opposed to this alternative.

[pichlermarc]

I support this plan. 👍

Q1: Do we want to do a single release of @opentelemetry/instrumentation-redis-legacy so that it is relatively straightforward for a user to install both the legacy and modern redis instrumentations in the same app (without having the use npm package aliases) to instrument old and modern versions of redis?

I think this could be helpful - though I feel redis@3 should be old enough by now for us to drop it without replacement, it still seems to steadily sit at about 1M downloads per week. I'll let you make the call if the extra effort is worth it.

A user with manual OTel bootstrap code that uses instr-redis and instr-redis-4 and naively updates to latest will get double instrumentation of redis@4. We could consider a final release of instr-redis-4 that disables itself by default.

Q: can redis@4 ever be double-wrapped? IIUC the instrumentation that comes last is the only one that gets to wrap, all others loose out as isWrapped() will return true, so the instrumentation that comes later will unwrap the previous one.

Users that update to the latest auto-instrumentations-node and that have getNodeAutoInstrumentations({'@opentelemetry/instrumentation-redis-4': ...}) will have that config no longer apply. We could update getNodeAutoInstrumentations to support the old ...-redis-4 configuration key with a deprecation warning for a period of time.

Having one version that does this could be helpful.

So IIUC the order of things would be:

• rename @opentelemetry/instrumentation-redis -> @opentelemetry/instrumentation-redis-legacy
• remove @opentelemetry/instrumentation-redis from @opentelemetry/auto-instrumentations-node
• rename @opentlemeetry/instrumentation-redis-4 -> @opentelemetry/instrumentation-redis
• add back @opentelemetr/instrumentation-redis-4 option to @opentelemetry/auto-instrumentations-node, deprecate it
• possibly also add a warning log for all non-typescript users
• release contrib
• continue with Support redis v5 #2830
• after some time: remove the deprecated option from @opentelemetry/auto-instrumentations-node

[trentm]

IIUC the instrumentation that comes last is the only one that gets to wrap, all others loose out as isWrapped() will return true

Ah, good point. You are right.

[trentm]

The maintainers discussed this this morning and @blumamir mentioned that he has a merge on the go (not quite a draft PR yet) that would basically do the first "Alternatives considered". I don't know the exact set of steps, but the result would be a instrumentation-redis with support for redis 2,3,4, and 5.

[trentm]

BTW the argument in favour of keeping support for redis 2 and 3 is that they still have large numbers of npm downloads.

https://www.npmjs.com/package/redis?activeTab=versions

3.1.2	961,739	4 years ago
2.8.0	337,171	8 years ago

I guess we'll never know what percentage of npm download numbers are CIs running silently ("If a tree falls in the forest...").