feat(node-experimental): Add @sentry/node-experimental package as MVP for POTEL#8609
feat(node-experimental): Add @sentry/node-experimental package as MVP for POTEL#8609
@sentry/node-experimental package as MVP for POTEL#8609Conversation
| ## 1.1 Types | ||
| - name: npm | ||
| id: "@sentry/types" | ||
| id: '@sentry/types' |
There was a problem hiding this comment.
Prettier changed this for me 😅 Hope that's OK...
There was a problem hiding this comment.
Ahh yes, when I worked on this, my prettier/vscode settings were broken and apparently our lint check didn't catch it. Should be fine.
0da5946 to
ae4abfb
Compare
|
Q: We could also publish this as |
size-limit report 📦
|
Lms24
left a comment
There was a problem hiding this comment.
Nice, LGTM from a higher-level perspective. I only have limited context on the otel-specific parts but I like the overall concept of "just" wrapping the otel instrumentation with our integration class.
| ## 1.1 Types | ||
| - name: npm | ||
| id: "@sentry/types" | ||
| id: '@sentry/types' |
There was a problem hiding this comment.
Ahh yes, when I worked on this, my prettier/vscode settings were broken and apparently our lint check didn't catch it. Should be fine.
| ```yml | ||
| - name: npm | ||
| id: npm:@sentry/[yourPackage] | ||
| id: '@sentry/[yourPackage]' |
There was a problem hiding this comment.
good catch, I forgot to adjust this
| import type { Postgres } from './postgres'; | ||
| import type { Prisma } from './prisma'; | ||
|
|
||
| const INTEGRATIONS = [ |
There was a problem hiding this comment.
l (no action required):
I wonder if this is a good idea. The requires prolong startup time and that's an issue for serverless environments. But as I said, no action required at this time, we can revisit this later.
There was a problem hiding this comment.
You mean to use this by default? The way this works I copied from the node auto discovery, only there it is opt-in via Sentry.autoDiscoverNodePerformanceMonitoringIntegrations().
With this setup, if you want to/need to avoid this, you can disable default integrations and opt-in to just the ones you want. Not sure if that is the best approach 🤔
There was a problem hiding this comment.
Yes, I was concerned about making this opt-in. iirc we discussed dropping autoDiscoverNodePerformanceMonitoringIntegrations entirely in v7 because of the performance implications but decided to make it opt-in. I don't want to block this PR though so it's fine as is for now. Just wanted to bring this up.
There was a problem hiding this comment.
Yeah, we can def. re-evaluate this, for now this is really experimental, and this specific part is easily changed later :) But let's keep this in mind! 👍
|
|
||
| addOtelSpanData(span.spanContext().spanId, additionalData); | ||
|
|
||
| getCurrentHub().addBreadcrumb( |
There was a problem hiding this comment.
m: do we need to check if the Breadcrumbs integration is configured to record http breadcrumbs?
(Not sure about this, I just know that I had to do this for client-side sveltekit fetch)
There was a problem hiding this comment.
Hmm not sure, if I look at the hub in core it has this method always 🤔 that delegates to scope.addBreadcrumb, which also seems to always be defined.
There was a problem hiding this comment.
Sorry, I mixed up the integrations, I rechecked and saw that the current Http integration has a breadcrumbs option which you added here as well.
but shouldn't we nevertheless guard this line with this._breadcrumbs? afaict we only check this._breadcrumbs at the beginning to early return if both, breadcrumbs and tracing are disabled.
There was a problem hiding this comment.
hah, you're absolutely right of course, completely forgot this 😅 good catch, will add the guard!
dc141b9 to
419629d
Compare
Lms24
left a comment
There was a problem hiding this comment.
Q: We could also publish this as
@sentry-internal/node-experimental? 🤔 WDYT?
I think the @sentry/ namespace is totally fine. We clearly mark it as experimental so I don't see a problem. But no strong opinions either, so ultimately whatever you prefer.
| * Receives the Otel Span as argument. | ||
| * Return `false` from the callback to skip this span in Sentry. | ||
| */ | ||
| public on(hook: 'spanEnd', callback: (otelSpan: OtelSpan, sentrySpan: Span) => void | false): void; |
There was a problem hiding this comment.
Why can't we just use hooks on the default client? We can just append with experimental
I'd like to avoid using a separate class if we can.
There was a problem hiding this comment.
The idea here was because we need this to have a possible return value, which we don't support right now (for a reason, makes stuff easier). Also I wanted to avoid adding an experimental hook because it is kind of public API then and we can't remove it again? but maybe that doesn't matter as well... 🤔
Thinking about this, one API that could work is:
const mutableOptions = { drop: false };
client.emit('otelSpanEnd', otelSpan, mutableOptions);
if (mutableOptions.drop) {
// drop this span
}
// And at hook register site
client.on('otelSpanEnd', (otelSpan, mutableOptions) => {
if (shouldDropSpan(otelSpan) {
mutableOptions.drop = true;
}
});WDYT about this?
There was a problem hiding this comment.
I changed it to use otelSpanEnd hook on the general client!
094c28e to
74900c0
Compare
Co-authored-by: Lukas Stracke <lukas.stracke@sentry.io>
74900c0 to
4319909
Compare
This introduces a new package
@sentry/node-experimental, which is an MVP implementation for Performance powered by OTEL (POTEL).This package provides a wrapper over
@sentry/node(also using@sentry/opentelemetry-node) which uses opentelemetry for performance instrumentation under the hood.This is all abstracted away from the user, they only need to do:
And it will set up all the necessary integrations etc. for the user, including the default integrations + any applying performance integrations.
For this, I added all performance integrations that exist for node, minus undici (which will take some more work to get going), plus some new stuff: mysql, fastify, nest. Also, mongoose is it's own integration now, not handled via mongo anymore.
Note that I've only manually tested express & http so far. All others still need to be verified etc. But this is really a POC, which may go somewhere or not - by publishing this, it becomes super easy to try this in various scenarios.
I have tweaked the Http integration to create more or less the same output as we're used to for Sentry. I also made small tweaks to
@sentry/opentelemetry-nodeto allow us to communicate with this a bit better. There are two main use cases I've identified there:spanEnd.