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.

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

Clarify the interpretation of SpanKind #337

Merged
merged 6 commits into from
Nov 4, 2019
Merged
Changes from 5 commits
Commits
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
66 changes: 48 additions & 18 deletions specification/api-tracing.md
Original file line number Diff line number Diff line change
Expand Up @@ -537,24 +537,54 @@ Returns true if the canonical code of this `Status` is `Ok`, otherwise false.

## SpanKind

Depending on the `Span` position in a `Trace` and application components
boundaries, it can play a different role. This role often defines how `Span`
will be processed and visualized by various backends. So it is important to
record this "hint" whenever possible to the best of the caller's knowledge.
`SpanKind` describes the relationship bewteen the Span, its parents,
jmacd marked this conversation as resolved.
Show resolved Hide resolved
and its children in a Trace. `SpanKind` describes two independent
properties that benefit tracing systems during analysis.

The first property described by `SpanKind` reflects whether the Span
is a remote child or parent. Spans with a remote parent are
interesting because they are sources of external load. Spans with a
remote child are interesting because they reflect a non-local system
dependency.

The second property described by `SpanKind` reflects whether a child
Span represents a synchronous call. When a child span is synchronous,
the parent is expected to wait for it to complete under ordinary
circumstances. It can be useful for tracing systems to know this
property, since synchronous Spans may contribute to the overall trace
latency.
Copy link
Member

Choose a reason for hiding this comment

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

Some RPC frameworks (well, not really 'P' as in 'procedure) support one-way calls, that may or may not be acked on delivery, but certainly do not provide for a result to be returned to the caller (e.g. firing off a UDP message).

What span_kind should the caller use in that case? Producer?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think this question points out that SpanKind is still flawed.

The question is whether these two should be independent or not. Can you be a CLIENT/PRODUCER? or a SERVER/CONSUMER? I.e., can you declare that there is a remote parent/child and an asynchronous relationship?

Can you be an internal span that has a PRODUCER/CONSUMER relationship with its child? These are capabilities we found in OpenTracing via ChildOf and FollowsFrom.

I am still skeptical of this field, but at least in the current state of this PR my understanding of the intention is closer to the group's.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@SergeyKanzhelev what do you think?

Copy link
Member

Choose a reason for hiding this comment

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

I agree with you that this PR improves current spec, but not addresses the problem of SpanKind expressiveness. Similar to #65 we just stalling on decision as not many consumer uses this information to the full extent.

For me - important thing is to distinguish incoming, internal and outgoing calls. As we had in OpenCensus. Mostly for the in-proc aggregation and analysis.


In order for `SpanKind` to be meaningful, callers should arrange that
a single Span does not serve more than one purpose. For example, a
server-side span should not be used directly as the parent of another
remote span. As a simple guideline, instrumentation should create a
new Span prior to extracting and serializing the span context for a
remote call.

These are the possible SpanKinds:

* `INTERNAL` Default value. Indicates that the span represents an internal
operation within an application, as opposed to an operations happening at the
boundaries.
* `SERVER` Indicates that the span covers server-side handling of an RPC or
other remote request.
* `CLIENT` Indicates that the span describes a request to some remote service.
* `PRODUCER` Indicates that the span describes a producer sending a message to a
broker. Unlike client and server, there is often no direct critical path
latency relationship between producer and consumer spans. A `Producer` span ends
when the message was accepted by the broker while the logical processing of the
message might span a much longer time.
* `CONSUMER` Indicates that the span describes a consumer receiving a message from
a broker. As for the `PRODUCER` kind, there is often no direct critical
path latency relationship between producer and consumer spans.
* `SERVER` Indicates that the span covers server-side handling of a
synchronous RPC or other remote request. This span is the child of
a remote `CLIENT` span that was expected to wait for a response.
* `CLIENT` Indicates that the span describes a synchronous request to
some remote service. This span is the parent of a remote `SERVER`
span and waits for its response.
* `PRODUCER` Indicates that the span describes the parent of an
asynchronous request. This parent span is expected to end before
the corresponding child `CONSUMER` span, possibly even before the
child span starts.
* `CONSUMER` Indicates that the span describes the child of an
asynchronous remote `PRODUCER` request.
* `INTERNAL` Default value. Indicates that the span represents an
internal operation within an application, as opposed to an
operations with remote parents or children.

To summarize the interpretation of these kinds:

| `SpanKind` | Synchronous | Asynchronous | Remote Incoming | Remote Outgoing |
|--|--|--|--|--|
| `CLIENT` | yes | | | yes |
| `SERVER` | yes | | yes | |
| `PRODUCER` | | yes | | yes|
| `CONSUMER` | | yes | yes | |
| `INTERNAL` | | | | |