Composite Spans and transaction_max_spans

[tobiasstadler]

If a span is dropped due to transaction_max_spans, can it still be incorporated into a composite span?

[felixbarny]

Seems like another thing we haven't clearly specified thus far.

I would say that no, if a span is dropped due to transaction_max_spans, it can't be incorporated into a composite span.

The reason is the limited utility and the increased complexity this would introduce.

Let's look at the utility. It seems to me that this would only be useful for a very limited set of edge-cases. Like when you're very close to the limit (such as 499/500 spans) and another batch of repetitive spans is about to start. Let's say there are 10 SELECT FROM owners calls. The first one can be collected, bringing the total spans to the max of 500. In this case, it's unfortunate that we can't add the other 9 identical calls to the composite span. However, if we're not that close to the limit (such as 498/500 spans), we could collect all of them. That's because when compressing a span, we also decrement the span count. So if someone is worried that they might only get 499 instead of 500 spans, they can just set transaction_max_spans to 501.

As for the complexity, it's not something that's impossible or too complex to solve. But it would assume that all agents create span objects even for spans that are above transaction_max_spans. This is currently true for Java but not all other agents. And relying on that for Java would reduce the flexibility we have going forward. We could internally also just have a limit of transaction_max_spans + 1 and check at the end of the span whether we can compress it and discard it otherwise. But that also introduces more complexity.

Overall I don't think the utility outweighs the complexity.

[tobiasstadler]

I am fine with that.

That spec says "To still retain some information about dropped spans (for example due to transaction_max_spans or exit_span_min_duration), agents SHOULD collect statistics on the corresponding transaction about dropped spans", so shouldn‘t the agents already "track" dropped spans (e.g. to get their duration)?

[tobiasstadler]

Since the Java agent always creates spans, even if transaction_max_spans is exceeded, do you think it is ok for it to compress dropped spans?

[felixbarny]

agents SHOULD collect statistics on the corresponding transaction about dropped spans", so shouldn‘t the agents already "track" dropped spans (e.g. to get their duration)?

Good point, you're right.

Since the Java agent always creates spans, even if transaction_max_spans is exceeded, do you think it is ok for it to compress dropped spans?

Yes, I think that's ok if it doesn't make the implementation significantly more complex.