-
Notifications
You must be signed in to change notification settings - Fork 104
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
exporter/trace: Support span link type #791
Comments
@dashpole do you think this is the way we'd want to implement this, vs trying to get this upstreamed? |
@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 @dashpole We're using exporter/trace, which I believe is the in-process span exporter. |
@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: