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
The current specification focuses on only one use-case. This is a synchronous service call with a clear beginning and an end, which are known upfront. Moreover, the logic to produce a consistent trace is left entirely to the emitter of the telemetry. Backends are not required to be able to construct traces from bits and pieces.
For event-driven architectures this cannot work because:
There is no logical end to an event trace. The last event that occurred is the end, but you cannot know that when it occurs.
The beginning of an event trace is uncertain. It is the first occurrence of event with a certain trace ID. That can come from anywhere. In all those places a root span could be generated but without an end time.
An event has no duration. It just marks a moment. With post-processing, the time between an event and some reaction to it may be measured, but there isn't always a reaction.
Often events already carry something like a correlation ID, which are propagated. It should therefore be possible to set trace IDs that are derived from such information instead of having only generated IDs.
To fix this, it should be possible to generate traces that are a collection of root spans, all with the same trace ID and no end time. From that, a backend can produce a consistent trace when it is requested or update it if it is stored.
The text was updated successfully, but these errors were encountered:
The current specification focuses on only one use-case. This is a synchronous service call with a clear beginning and an end, which are known upfront. Moreover, the logic to produce a consistent trace is left entirely to the emitter of the telemetry. Backends are not required to be able to construct traces from bits and pieces.
For event-driven architectures this cannot work because:
To fix this, it should be possible to generate traces that are a collection of root spans, all with the same trace ID and no end time. From that, a backend can produce a consistent trace when it is requested or update it if it is stored.
The text was updated successfully, but these errors were encountered: