Description

Today, we have @sentry/node which out of the box comes with a lot of (OpenTelemetry-based) auto instrumentation.

While this is the default experience we want for our users - e.g. no need to install further packages - it can be annoying for certain users:

1. Users who do not care about performance monitoring, do not need to pull in all these node dependencies
2. Users who have their own OTEL setup may run into problems with conflicts of versions
3. Users who do not care about performance auto-instrumentation, for example if you instrument a CLI or similar things

For these users, we should look into providing an easier way to get the Sentry experience they deserve. For example, we could add a @sentry/node-core package, which is more or less the node package minus all the OTEL instrumentation packages. Then, the @sentry/node package could extend this and add the respective auto instrumentation. The node-core package would only register our own custom http & fetch instrumentation to get the core functionality we need working (this is already basically done for http, for fetch still TODO: #15212)

With this, users could choose to do:

import * as Sentry from '@sentry/node-core';

Sentry.init({
  dsn: 'xxx',      
});

And would get a fully working Sentry instance, but without performance auto-instrumentation & otel instrumentation package dependencies.

We may also want to use this SDK to allow custom OTEL setups as well. This means that this SDK could ship without any otel packages as dependencies, instead requiring them as peer dependencies, making the setup slightly harder, but allowing more flexibility for users.

Notes / Thoughts

Some additional pointers for implementation:

• The node core SDK needs a httpIntegration & fetchIntergation which basically only register SentryHttpInstrumentation and SentryNodeFetchInstrumentation. The node SDK must extend these and register the additional otel instrumentations, as we already do today