Advice for APM/Observability Agents?

Hello! We maintain an APM Agent that instruments this redis library. If you're not familiar with APM agents the TL;DR; is whenever there's a redis command we create something called a "span object" to represent that command, the time it took for that command to finish, and link it to other span objects that represent the HTTP request, and ship those span object to a central server. APM Agents allow users to monitor their applications and services. (New Relic, Data Dog, Elastic APM, Honeycomb, etc.)

Traditionally when we instrument a library like this we use method/module wrapping (sometimes called Monkey Patching) to change the definition of a method in the library to create our spans. For v2 and v3 of this library we've wrapped the send_command or internal_send_command methods.

However, in v4 of the library it looks like these methods no long exist, and that the closest analog, sendComand, is a private TypeScript method which generates a bunch of unwrappable raw javascript. Additionally, wrapping the queue object could be another option but this.#queue is similarly private, as is #initiateQueue

Another option is for us to instrument createCommand and wrap the returned client instance object, but wrapping every redis command is a bit heavier handed that we usually like to be.

It's certainly your right as open source maintainers to create whatever sort of public/private API you like -- but the use of private methods has really blocked us from giving our users the experience they've come to expect.

Do you have any advice for how APM Vendors like us can instrument version four of this library?

Review the v4 entry points mentioned in the issue: sendComand, createCommand, the queue object, and #initiateQueue. Compare them with the v2 and v3 send_command or internal_send_command instrumentation points, then determine what supported instrumentation path or API guidance is needed for APM vendors.