Comment by candiddevmike

A span is a discrete event emitted on completion. It contains arbitrary metadata (plus a few mandatory fields if you're following the OTEL spec).

As such, it doesn't really have a beginning or end except that it has fields for duration and timestamps.

I'd check out the OTEL docs since I think seeing the examples as JSON helps clarify things. It looks like they have events attached to spans which is optional. https://opentelemetry.io/docs/concepts/signals/traces/

It’s been a minute since I worked on this but IIRC no, which means that if the request times out you have to be careful to end the span, and also all of the dependent calls show up at the collector in reverse chronological order.

The thing is that at scale you’d never be able to guarantee that the start of the span showed up at a collector in chronological order anyway, especially due to the queuing intervals being distinct per collection sidecar. But what you could do with two events is discover spans with no orderly ending to them. You could easily truncate traces that go over the span limit instead of just dropping them on the floor (fuck you for this, OTEL, this is the biggest bullshit in the entire spec). And you could reduce the number of traceids in your parsing buffer that have no metadata associated with them, both in aggregate and number of messages in the limbo state per thousand events processed.