rfc(feature): Support Linking Traces #141
Conversation
|
Great stuff! One thing I was wondering about is how links are affected by span filtering. What if links are actively dropped by users? Is that a concern? |
I would argue that this is up to users. If users decide to drop a span link, we just won't be able to link the respective spans together. Meaning, unless there's a strong case for consistent sampling across traces (which is still TBD) I think we can permit mutation of links just like any other span property. |
|
Sorry, looks like "starting a review" with both new comments and replies got weird and duplicated a bunch of stuff in the timeline above. Sorry 😬 |
Co-authored-by: Andrei <168741329+andreiborza@users.noreply.github.com>
Co-authored-by: Sigrid Huemer <32902192+s1gr1d@users.noreply.github.com>
Co-authored-by: Mike Ihbe <mikejihbe@gmail.com>
Lms24
force-pushed
the
lms/linking-traces
branch
from
47f34d9 to
9012b51
Compare
Lms24
changed the title
Lms24
requested review from
s1gr1d,
andreiborza,
chargome,
mydea,
philipphofmann,
mjq,
jan-auer,
jjbayer and
a team
There was a problem hiding this comment.
LTGM 
While this doesn't solve all of our long-lived trace problems, and I would love to see traces linked to sessions, this is a significant step in the right direction. This concept will solve multiple issues you thoroughly described in the RFC. It's also excellent that OTel already has this concept
Thanks for the detailed write-up. I'm looking forward to implementing this.
| It's worth noting that we will not link to the previous positively sampled trace if a negatively sampled trace is in-between (see Traces 2-4 in the diagram). Furthermore, we will not show _how many_ traces were negatively sampled in between two trace chains; only that there was at least one trace in between (see Trace 5-8). | ||
|
|
||
| There are some ideas how we could show multiple negatively sampled spans as well as how we could connect traces with gaps due to sampling. For now, we'll disregard this because there's no concrete use case, yet. However, given spans can have multiple links and links can have attributes, we could add this information later on, if we deem it necessary. |
There was a problem hiding this comment.
Most customers don't sample at 100%. They will frequently experience previously negatively sampled traces. I can imagine that some customers would like to navigate to the last positively sampled trace when most of their previous traces are negatively sampled. But it might be OK to wait for customers to ask for that feature. The current proposal would allow multiple options to achieve this without changing the APIs and the protocol.
There was a problem hiding this comment.
Yup. I sketched out a solution a while ago how we could add multiple links to indicate missing traces due to sampling:
I didn't include this in the RFC because as I wrote, it's something we can tackle if there's demand for it.
This RFC specifies our plans to support linked traces via span links.
Since this became quite a lot of text, I recommend especially reading the Preferred Option section which specifies SDK, Relay and Storage changes. The other sections are supposed to provide context and additional information.
Rendered Document
ref: https://github.com/getsentry/projects/issues/268