-
Notifications
You must be signed in to change notification settings - Fork 0
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
Project: Performance powered by OTel [POTEL] #4
Comments
stephanie-anderson
changed the title
Project: Powered by OpenTelemetry
Project: Performance powered by OTel
Jul 7, 2023
6 tasks
smeubank
changed the title
Project: Performance powered by OTel
Project: Performance powered by OTel [POTEL]
Apr 29, 2024
54 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Project Board
See our project board to track this initiative across all SDKs
Web Frontend SDKs
Web Backend SDKs
Mobile SDKs
Description
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 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.
Personas
i. Only using Sentry SDK, OTel under the hood and not that interested
ii. Top Priority this is define the vast majority of our users today, at least those who get value from our Performance products
i. Use OTel SDK/APIs directly for instrumentation
ii. Span Processor 2.0
iii. 2nd Priority
i. they are very likely unaware of OTel, at least it is plausible
ii. not a very common use case but ideally we could consume those spans as well
iii. lowest prio
👩💻 User Stories
🎯 Goals of This Project
🚫 Non-Goals of This Project
Clarifications
Notion Documents
PR/FAQ Document
https://www.notion.so/sentry/PR-FAQ-Sentry-Tracing-Standardizes-on-OpenTelemetry-for-Tracing-3e381b48f219403c9fd7ff69f6ea4af6
Discuss
#proj-performance-powered-by-otel
OTel Instrumentations
Node.js
Python
FAQ
Why do we want users not longer have to think about transactions/hubs/scopes?
Because they are an implementation detail of Sentry's SDK. Transactions on one had are a bit more front and center but for a user to achieve a simple measurement (Span) we shouldn't require them to understand all these concepts. We internally need to abstract away this complexity and let the user measure what they want simple as e.g.:
startSpan
/finishSpan
and/ortrace
callback function.Why OTEL - or - How we want to use OTEL?
Today the OTEL setup is unnecessarily complex and it feels like either you have to use Sentry or use OTEL - The end result has to be that there is only one way and to achieve the highest possible instrumentation we have to use OTEL underneath to cover all integrations possible.
How do we make sure that the user always gets a measurement?
At any point in time - we want to ensure whenever the user measures something - it ends up in Sentry. Specific example even if today there is no ongoing transaction we create one under the hood and send it to Sentry.
The text was updated successfully, but these errors were encountered: