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
When creating a new span with a single link to a followed span in the same trace, the UI renders the new span as if the followed span were actually the parent span, and renders a link icon for the true parent of the new span. In other words, the UI seems to flip the meaning of CHILD_OF and FOLLOWS_FROM when rendering, even though the references are correctly expressed in the trace.
Steps to reproduce
Create a new trace with two immediate child spans logically referred to as followed and parent
Create a third span as a child of parent and specify one link to the followed span
View the trace and note that the third span is rendered as a child of followed with a link to parent instead of the other way round.
Expected behavior
I expected child spans to be rendered beneath their parent, not beneath a linked span.
Relevant log output
No response
Screenshot
Additional context
Hopefully the annotated screen shot depicts the issue clearly.
The red-circled span shows a parent spanID ending in dc34 and a follows-from spanId ending in de6f. Yet the red-circled span named remote_client::send_response is rendered as if the parent is the follows-from span of de6f.
// export OTEL_EXPORTER_OTLP_ENDPOINT=http://172.17.0.3:4317// where IP is that of jaeger container for docker inspect network bridgelet _tracer = opentelemetry_otlp::new_pipeline().tracing().with_exporter(opentelemetry_otlp::new_exporter().tonic()).with_trace_config(config().with_resource(Resource::new(service_attributes(service_name)))).install_batch(opentelemetry_sdk::runtime::TokioCurrentThread)?;
Stogage backend
Jaeger all-in-one
Operating system
Linux
Deployment model
Docker
Deployment configs
No response
The text was updated successfully, but these errors were encountered:
@yurishkuro, I would consider making a PR with a fix if I could get a rough pointer into the code base where the adjustments are most likely to be needed. (I'm just completely unfamiliar with this codebase.)
Unfortunately, I am not that intimately familiar with the UI code either. My typical approach is to look at some UI labels in the screen of interest, find them in the code, and walk upwards. In theory, there can be several solutions to this problem:
UI might make random decision about a proper parent
UI might always assume the first reference as the parent, but then introduce a re-ordering somewhere else in the code
UI might 100% respect the ordering, but not alter it itself, instead relying on the server (which I think already ensures child-of refs come first)
What happened?
When creating a new span with a single link to a
followed
span in the same trace, the UI renders the new span as if thefollowed
span were actually theparent
span, and renders a link icon for the trueparent
of the new span. In other words, the UI seems to flip the meaning ofCHILD_OF
andFOLLOWS_FROM
when rendering, even though the references are correctly expressed in the trace.Steps to reproduce
followed
andparent
parent
and specify one link to thefollowed
spanfollowed
with a link toparent
instead of the other way round.Expected behavior
I expected child spans to be rendered beneath their parent, not beneath a linked span.
Relevant log output
No response
Screenshot
Additional context
Hopefully the annotated screen shot depicts the issue clearly.
The red-circled span shows a parent spanID ending in
dc34
and a follows-from spanId ending inde6f
. Yet the red-circled span namedremote_client::send_response
is rendered as if the parent is the follows-from span ofde6f
.Jaeger backend version
v1.49.0
SDK
https://crates.io/crates/opentelemetry_sdk
OTEL Rust SDK -> [OTLP] -> Jaeger-all-in-one
Pipeline
OTEL Rust SDK -> OTLP -> Jaeger-all-in-one
Stogage backend
Jaeger all-in-one
Operating system
Linux
Deployment model
Docker
Deployment configs
No response
The text was updated successfully, but these errors were encountered: