sentry-javascript
sentry-javascript copied to clipboard
getsentry
Implement Node Core SDK
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:
- Users who do not care about performance monitoring, do not need to pull in all these node dependencies
- Users who have their own OTEL setup may run into problems with conflicts of versions
- 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: https://github.com/getsentry/sentry-javascript/issues/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&fetchIntergationwhich basically only registerSentryHttpInstrumentationandSentryNodeFetchInstrumentation. The node SDK must extend these and register the additional otel instrumentations, as we already do today
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).
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.
@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.
No special requirements. I really love sentry for the error reporting and now replay.
We have other tooling we prefer for tracing. I just want to use sentry without it touching our tracing setup.
This is a big issue for us too. We don't even use OTEL features, yet our CPU profile shows open telemetry calls are eating up HUGE % of all CPU time.
All of the highlighted entries are open telemetry related functions, out of which many are actually @sentry's own ones, notably groupSpansWithParents, which runs really hot and creates a lot of garbage.
https://github.com/getsentry/sentry-javascript/blob/a79ca7eb30794d0aa40e3d0a47853ad5fc10ef64/packages/opentelemetry/src/utils/groupSpansWithParents.ts#L14-L28
I am not a GC pro, but with the help of my friend ChatGPT, I think the issue is serious.
Potential Memory Retention Issue in Span Tree Construction
The current implementation for constructing a tree of spans creates a structure in which each SpanNode contains:
- a reference to its
parentNode, and - a list of
childrennodes.
This creates a bi-directional reference graph between parent and child spans. While Node.js (V8) garbage collection is capable of handling cycles, this structure introduces potential memory retention issues, particularly in high-throughput or long-running applications.
Why this matters
If any part of the span tree is accidentally retained—via closures, logs, metrics, or linked async contexts—the entire object graph can be kept in memory. This can result in:
- Increased memory usage over time
- More frequent and longer garbage collection pauses
- Memory leaks in worst-case scenarios
This is especially relevant when the span trees are large (e.g., hundreds or thousands of spans) and created frequently, such as in instrumentation that captures trace data on a per-request or per-batch basis.
Proposed Improvements
To mitigate these risks, one or more of the following strategies could be adopted:
-
Break reference cycles after processing
If the span tree is only needed for temporary processing, the.parentNodereferences can be explicitly removed after use:for (const node of spanNodes) { node.parentNode = undefined; }
Hey @moltar, thanks for pointing this out. Just to clarify, the node-core SDK will still have dependencies on OTel, but this will be the basic (api, core, instrumentation, ...). It will not ship with any of the node instrumentations and will not create spans.
@andreiborza As long as it does not "activate" the OTEL stuff and just ships package, I think it's fine.
Also, maybe outside the scope of this ticket, but the internal code I think needs to be optimized anyways, as this is quite bad that telemetry makes things so much worse.
This is also an issue for us, we're using Sentry for error tracking and want to use Honeycomb for distributed tracing, but as soon as I install Sentry next to Honeycomb, the whole tracing integration from OTEL stops working with Fastify, and we don't get any root spans anymore.
@andreiborza Is this already released? If so, which version? If not, when is it expected? Thank you!