You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the time of Sentry's initial performance product development, OpenTelemetry was in the nascent stages of its lifecycle and was not yet optimized for our requirements. Nevertheless, we maintained similarities in our data models and paradigms with OpenTelemetry. Since then, OpenTelemetry has significantly matured, passed the test of time, and has been generally available (GA) for over a year. It now boasts an extensive ecosystem of integrations spanning multiple technologies, including databases, queues, and protocols.
This maturity means that now is the time for us to rework our Node Performance Monitoring to use Otel under the hood. This way, we can leverage all the functionality from the Otel ecosystem, and overall better align with the broader ecosystem.
Key goals of this project
Leverage OpenTelemetry instrumentation for Performance
Ensure a consistent user experience - it should not feel much different to users than the current SDK experience
Do not loose functionality - in places where our instrumentation may exceed what Otel currently offers, we want to either keep some of our own instrumentation, and/or in the medium term upstream improvements to the Otel instrumentations
TLDR: Users continue to use Sentry.init() and everything just works™️.
Process
The idea is to create a proof of concept MVP first, which shows how you could use Sentry.init() and get error monitoring + performance monitoring powered by Otel with minimal user configuration.
After this proof of concept, we will work on getting to feature parity with the existing node integrations.
Finally, we may fold this back into the existing @sentry/node package and make this the regular experience. This will have to be shipped in a new major, as Node support will have to change (Otel has much stricter node support than we do - v14+ as of now). We'll need to make sure this is transparent to our users.
Afterwards, we may add further integrations/instrumentations based on what Otel instrumentations are available.
Non-Goals
For the initial work, we want to strive to optimize for easy setup & usage. Exposing Otel internals & providing more hooks etc. for users to manually add Otel stuff may come at a later point.
The content you are editing has changed. Please copy your edits and refresh the page.
Once the MVP is somewhat feature complete, we need to consider how to release. If possible, we should consider releasing this as a major release of @sentry/node (in v8). If this will be possible will depend on the fact if we run into any unexpected roadblocks/problems while migrating. In the (hopeful) case that all can be migrated more or less easily with as little breaking changes as possible (best case: Only node support policy has to change), releasing this as @sentry/node would be the best outcome. If this is not possible, for some reason or another, we may consider releasing this as a separate package.
At the time of Sentry's initial performance product development, OpenTelemetry was in the nascent stages of its lifecycle and was not yet optimized for our requirements. Nevertheless, we maintained similarities in our data models and paradigms with OpenTelemetry. Since then, OpenTelemetry has significantly matured, passed the test of time, and has been generally available (GA) for over a year. It now boasts an extensive ecosystem of integrations spanning multiple technologies, including databases, queues, and protocols.
This maturity means that now is the time for us to rework our Node Performance Monitoring to use Otel under the hood. This way, we can leverage all the functionality from the Otel ecosystem, and overall better align with the broader ecosystem.
Key goals of this project
Sentry.init()
and everything just works™️.Process
The idea is to create a proof of concept MVP first, which shows how you could use
Sentry.init()
and get error monitoring + performance monitoring powered by Otel with minimal user configuration.After this proof of concept, we will work on getting to feature parity with the existing node integrations.
Finally, we may fold this back into the existing
@sentry/node
package and make this the regular experience. This will have to be shipped in a new major, as Node support will have to change (Otel has much stricter node support than we do - v14+ as of now). We'll need to make sure this is transparent to our users.Afterwards, we may add further integrations/instrumentations based on what Otel instrumentations are available.
Non-Goals
For the initial work, we want to strive to optimize for easy setup & usage. Exposing Otel internals & providing more hooks etc. for users to manually add Otel stuff may come at a later point.
MVP
Port existing integrations
Releasing
Once the MVP is somewhat feature complete, we need to consider how to release. If possible, we should consider releasing this as a major release of
@sentry/node
(in v8). If this will be possible will depend on the fact if we run into any unexpected roadblocks/problems while migrating. In the (hopeful) case that all can be migrated more or less easily with as little breaking changes as possible (best case: Only node support policy has to change), releasing this as@sentry/node
would be the best outcome. If this is not possible, for some reason or another, we may consider releasing this as a separate package.Further steps
Eventually, we may also add some other integrations based on instrumentation that exists for Otel (see: https://github.com/open-telemetry/opentelemetry-js-contrib/tree/main/plugins/node). Note: The goal is to still provide a curated experience.
Stretch goal: Add new integrations
ref getsentry/team-sdks#4
The text was updated successfully, but these errors were encountered: