Implement Node Core SDK

[mydea]

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

[nwalters512]

This would be a huge benefit to me and my team. The fact that @sentry/node pins OTel deps means that I either have to a) wait for Sentry to update them, b) pin to older versions in my project to avoid duplicates, or c) contribute the upgrades to Sentry myself (which I've been trying to do, see #15098 and related PRs). I'd love it if I could install a version of Sentry that doesn't come with OTel dependencies and just use it for error reporting (which Sentry is fantastic at).

[pckilgore]

Seconded a way to install the baby (sentry error monitoring) without the bathwater (otel stack). We've wasted far too many of our team's limited observability calories on otel things broken by incredibly convoluted dependency issues created by the sentry packages.

[lforst]

@pckilgore we agree with you. We're gonna start looking into this soon. If you have any special requirements, please note them here so we can consider them when building a solution.