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
Distributed Tracing built-in to Sentry landed with the addition of Sentry for Performance Monitoring, the SDKs started creating a sentry-trace header for out going HTTP requests. Backend SDKs became aware of those and further propagated the trace information, as well as adding it to any outgoing events: errors or transactions.
For the most part a trace-id is created when a transaction (event used for performance monitoring) is created. And while the transaction exists (and bound to the scope), that trace-id is propagated through HTTP integrations.
With other products landing such as Session Replay, the need to connect a Replay throughout the whole call chain became more prominent. We can do that today if we rely on sentry-trace being propagated but that requires performance monitoring being enabled. That was a constraint to the initial deliverable of having Replay show up on backend errors:
This issue aims to decouple trace propagation and transactions or the performance product. So errors, replays, etc can be linked together across from the frontend to backend services.
The content you are editing has changed. Please copy your edits and refresh the page.
I will follow up with this in TSC, essentially i think the best as is. Will be define this is a non-breaking change and expected behavior to get traces and turn off perofrmance tracesSampleRate: 0.0
for OTel, the OTel SDK really runs the show for propagation, should work as is, I also don't imagine many OTel users would want to have an errors and replay only product experience
This issue has gone three weeks without activity. In another week, I will close it.
But! If you comment or otherwise update it, I will reset the clock, and if you label it Status: Backlog or Status: In Progress, I will leave it alone ... forever!
"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀
Distributed Tracing built-in to Sentry landed with the addition of Sentry for Performance Monitoring, the SDKs started creating a
sentry-trace
header for out going HTTP requests. Backend SDKs became aware of those and further propagated the trace information, as well as adding it to any outgoing events: errors or transactions.For the most part a
trace-id
is created when a transaction (event used for performance monitoring) is created. And while the transaction exists (and bound to the scope), thattrace-id
is propagated through HTTP integrations.With other products landing such as Session Replay, the need to connect a Replay throughout the whole call chain became more prominent. We can do that today if we rely on
sentry-trace
being propagated but that requires performance monitoring being enabled. That was a constraint to the initial deliverable of having Replay show up on backend errors:This issue aims to decouple trace propagation and transactions or the performance product. So errors, replays, etc can be linked together across from the frontend to backend services.
Initial action points
The text was updated successfully, but these errors were encountered: