[APM] Timeline: Show spans without transaction

[formgeist]

Following a discussion in apm-server about to handle spans that have no transaction, we need to figure out a solution in the UI to keep displaying them but with a note or indication that they're without a transaction.

[elasticmachine]

Pinging @elastic/apm-ui

[formgeist]

I've made a design proposal on how to indicate a span with no transaction. I suppose it's not a common case which means we might just want to flag it with a tooltip explaining that this span is without a parent transaction.

cc @elastic/apm-ui

[formgeist]

@simitt @felixbarny Thoughts on implementing this into the design of the Timeline?

[felixbarny]

If you don't know the parent of a span, I think it's impossible to even show that span.

The transactions/spans are rendered as a tree-structure. When expanding a node, it's direct children are loaded. But if the parent transaction of a span is missing, the spans are not reachable via the tree structure and thus can never be rendered.

So we could only add a trace-level warning, similar to #22348. This warning would trigger if we have more spans than expected. The problem is that we could also have more spans than expected when a span is started after it's transaction has ended, which is totally valid.

[formgeist]

I think it's just my copy that's confusing 😕If we intend to inject spans that don't have a transaction into the trace timeline, what should we write? "Span without transaction"?

[felixbarny]

We would have no Idea where to put the spans inside the tree, so I don't think we can just "inject" them.

[formgeist]

OK, I see your point about where to inject them in the three - other than in the very start after the root trace, or at the very end, right?

[felixbarny]

Yes, so I think it would be rather misleading than helpful to put them there. Also, when we only load child spans on demand, we can never navigate to those.

I would avoid an implementation which loads all the spans of a trace at once. This has already lead to problems in other tracing systems, like zipkin.

[felixbarny]

See also openzipkin/openzipkin.github.io#80

[formgeist]

Perhaps this needs to have a wider consensus, but do we agree that the spans without transactions are not useful in the Timeline visualization, and we're not going to do anything special to notify the user that there are more spans available than what's loaded in the visualization? To me it doesn't sound viable to always notify the user when there's more spans than in the total_span_count. Thoughts @simitt @felixbarny?

[formgeist]

Ping @simitt @felixbarny 🙂

[felixbarny]

but do we agree that the spans without transactions are not useful in the Timeline visualization

At least I agree 😄

To me it doesn't sound viable to always notify the user when there's more spans than in the total_span_count

I also agree because the reason for that does not have to be an error condition. It could also be because a span was started after its transaction has ended.

[formgeist]

@roncohen @simitt Do you agree to not show spans without transactions in the Trace timeline, since we don't where to place them in the flow and not to warn the user at the top of the trace if there's more spans than total_span_count.

[simitt]

I agree that we cannot show them. I don't agree though that this would be a viable use case, as we require a span to have a parent_id and a transaction_id set. This indicates that not finding the transaction a span is linking to, is not a viable use case, but should only happen if the transaction isn't stored to ES (for whichever reasons).
@felixbarny if a span is started after a transaction, wouldn't the transaction_id still be set for the span? If not we have to reopen the discussions around required fields for spans again.

[felixbarny]

if a span is started after a transaction, wouldn't the transaction_id still be set for the span?

It does

[...] not finding the transaction [...] should only happen if the transaction isn't stored to ES (for whichever reasons).

correct

so we just can't display these kinds of spans in any meaningful way

[formgeist]

OK, closing this issue, and we'll start with #22348 instead