feat(nextjs): Use OpenTelemetry for performance monitoring and tracing#11016
feat(nextjs): Use OpenTelemetry for performance monitoring and tracing#11016
Conversation
size-limit report 📦
|
33a4f94 to
815b156
Compare
In order to proceed with removing `Sentry.Integrations.X` as per #8844, there's still some places to clean up. This does conflict with #11016, but not sure when that merges in, so opening this in the meantime to unblock the integrations cleanup work. if we think the OTEL nextjs work will merge in sooner then the next 1-2 days, I'm happy to leave this alone for now!
3b4fa31 to
3b5d9ce
Compare
| "wait-port": "1.0.4" | ||
| }, | ||
| "devDependencies": { | ||
| "@sentry-internal/feedback": "latest || *", |
There was a problem hiding this comment.
I think so, at least I couldn't be bothered to filter them out. These are all deps that nextjs depends on or could ever depend on.
| 'http.method': 'GET', | ||
| 'sentry.op': 'http.client', | ||
| 'sentry.origin': 'auto.http.node.undici', | ||
| 'next.span_type': 'AppRender.fetch', // This span is created by Next.js own fetch instrumentation |
There was a problem hiding this comment.
l: We could think about adding sentry.origin: 'auto.http.nextjs.fetch' or something like this if we detect this.
There was a problem hiding this comment.
I have started a broader discussion around this topic last week because we need a generic decision in all SDKs for this. The important question being: "What sentry.origin do we give spans that are not generated through Sentry SDK API?" Right now it is manual - which is obv wrong. I'd argue we don't set anything, because sentry.origin doesn't make sense anymore.
mydea
left a comment
There was a problem hiding this comment.
Looking great! Left some small nitty-comments, great work (the outcome always looks so simple...! "it just works, what do you mean this was tricky???")
| // if (nextjsVersion !== 'latest' && nextjsVersion !== 'canary') { | ||
| // assert.doesNotMatch(buildStderr, /Import trace for requested module/); // This is Next.js/Webpack speech for "something is off" | ||
| // } | ||
| // Note(lforst): I disabled this for the time being to figure out OTEL + Next.js - Next.js is currently complaining about a critical import in the @opentelemetry/instrumentation package. |
There was a problem hiding this comment.
For reference, what exactly is it complaining about?
There was a problem hiding this comment.
Added a comment with an example!
| "@playwright/test": "^1.27.1" | ||
| }, | ||
| "devDependencies": { | ||
| "@sentry-internal/feedback": "latest || *", |
packages/nextjs/src/server/index.ts
Outdated
|
|
||
| const filterTransactions: EventProcessor = event => { | ||
| return event.type === 'transaction' && event.transaction === '/404' ? null : event; | ||
| const filterLowQualityTransactions: EventProcessor = event => { |
There was a problem hiding this comment.
Is it on purpose that we are not filtering /404 transactions anymore here? (or do these not exist anymore?)
There was a problem hiding this comment.
Right, I think I accidentally removed this - added it back!
packages/nextjs/src/server/index.ts
Outdated
|
|
||
| const filterTransactions: EventProcessor = event => { | ||
| return event.type === 'transaction' && event.transaction === '/404' ? null : event; | ||
| const filterLowQualityTransactions: EventProcessor = event => { |
There was a problem hiding this comment.
l: This is fine, but could also possible be simplified to:
addEventListener(Object.assign((event: Event) => {
// ...
}, { id: 'NextLowQualityTransactionsFilter' }));Not sure how much better, but avoids some local variables - feel free to ignore or not :D
packages/nextjs/src/server/index.ts
Outdated
| // Filter out spans for Sentry event sends | ||
| const httpTargetAttribute: unknown = span.data?.['http.target']; | ||
| if (typeof httpTargetAttribute === 'string') { | ||
| // TODO: Find a more robust matching logic |
There was a problem hiding this comment.
We should use suppressTracing here 🤔 something to look into in the future!
There was a problem hiding this comment.
to be clear, with "here" I mean in the transport :D
There was a problem hiding this comment.
Yep, I'll add a TODO to potentially revisit this in the future.
|
|
||
| filterTransactions.id = 'NextServer404TransactionFilter'; | ||
| addEventProcessor( | ||
| Object.assign( |
There was a problem hiding this comment.
should we add these as integrations?
There was a problem hiding this comment.
Maybe in a followup. I want this pr closed asap.
740805b to
ad74746
Compare
ad74746 to
9858846
Compare
9858846 to
65f3e73
Compare
In order to proceed with removing `Sentry.Integrations.X` as per getsentry#8844, there's still some places to clean up. This does conflict with getsentry#11016, but not sure when that merges in, so opening this in the meantime to unblock the integrations cleanup work. if we think the OTEL nextjs work will merge in sooner then the next 1-2 days, I'm happy to leave this alone for now!
getsentry#11016) Co-authored-by: s1gr1d <sigrid.huemer@posteo.at>
With this change, there are two remaining references to node-experimental. 1. nextjs, which is handled by getsentry#11016 2. express integration tests, which I will address after getsentry#11285 gets merged Once those two are done, we can remove the old node packages entirely!
Next.js provides their own OTel http integration, which conflicts with ours ref getsentry#11016 added commit from this PR: getsentry#11319 --------- Co-authored-by: Luca Forstner <luca.forstner@sentry.io> Co-authored-by: Francesco Novy <francesco.novy@sentry.io>
This PR moves the Next.js over to OpenTelemetry based performance monitoring.
Resolves #11042
Follow-up items: