-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
feat(nextjs): Use OpenTelemetry for performance monitoring and tracing #11016
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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
@@ -26,8 +26,20 @@ | |||
"wait-port": "1.0.4" | |||
}, | |||
"devDependencies": { | |||
"@sentry-internal/feedback": "latest || *", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need all of these?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
@@ -13,7 +13,7 @@ test('Should send a transaction with a fetch span', async ({ page }) => { | |||
data: expect.objectContaining({ | |||
'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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For reference, what exactly is it complaining about?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a comment with an example!
@@ -29,8 +29,20 @@ | |||
"@playwright/test": "^1.27.1" | |||
}, | |||
"devDependencies": { | |||
"@sentry-internal/feedback": "latest || *", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need all of these?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as #11016 (comment)
packages/nextjs/src/server/index.ts
Outdated
@@ -117,19 +113,67 @@ export function init(options: NodeOptions): void { | |||
|
|||
nodeInit(opts); | |||
|
|||
const filterTransactions: EventProcessor = event => { | |||
return event.type === 'transaction' && event.transaction === '/404' ? null : event; | |||
const filterLowQualityTransactions: EventProcessor = event => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, I think I accidentally removed this - added it back!
packages/nextjs/src/server/index.ts
Outdated
@@ -117,19 +113,67 @@ export function init(options: NodeOptions): void { | |||
|
|||
nodeInit(opts); | |||
|
|||
const filterTransactions: EventProcessor = event => { | |||
return event.type === 'transaction' && event.transaction === '/404' ? null : event; | |||
const filterLowQualityTransactions: EventProcessor = event => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
love it
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should use suppressTracing
here 🤔 something to look into in the future!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
to be clear, with "here" I mean in the transport :D
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we add these as integrations?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe in a followup. I want this pr closed asap.
740805b
to
ad74746
Compare
ad74746
to
9858846
Compare
9858846
to
65f3e73
Compare
Next.js provides their own OTel http integration, which conflicts with ours ref #11016 added commit from this PR: #11319 --------- Co-authored-by: Luca Forstner <[email protected]> Co-authored-by: Francesco Novy <[email protected]>
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 <[email protected]>
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 <[email protected]> Co-authored-by: Francesco Novy <[email protected]>
This PR moves the Next.js over to OpenTelemetry based performance monitoring.
Resolves #11042
Follow-up items: