4 ms·

I hate that this specification and most of the other ones use spans that have a beginning and end rather than events that start and end the span. What if it cra

I hate that this specification and most of the other ones use spans that have a beginning and end rather than events that start and end the span. What if it crashes before it sends out the span? What if it is taking a very long time to complete?

rad_gruchalski 5y ago
You can emit multiple spans yourself, no?
novok 5y ago
Data query wise it's significantly more complicated to compile 2 db row spans than it is to do queries on one db row spans. The library that makes and manages those spans before uploading can deal with those use cases internally if it wants, a lot of these systems have support for single point events too.
beeandapenguin 5y ago
For the long running scenario, why not use Links? The specification describes[1] a similar scenario and how links can be leveraged to causally relate spans even across trace boundaries. As for the crashing scenario, this seems like an application-level concern. Ideally it is not waiting until the crash to send traces. Depending on the environment, the application could handle the crash and deliver the telemetry leading up to it before shutting down. [1]: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/overview.md#links-between-spans https://github.com/open-telemetry/opentelemetry-specificatio...
- jeffbee 5y ago
  Yes, logging the beginning and ending of a span to your observability platform is a common and valuable approach, since you can figure out from the open spans of a dead process what requests might have been running when it died, making it easier to diagnose requests of death.
dyladan 5y ago
The span is simply the way the data is modeled. The way the tracing works is it calls a component called a Span Processor on both span start and end. It would be possible to implement a Span Processor that sends span_start and span_end events to your backend without waiting for the span to start. In terms of crashing and taking a long time to complete, these are problems that are very difficult to solve on the backend as well. Simply having the start event without the end event is not enough info to say for sure that there will _never_ be an end event. For low data volumes and simple use-cases this may not seem like a big deal, but it gets complex extremely quickly.
unportant 5y ago
I think you are right and data model should have been event based rather than span based. https://medium.com/opentracing/open-for-event-based-tracing-a326c295f2a2 https://medium.com/opentracing/open-for-event-based-tracing-... digs into that topic and basically says that distributed tracing is about causality & partial ordering which bring us back to the 70's with Lamport's logical clocks and all following work. However, this design "flaw" is well known and seems assumed. I'm not able to find relevant GitHub issues right now, but I remember this topic being discussed on OpenTracing or OpenTelemetry bug tracker and the outcome was something like "Spans might not be the best data model, but people are now used to it and we have to ship the spec within a reasonable time, so let's stick to it". Edit: https://github.com/open-telemetry/opentelemetry-specification/issues/20 https://github.com/open-telemetry/opentelemetry-specificatio... might be relevant to your concerns.

rad_gruchalski 5y ago

You can emit multiple spans yourself, no?

novok 5y ago

Data query wise it's significantly more complicated to compile 2 db row spans than it is to do queries on one db row spans. The library that makes and manages those spans before uploading can deal with those use cases internally if it wants, a lot of these systems have support for single point events too.

beeandapenguin 5y ago

For the long running scenario, why not use Links? The specification describes[1] a similar scenario and how links can be leveraged to causally relate spans even across trace boundaries. As for the crashing scenario, this seems like an application-level concern. Ideally it is not waiting until the crash to send traces. Depending on the environment, the application could handle the crash and deliver the telemetry leading up to it before shutting down. [1]: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/overview.md#links-between-spans https://github.com/open-telemetry/opentelemetry-specificatio...

jeffbee 5y ago
Yes, logging the beginning and ending of a span to your observability platform is a common and valuable approach, since you can figure out from the open spans of a dead process what requests might have been running when it died, making it easier to diagnose requests of death.

dyladan 5y ago

The span is simply the way the data is modeled. The way the tracing works is it calls a component called a Span Processor on both span start and end. It would be possible to implement a Span Processor that sends span_start and span_end events to your backend without waiting for the span to start. In terms of crashing and taking a long time to complete, these are problems that are very difficult to solve on the backend as well. Simply having the start event without the end event is not enough info to say for sure that there will _never_ be an end event. For low data volumes and simple use-cases this may not seem like a big deal, but it gets complex extremely quickly.

unportant 5y ago

I think you are right and data model should have been event based rather than span based. https://medium.com/opentracing/open-for-event-based-tracing-a326c295f2a2 https://medium.com/opentracing/open-for-event-based-tracing-... digs into that topic and basically says that distributed tracing is about causality & partial ordering which bring us back to the 70's with Lamport's logical clocks and all following work. However, this design "flaw" is well known and seems assumed. I'm not able to find relevant GitHub issues right now, but I remember this topic being discussed on OpenTracing or OpenTelemetry bug tracker and the outcome was something like "Spans might not be the best data model, but people are now used to it and we have to ship the spec within a reasonable time, so let's stick to it". Edit: https://github.com/open-telemetry/opentelemetry-specification/issues/20 https://github.com/open-telemetry/opentelemetry-specificatio... might be relevant to your concerns.