Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

clarifies parent and links #283

Merged
merged 3 commits into from
Oct 5, 2019
Merged

clarifies parent and links #283

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
121bb38
clarifies parent and links
Oct 3, 2019
279a26d
Update specification/overview.md
SergeyKanzhelev Oct 3, 2019
383a990
Merge branch 'master' into linksFromTheSameTrace
bogdandrutu Oct 5, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 17 additions & 6 deletions specification/overview.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -95,12 +95,23 @@ propagated from parent to child **Spans**.
A **Span** may be linked to zero or more other **Spans** (defined by
**SpanContext**) that are causally related. **Links** can point to
**SpanContexts** inside a single **Trace** or across different **Traces**.
**Links** can be used to represent batched operations where a **Span** has
multiple parents, each representing a single incoming item being processed in
the batch. Another example of using a **Link** is to declare relationship
between originating and restarted trace. This can be used when **Trace** enters
trusted boundaries of an service and service policy requires to generate a new
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
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Newline before new sentence?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed. See #289

declare relationship between originating and followed trace. This can be used
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we use Links for asynchronous operations extending past the topmost parent span as well? What are the recommendtations on tracing evented systems?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link

@haf haf Oct 7, 2019 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link

@haf haf Oct 7, 2019 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

...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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@haf I think the best way to throw things at a wall is to create an issue =)

when **Trace** enters trusted boundaries of a service and service policy
requires to generate a new Trace instead of trusting incoming Trace context. Or
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

...requires the generation of a new Trace rather than trusting the incoming Trace context...?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks! fixed. See #289

when long running Trace representing asynchronous data processing operation was
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't start sentences with "or"

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

rephrased. See #289

initiated by one of many fast incoming request.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This sentence doesn't make semantic sense IMO

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

rephrased. See #289


In case of scatter/gather pattern, when the root operation starts multiple
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the case of usage of the scatter/gather

or

When using the scatter/gather (also called fork/join) pattern, ....

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks!

downstream processing operations and all of them being aggregated back in a
single **Span**, this last **Span** is linked to many operations it
aggregates. All of them are the **Span**s from the same Trace. And similar to
the Parent field of a **Span**. It is recommended, however, to not set parent of
the **Span** in this scenario as semantically parent field represents a single
parent scenario, in many cases parent **Span** fully encloses the child
**Span**. Which is not the case in scatter/gather and batch scenarios.

## Metrics

Expand Down
3 changes: 2 additions & 1 deletion specification/sdk-tracing.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -46,7 +46,8 @@ Returns the sampling Decision for a `Span` to be created.
- `SpanId` of the `Span` to be created.
- Name of the `Span` to be created.
- Collection of links that will be associated with the `Span` to be created.
Typically useful for batch operations.
Typically useful for batch operations, see [Links Between
Spans](overview.md#links-between-spans).

**Return value:**

Expand Down