OTel instrumentation package for the TracingChannel API (subscriber side of #4178)

[Vunovati]

Hi @wellwelwel, @logaretm

PR #4178 added TracingChannel support to mysql2. I've built
the subscriber side: an OpenTelemetry instrumentation package that listens to
the mysql2:query, mysql2:execute, mysql2:connect, and mysql2:pool:connect
channels and produces proper OTel spans.

Here is the Package: mysql2-otel-instrumentation

and the Repo: mysql2-otel-instrumentation

What it does differently from @opentelemetry/instrumentation-mysql2

The existing OTel instrumentation uses RITM (require-in-the-middle) to
monkey-patch Connection.prototype.query and Connection.prototype.execute.
This package does not monkey-patch. It is a simple diagnostics_channel subscriber.

	@opentelemetry/instrumentation-mysql2	This package
Approach	RITM monkey-patching	TracingChannel subscriber
mysql2 version	any	≥3.20.0
Node.js version	≥14	≥20
ESM safe	fragile (IITM)	yes
Initialization order	must load before mysql2	no constraint
RITM/IITM dependency	yes	none

Why this belongs close to mysql2

The OTel JS ecosystem is actively moving toward library-owned instrumentation.
The most recent precedent: @opentelemetry/instrumentation-fastify was deprecated
in January 2025 and removed in March 2026 in favor of @fastify/otel, maintained
by the Fastify team.

This package is the direct subscriber counterpart to the work done by @logaretm in #4178.

The ask

Would you be willing to add a link to this package in the mysql2 docs? Something minimal like:

## Tracing / Observability

For OpenTelemetry instrumentation based on the native TracingChannel API
(mysql2 ≥3.20.0, Node.js ≥20), see [mysql2-otel-instrumentation](https://www.npmjs.com/package/mysql2-otel-instrumentation).

Happy to open a PR for that if you're open to it.

[logaretm]

I hold no opinion to include or not include this in docs, but just sharing my thoughts here. I think tracing channels bring an interesting fork in the road for the ecosystem in these cases, like you demonstrated you can have high quality custom 3rd party instrumentation with very low cost (no RITM, no patches, nothing to undo, subscribe at anytime, native APIs with zero deps).

I wonder if OTEL would be interested in switching their instrumentations gradually to adopt tracing channels subscriptions, would you run it by them to see what they think?

On the other hand with the cost of building instrumentations being cheap now, would OTEL even want to maintain their first party instrumentations for these libraries anymore?

[Vunovati]

Thanks for sharing your thoughts @logaretm

I'm opening an issue in opentelemetry-js-contrib today. I'll link the issue here once it's up. (edit: open-telemetry/opentelemetry-js-contrib#3467)

On whether OTel would want to maintain first-party instrumentations for libraries
that now ship TracingChannels: my instinct is no, at least not in their current
form. If we take the Fastify as a role model ... once the library owns the instrumentation story, the contrib package becomes redundant... but let's see what they say.