Clarify some details about span kind and the meanings of the values. #1738
Conversation
There was a problem hiding this comment.
I am not sure that these changes resolved #1360 completely.
Also, if the goal of these changes is to allow nested CLIENT spans, then I am against it :) For a very specific reason: if we have several CLIENT spans during one remote call, which of those spans should be propagated?
| @@ -697,7 +697,9 @@ 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 | |||
| is a "logical" remote child or parent. By "logical", we mean that | |||
| the span is logically a remote child or parent, from the point of view | |||
There was a problem hiding this comment.
In this section you say both "remote child" and "span with a remote parent". I am afraid "remote child" will be somewhat confusing term. Or at least we have to explicitly define what is "remote child".
I think it's very simple: the last one to touch the headers is the one that is propagated. Is there more complication that I'm not considering? |
|
I removed my objection after offline discussion with @jkwatson |
iNikem
dismissed
their stale review
I removed my objection after offline discussion with @jkwatson
|
I agree it's needed to relax this constraint on nesting. I'm wondering if there's anything we can do to make it easier on backends that use CLIENT/SERVER and PRODUCER/CONSUMER spans to draw service maps, e.g. we had this discussion in Java a while ago before we started suppressing nested CLIENT spans: open-telemetry/opentelemetry-java-instrumentation#440 |
carlosalberto
added
area:api
|
Let's merge this right after the 1.4 release as we have enough approvals. |
Fixes #1360
Changes
Provides some additional clarity around Span.Kind and the meanings of the various values.