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
I have a parent-child relationship between spans (e.g., processing batches of requests). I'd like to be able to use that data when consuming the Cloud Trace API (e.g., seeing parent-child relationship in Cloud Trace explorer).
Having a way to both use OTEL and the span link type would make using links a lot more powerful.
One approach would be to have a magic attribute in Link.Attributes that holds the type and is popped from Attributes and added to the link in linksProtoFromLinks(). Psuedo-code:
@mattayes Can you share a screenshot, or something that shows how the UX is degraded with an unknown span link type?
I'm not against having a special attribute for span link type. Obviously it would be better to have it supported upstream, but that is a lot more work.
@mattayes are you using the in-process span exporter, or the collector exporter?
@dashpole I assumed that, if the parent-child relationship is known, the Trace Explorer UI could display the whole chain. For example, if we're using a fan-in approach, we'll see N parent traces fanning into a single child trace in the UI (e.g., part of the timing visualization). Alternatively, if I started from one of the parent traces, I'd be able to see the whole flow—including through the child trace—in the UI.
That appears to not be the case today: it looks like it'll always only show up in the Metadata & Links section. AFAICT there's no way to see the entire trace, including through links: at every link we need to navigate to the next trace. That's what I meant by "worse UX": if we could see everything at once the links would be a lot more useful.
@mattayes thanks. I don't think the link type impacts whether or not the link is followed in the UI. I'll share your feedback with the UI team.
Given the only impact is adding the field in the metadata & links section, i'm inclined to say we should wait for upstream to add this before changing our exporters. It seems like a custom attribute is about as useful as setting the link type.
Problem
I have a parent-child relationship between spans (e.g., processing batches of requests). I'd like to be able to use that data when consuming the Cloud Trace API (e.g., seeing parent-child relationship in Cloud Trace explorer).
While the Cloud Trace API natively supports this via the span link type, OTEL does not, so all links relationships are unspecified, leading to a worse UX.
Solutions
Having a way to both use OTEL and the span link type would make using links a lot more powerful.
One approach would be to have a magic attribute in
Link.Attributes
that holds the type and is popped fromAttributes
and added to the link in linksProtoFromLinks(). Psuedo-code:Another approach would be to work with OTEL and have the spec support relationships directly.
The text was updated successfully, but these errors were encountered: