Large number of OTel instrumentation dependencies installed by Sentry

[nwalters512]

In recent releases, the number of OpenTelemetry instrumentation packages installed by @sentry/node has ballooned to 21:

    "@opentelemetry/instrumentation-amqplib": "npm:^0.42.0"
    "@opentelemetry/instrumentation-connect": "npm:0.39.0"
    "@opentelemetry/instrumentation-dataloader": "npm:0.12.0"
    "@opentelemetry/instrumentation-express": "npm:0.42.0"
    "@opentelemetry/instrumentation-fastify": "npm:0.39.0"
    "@opentelemetry/instrumentation-fs": "npm:0.15.0"
    "@opentelemetry/instrumentation-generic-pool": "npm:0.39.0"
    "@opentelemetry/instrumentation-graphql": "npm:0.43.0"
    "@opentelemetry/instrumentation-hapi": "npm:0.41.0"
    "@opentelemetry/instrumentation-http": "npm:0.53.0"
    "@opentelemetry/instrumentation-ioredis": "npm:0.43.0"
    "@opentelemetry/instrumentation-kafkajs": "npm:0.3.0"
    "@opentelemetry/instrumentation-koa": "npm:0.43.0"
    "@opentelemetry/instrumentation-mongodb": "npm:0.47.0"
    "@opentelemetry/instrumentation-mongoose": "npm:0.42.0"
    "@opentelemetry/instrumentation-mysql": "npm:0.41.0"
    "@opentelemetry/instrumentation-mysql2": "npm:0.41.0"
    "@opentelemetry/instrumentation-nestjs-core": "npm:0.40.0"
    "@opentelemetry/instrumentation-pg": "npm:0.44.0"
    "@opentelemetry/instrumentation-redis-4": "npm:0.42.0"
    "@opentelemetry/instrumentation-undici": "npm:0.6.0"

These comprise many megabytes of dependencies that increase install times and bloat the size of our container images with absolutely zero value for our team, application, or users.

Is there any chance that we'll get a @sentry/node-core or similar package that doesn't include this OpenTelemetry bloat? This would mirror what OpenTelemetry itself does: @opentelemetry/auto-instrumentations-node can be used by anyone who wants all possible instrumentation, but one can still piece together their own setup by manually installing and configuring just the constituent packages that they need.

If not: what'll happen in the long run here? The official OTel autoinstrumentation package is up to 39 @opentelemetry/instrumentation-* dependencies, with more being periodically added. Will @sentry/node just keep adding more and more dependencies to keep up?

[lforst]

Your concern is very valid. Up until now we just kept adding deps for the simple reason that we want to make it dead simple to set up Sentry. I am starting to think that this could go south long term when thinking about, maintenance, reliability, and security.

I don't have a specific answer for you but I will take this to the team and discuss.

[nwalters512]

Thanks! FWIW, in the past couple of weeks, two more instrumentation packages have made it onto the list. Here's the current collection on develop:

    "@opentelemetry/instrumentation-amqplib": "^0.42.0",
    "@opentelemetry/instrumentation-connect": "0.40.0",
    "@opentelemetry/instrumentation-dataloader": "0.12.0",
    "@opentelemetry/instrumentation-express": "0.44.0",
    "@opentelemetry/instrumentation-fastify": "0.40.0",
    "@opentelemetry/instrumentation-fs": "0.16.0",
    "@opentelemetry/instrumentation-generic-pool": "0.39.0",
    "@opentelemetry/instrumentation-graphql": "0.43.0",
    "@opentelemetry/instrumentation-hapi": "0.41.0",
    "@opentelemetry/instrumentation-http": "0.53.0",
    "@opentelemetry/instrumentation-ioredis": "0.43.0",
    "@opentelemetry/instrumentation-kafkajs": "0.4.0",
    "@opentelemetry/instrumentation-koa": "0.43.0",
    "@opentelemetry/instrumentation-lru-memoizer": "0.40.0",
    "@opentelemetry/instrumentation-mongodb": "0.47.0",
    "@opentelemetry/instrumentation-mongoose": "0.42.0",
    "@opentelemetry/instrumentation-mysql": "0.41.0",
    "@opentelemetry/instrumentation-mysql2": "0.41.0",
    "@opentelemetry/instrumentation-nestjs-core": "0.40.0",
    "@opentelemetry/instrumentation-pg": "0.44.0",
    "@opentelemetry/instrumentation-redis-4": "0.42.0",
    "@opentelemetry/instrumentation-undici": "0.6.0",

[lforst]

It's on our radar. Fwiw this will not be changed all too quickly. We need to figure out a way that aligns with how we want setup to work and generally find a story around how a less heavy node SDK can look.