@sentry/node: Stop bringing (explicit) opentelemetry dependencies

[klippx]

We have an important issue to share with the fact that @sentry/node brings a lot of opentelemetry dependencies. Not only does it add bloat for people not using it (see #13846) it actually causes runtime issues for those people that DO use opentelemetry.

In our mono-repo we have services that are deployed with opentelemetry tracing and metrics, being sent to an OTEL sidecar, pushing metrics and tracing to tools such as elastic, prometheus, grafana, etc.

As such, we have our own explicit dependency to @opentelemetry/instrumentation-http since we use it in our instrumentation, and it is being kept on latest version at all times using Renovate. Currently the latest version is 0.57.1, but wait, why is our otel sidecar exporters suddenly screaming?

[otel-collector] collected metric <metric info> was collected before with the same name and label values

After a few days of testing this and that and looking at all the wrong things, we finally got an important clue by using the debug log exporter in the otel-collector sidecar helped us crack the case, as we saw the curious InstrumentationScope names:

InstrumentationScope @opentelemetry/instrumentation-http 0.57.1
InstrumentationScope @opentelemetry_sentry-patched/instrumentation-http 0.56.0

What are these names, where do they come from? Well, it brought our attention to @sentry/node and we got a sudden hunch that we found the culprit, and this might be due to having multiple package versions of @opentelemetry/instrumentation-http; both of which are reporting metrics and consequently pushing duplicate metrics!

Let's see:

$ yarn why @opentelemetry/instrumentation-http
├─ @sentry/node@npm:8.51.0
│  └─ @opentelemetry/instrumentation-http@npm:0.56.0 [8db7d] (via npm:0.56.0 [8db7d])
│
└─ @vcc/shared@workspace:shared
   └─ @opentelemetry/instrumentation-http@npm:0.57.1 [766b1] (via npm:0.57.1 [766b1])

Oh yea. What is @sentry/node even doing bringing an explicit dependency to @opentelemetry/instrumentation-http? But whatever, let's try to pin this to 0.56.0... 1h later: YES, that fixed the issue.

But now let's figure out why this was never a problem before. We have had Sentry 8.x since May 2024 and this issue happened in the last 2-4 weeks. The explanation is simple: Renovate and vigilant upgrades of both @sentry/node and @opentelemetry/* packages.

• In 8.x Sentry maintainers were keeping the dependency to @opentelemetry/instrumentation-http up to date and never lagging
• But now that 9.x alpha is being worked on, the 8.x branch is no longer kept up to date with these dependencies and @opentelemetry/instrumentation-http has gotten stale
• As such, we are effectively "frozen" on whatever versions of @opentelemetry/* packages is in the latest 8.x version or we will face the consequences as shown above until 9.x is out which let's be honest can be weeks/months for all we know

Summary

@sentry/node has explicit dependencies to @opentelemetry/* packages.

What does this mean?

It means that you need to release a new version of @sentry/node immediately after a package bump to any of the @opentelemetry/* packages that you "depend" on.

For us, this means that we have to manually (nasty word) keep @opentelemetry/* versions in sync with whatever @sentry/node decided to bring to the party 😠 Which is not feasible. We need this to be automated by Renovate, and we will not let a bad package rain on our parade. And we cannot be "frozen" on the 8.x versions, there are a ton of different @opentelemetry/* packages on different 0.x and 1.x versions that have implicit dependencies on each other, so we always want to be on the latest for all these packages.

Action required

Can you please reconsider this for 9.x ?

• Perhaps consider loosen up the version ranges to allow 0.57.1 from our host project, instead of hard pinning it to 0.56.0 ?
• Perhaps consider using it as peer dependency so your package doesn't add colliding versions?
• Perhaps publish it as a separate package @sentry/node-opentelemetry to get it out of our hair?

[mydea]

This was discussed a bit in another discussion, but just to clean this up here:

We will look into #15213, which should make this possible. That will still ship otel dependencies (e.g. @opentelemetry/core or @opentelemetry/sdk-trace-base), but only in a limited way and in reasonable ranges, no <0 packages (no instrumentation packages!) that are hard to dedupe.

I'll close this discussion, further feedback on this can be gathered in the dedicated issue - thank you for bringing things like this up, we're always trying to find a good balance between "easy out of the box experience" and "make it possible to do specific things nicely".