clarifies parent and links #283
Conversation
SergeyKanzhelev
requested review from
AloisReitbauer,
bogdandrutu,
c24t,
carlosalberto,
iredelmeier,
reyang,
songy23,
tedsuo,
tigrannajaryan and
yurishkuro
as code owners
|
tracing page should be updated as well. It has A span could have zero or one or more than one parents. Single parent is represented using parent and multiple parents are represented using Links. |
|
@rghetia removed the word parent from this sentence. SHould work better now |
| Trace instead of trusting incoming Trace context. | ||
| **Links** can be used to represent batched operations where a **Span** was | ||
| initiated by multiple initiating **Span**s, each representing a single incoming | ||
| item being processed in the batch. Another example of using a **Link** is to |
| item being processed in the batch. Another example of using a **Link** is to | ||
| declare relationship between originating and followed trace. This can be used | ||
| when **Trace** enters trusted boundaries of a service and service policy | ||
| requires to generate a new Trace instead of trusting incoming Trace context. Or |
There was a problem hiding this comment.
...requires the generation of a new Trace rather than trusting the incoming Trace context...?
There was a problem hiding this comment.
thanks! fixed. See #289
| declare relationship between originating and followed trace. This can be used | ||
| when **Trace** enters trusted boundaries of a service and service policy | ||
| requires to generate a new Trace instead of trusting incoming Trace context. Or | ||
| when long running Trace representing asynchronous data processing operation was |
There was a problem hiding this comment.
rephrased. See #289
| when **Trace** enters trusted boundaries of a service and service policy | ||
| requires to generate a new Trace instead of trusting incoming Trace context. Or | ||
| when long running Trace representing asynchronous data processing operation was | ||
| initiated by one of many fast incoming request. |
There was a problem hiding this comment.
This sentence doesn't make semantic sense IMO
There was a problem hiding this comment.
rephrased. See #289
| when long running Trace representing asynchronous data processing operation was | ||
| initiated by one of many fast incoming request. | ||
|
|
||
| In case of scatter/gather pattern, when the root operation starts multiple |
There was a problem hiding this comment.
In the case of usage of the scatter/gather
or
When using the scatter/gather (also called fork/join) pattern, ....
| **Links** can be used to represent batched operations where a **Span** was | ||
| initiated by multiple initiating **Span**s, each representing a single incoming | ||
| item being processed in the batch. Another example of using a **Link** is to | ||
| declare relationship between originating and followed trace. This can be used |
There was a problem hiding this comment.
Could we use Links for asynchronous operations extending past the topmost parent span as well? What are the recommendtations on tracing evented systems?
There was a problem hiding this comment.
Could we use Links for asynchronous operations extending past the topmost parent span as well?
You could. There is no limitations in specs as of
What are the recommendtations on tracing evented systems?
We don't have recommendations written. Do you want to start on this? I'd personally prioritize it for after v0.3
There was a problem hiding this comment.
we still have an issue to agree on link types. Where this can come up. But I think full blown event based systems support will likely be in scope later
There was a problem hiding this comment.
I wouldn't mind coming with input as to how to solve it;
- initially, "FollowsFrom" like in opentracing would probably be just fine. This is classically called "correlation id"; and could be the TraceId or SpanId the async span follows from
- if you were to make a recommendation on when relations are considered completely mapped, perhaps event-time like in the steaming systems would be a good frame of reference. However; In most servers/collectors I suppose late relationships would be linked in a best-effort manner as they become known
In all likelyhood someone else has solved this problem for written extensively about it though ;)
Link: #65
There was a problem hiding this comment.
...and if I were to throw stuff at a wall to see what sticks, then perhaps dotted version vector sets can be adapted to use the span id as the "server id" (after all, Spans are not long running generally), creating a partial order of happened-before, happened-after and happened-concurrently between spans and allowing visualisation thereof.
There was a problem hiding this comment.
@haf I think the best way to throw things at a wall is to create an issue =)
* clarifies parent and links * Update specification/overview.md
* clarifies parent and links * Update specification/overview.md
Fixes #207