-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
feat!: Bump to OpenTelemetry v2 #16872
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
base: develop
Are you sure you want to change the base?
Conversation
size-limit report 📦
|
|
||
// Access the span processors from the provider via _activeSpanProcessor | ||
// Casted as any because _activeSpanProcessor is marked as readonly | ||
const multiSpanProcessor = (provider as any)._activeSpanProcessor as |
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.
not sure, but sometimes it also works to do provider['_activeSpanProcessor']
to make TS happy!
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.
👍 worked, thanks!
6de3296
to
957a4c8
Compare
8c43c8a
to
213aa83
Compare
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.
nice work!
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.
Nice! I just had a couple of questions regarding changed attributes/data mostly. Otherwise LGTM!
@@ -65,7 +65,6 @@ test('Should record a transaction for route with parameters', async ({ request } | |||
data: { | |||
'express.name': 'query', | |||
'express.type': 'middleware', | |||
'http.route': '/', |
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.
logaf-l but our of curiosity: why was this attribute removed?
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.
The express instrumentation doesn't add it anymore to middleware spans, I didn't find anything in their changelog regarding this tho so it's more of an observation after running it 😅.
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.
Actually, this likely came from open-telemetry/opentelemetry-js-contrib#2843. Looks like it might be a bug in the instrumentation now because these spans are not for a 404 route..
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.
@s1gr1d could you take a look at that please?
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.
This was a bug before, as it was always attaching http.route
. http.route
should not be included when no route was matched (on 404).
The matched route, that is, the path template in the format used by the respective server framework.
Semantic Convention Docs: https://opentelemetry.io/docs/specs/semconv/registry/attributes/http/
But in this case it's not a 404 route 🤔
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.
Just checked: Middleware spans might not include the http.route
attribute when it's not yet known at the time the middleware runs. And 'http.route': '/'
is only added when there is an explicitly defined root route AND when when the route resolution is already done (middleware might run before that).
And why it was added before: Previously, the attribute ALWAYS defaulted to /
but this was wrong. https://github.com/open-telemetry/opentelemetry-js-contrib/pull/2843/files#diff-81c3e13c3dac53e0dd6aabf6dc165305350eb522a85a2561f9ee51d9249011e7L198
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.
Awesome, thanks so much for investigating and fixing this upstream @s1gr1d :)
}), | ||
), | ||
); | ||
const provider = new NodeTracerProvider({ |
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.
no action required: was this a breaking change in the provider class or simply a refactor?
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.
Breaking change, there's no more addSpanProcessor
in v2.
@@ -31,7 +31,11 @@ test.describe('Trace propagation', () => { | |||
const clientTx = await clientTxPromise; | |||
|
|||
expect(clientTx.contexts?.trace?.trace_id).toEqual(serverTx.contexts?.trace?.trace_id); | |||
expect(clientTx.contexts?.trace?.parent_span_id).toBe(serverTx.contexts?.trace?.span_id); | |||
|
|||
const requestHandlerSpan = serverTx.spans?.find(span => span.op === 'request_handler.express'); |
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.
no action required: looks like the parent span changed here. Any idea why? Is this a consequence of updated instrumenations?
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.
Yea, this came through the update in instrumentation. We no longer use our express v5 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.
🥇
"@opentelemetry/instrumentation-nestjs-core": "0.44.1", | ||
"@opentelemetry/core": "^2.0.0", | ||
"@opentelemetry/instrumentation": "^0.202.0", | ||
"@opentelemetry/instrumentation-nestjs-core": "0.48.1", |
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 can then switch this one in a separate PR (replacing our vendored 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.
We have to switch anyway to match deps, it shouldn't affect our vendored instrumentation tho.
4f9eeed
to
2105d24
Compare
This PR
0.202.0
for experimental and latest versions for all instrumentations).@sentry/opentelemetry
OpenTelemetry v2 test dev-package as this is now covered by the package itselfNote: Once this PR is merged, the
develop
branch officially becomes thev10
branch and any releases for v9 have to happen on thev9
branch.