Make tracer to add ignored parents as links as an option, add initial semantic conventions for links

[krnowak]

In opentelemetry-go, we have implemented (but not yet merged - open-telemetry/opentelemetry-go#451) an option for forcing the tracer to create a new root span (this is required by the specification). We decided that putting the possible-but-ignored parents as link into the span can be useful. This is not currently mandated by the specification, so this PR tries to take a stab at it. I'm not sure if the place where I propose the attribute keys and values for link attributes is the right place, so please correct me if it is not. Thanks.

[Oberon00]

@krnowak

(this is required by the specification)

Which specification? W3C or OTel? Can you please add a link?

EDIT: Also, the go PR you linked is huge. Can you please summarize the relevant parts here so that one can understand the issue without reading the PR diff?

[dyladan]

As I understand it, when they call startSpan, it implicitly gets a parent from the current context. They added an option to force it to become a root span.

link to spec for that: https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/api-tracing.md#span-creation

The API MUST accept the following parameters:

• The parent Span or a Context containing a parent Span or SpanContext, and whether the new Span should be a root Span.

This PR makes it so that when you call startSpan and force it to be a root span in the case where there was a Span or SpanContext that would have become the parent automatically, that Span/SpanContext which would have been the parent (but isn't because this is a root span) should be added as a Link.

[yurishkuro]

I think this is the first time we have a specific prescription for link attributes. I am not sure this doc is the place for it, or the only place, because this is clearly a semantic convention that should be documented in the data-* docs. And if we have more conventions for link attributes, I would like them to be consolidated in one document.

On the subject of capturing ignored parent, it sounds like a reasonable behavior.

[krnowak]

@Oberon00

About requirement - I was referring to the sentence "Implementations MUST provide an option to create a Span as a root span, and MUST generate a new TraceId for each root span created.".

And the relevant changes in the PR are here:

• The helper for getting a parent and capturing the ignored parents as links (internal/trace/parent/parent.go) - https://github.com/open-telemetry/opentelemetry-go/pull/451/files#diff-0f0866c95e7bc01ff2da6b0ccf5272e2
• The use of the helper in SDK tracer (sdk/trace/tracer.go) - https://github.com/open-telemetry/opentelemetry-go/pull/451/files#diff-4cca7318f7aada52d99d496de00b24ed
• The API changes (api/trace/api.go) - https://github.com/open-telemetry/opentelemetry-go/pull/451/files#diff-833089f51cfa7ededccfcfae309887bd

[krnowak]

Updated the PR. Added a new document with semantic conventions for link attributes.

[krnowak]

Updated.

[Oberon00]

That would be the first semantic conventions to use dashes in keys. I suggest using ignoredparent or ignored_parent instead.

[jmacd]

I would prefer to keep the word "ignored" out. That will be clear in context. Maybe instead just parent.kind=PSK where PSK is the parent SpanKind.

[krnowak]

I'd go with the "local" and "remote" kinds for now, because getting the parent SpanKind would require an access to the Span, which might not be available if all we got is the span context from the propagator.

[krnowak]

Changed the prefix to parent.

[SergeyKanzhelev]

I agree with @yurishkuro that adding the link types should be a bigger discussion. It also feels that the proposed flag addresses a very specific use case and there may be more requirements. Can the same be implemented via SpanProcessor.Start callback so more elaborate logic can be added if needed?

[SergeyKanzhelev]

another option may be to add traceparent of the ignored parent to the tracestate. It may be more involved design as we will need to decide how the key in tracestate will be called and how to write the original traceparent value there.

What scenario do you envision here? Can it be implemented via the SpanProcessor so customer may apply some custom logic like I described with the tracestate?

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[github-actions]

Closed as inactive. Feel free to reopen if this PR is still being worked on.