Propose a Change to the Browser Trace Model #20
Conversation
| In the most trivial case the recommendation to customers would be to pick one project that | ||
| starts traces for real user sessions. This could be *either* frontend of backend but it | ||
| should attempt to be consistent about it. In either case the client SDK should *continue the | ||
| trace* until the browser tab naturally closes. |
There was a problem hiding this comment.
The issue here is with traces that then can be multiple hours long - and so then the value of analyzing a trace is completely lost.
I'm strongly against this because I feel like it'll reduce the value of trace view, and make it harder for us to expand the tracing product.
There was a problem hiding this comment.
That sounds a bit like a UX issue? I don't think that it's inherently problematic if a trace is very long, we today already do not draw much of a value out of the trace view.
To me it feels at least like there is more value to the trace being connected than the trace being split into transactions on every navigation.
There was a problem hiding this comment.
User inactivity in a browser tab could be another natural way of ending a session, and beginning a new one.
There could be users that leave tabs open for a very long time, and having large time gaps between transactions might seem weird.
|
|
||
| ## Alternative B: Trace to Trace Relationships | ||
|
|
||
| A potential alternative would be to continue the current project but allow a trace to annotate |
There was a problem hiding this comment.
As an aside, in my eyes there are various correlation ID mechanisms that we chat about, and it would be nice to get an RFC going that establishes them all. Off the top of my head:
- release id
- user id
- session id
- trace id
- profile id
- replay id (basically a session id)
The most important relationships are as follows:
- 1 users x R releases
- 1 user x S sessions/replays
- 1 user x T traces
- 1 session/replay x T traces
- 1 profile x 1 trace (though this is changing to 1 profile x T trace iirc)
If we can establish these concepts consistently it'll be a nice foundation for us to keep building off of
There was a problem hiding this comment.
big +1 here, i still feel like we are moving torwards treating a trace more like a session, and it will get more and more confusing with our existing sessions/releases and session replay (which is closes to what is the standard definition of a session)
The problem we are solving for to relate transactions across a user session by exanding the inclusion of more traces in a single trace for sampling, I feel will just create more fuzzy area. Confusion for us and our users.
Co-authored-by: Alberto Leal <[email protected]>
| This RFC proposes to require a frontend SDK to retain a trace that it continues | ||
| until the SDK naturally ends the user session. This change is primarily to the | ||
| browser trace model to better support dynamic sampling and to create a more | ||
| coherent user experience. |
There was a problem hiding this comment.
I believe this affects mobile as well since the concept is similar to the browser trace model, right?
There was a problem hiding this comment.
Yes it will also affect mobile - by making ui.load and resulting interaction and navigation transactions linked.
|
hi folks we had some discussions in the office and for transparency I want to share here. Goal: Answer 3 questions:
A graph for context. Here we see for comparison how a session covers the full scope of time of user's interaction with a website. With each row representing traces starting in a frontend and it's connected chain of services. Replay is there as a the new emerging product which has "sessions" but they are not synonymous with these user sessions. So our input is that Sentry does want a concept of a session as shown here, a trace should not be expanded in scope to be conflated with a session. Similar to other applications and products. We should continue to research how sessions are handled in other products. Define our definitions of each term, as stated in @AbhiPrasad 's comment above, and discuss how to facilitate such contextual data, considering but not limited to Dynamic Sampling. Example: Proposal: Supporting Real User Monitoring Events in OpenTelemetry
|
|
For Sentry internal employees - the point above by @smeubank was elaborated on by @benvinegar in https://vanguard.getsentry.net/p/cl9eb7qko33680ls604otdki9 |
|
@ale-cota with the changes to how dynamic tracing will work going forward on AM2 plans the the like, the direct control customers have on traces are greatly diminished. As a result I do not believe that the original issue here is particularly impactful. That said, I believe expressing which project originally started the trace in terms of sampling decision might still be important for when starting a trace again later on. I would propose closing this RFC and instead opening one about the particular issues related to expression sampling consistency for sessions rather than traces. Thoughts? |
|
@mitsuhiko yes, I agree to closing this one and opening a new one regarding user sessions instead. |
This RFC proposes a change to the browser (frontend) trace model so that user sessions are reusing the traces or at least continuing the sampling context. This issue relates to #14 and getsentry/sentry#39349 and the confusion it causes in the dynamic sampling configuration experience.
This RFC currently proposes to continuing the session but alternative options are possible. I will defer the decision for this RFC to @ale-cota since the main impact today is dynamic sampling.
Rendered RFC