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

opentelemetry: Add extension to link spans #1516

Merged
merged 4 commits into from
Aug 23, 2021

Conversation

LehMaxence
Copy link
Contributor

Repeat of #1480 to merge on master.

Motivation

Discussed in #1121, the opentelemetry specifications allow adding a link to a propagated span and/or a closed span. However, the implemented on_follows_from of the OpenTelemetryLayer does not allow this.

Solution

The solution follows the same model as the set_parent Span extension function.
A add_link function that takes the linked span context was added to the OpenTelemetrySpanExt.

Discussed in tokio-rs#1121, the purpose of adding the `add_link` extension is to allow adding a link to a
propagated span and/or a closed span.
@LehMaxence LehMaxence requested review from jtescher and a team as code owners August 18, 2021 18:05
Copy link
Member

@hawkw hawkw left a comment

Choose a reason for hiding this comment

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

looks good to me! commented on a couple of minor things, but no blockers.

let's see if @jtescher has anything to add?

tracing-opentelemetry/src/span_ext.rs Outdated Show resolved Hide resolved
if let Some(cx) = cx.take() {
let follows_context = cx.span().span_context().clone();
let follows_link =
opentelemetry::trace::Link::new(follows_context, Vec::new());
Copy link
Member

Choose a reason for hiding this comment

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

I notice this will always create a link with no key-value attributes. Do you think it makes sense to include a separate function like add_link_with_attributes(&self, cx: Context, attrs: Vec<KeyValue>), or something?

We can always add this in a separate PR, of course.

Copy link
Collaborator

Choose a reason for hiding this comment

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

add_link_with_attributes sounds good to me 👍

/// // Or if the current span has been created elsewhere:
/// Span::current().add_link(parent_context);
/// ```
fn add_link(&self, cx: Context);
Copy link
Member

Choose a reason for hiding this comment

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

oh, one other thought. I notice that in the examples, the Context parameter always has to be cloned...but in the add_link method, we borrow the span from the context, and then clone the SpanContext from the span...so, afaict, we could just borrow the Context parameter rather than forcing the user to clone it when calling this method. that might be more efficient, as well?

but, on the other hand, existing methods on this trait (e.g. set_parent) take the Context by value, so maybe it's preferable to be consistent? IDK.

@jtescher what do you think?

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 was trying to be consistent with set_parent, as you notice, but that may not be necessary indeed.

Copy link
Member

Choose a reason for hiding this comment

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

yeah, i think there's kind of a tradeoff between consistency and ergonomics (and possibly performance?) here...i'd probably go with taking it by reference, but it's @jtescher's call.

alternatively, should this method just take the SpanContext? that way, the user can get it from somewhere other than a Context...i'm not sure if there's a use-case for that, or not?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The method could just take SpanContext since links don't care about the whole Context.
However propagators return Context so maybe we need both fn add_link(&self, cx: SpanContext) and fn add_link(&self, cx: &Context) .

fn add_link(&self, cx: &Context) would just get the SpanContext of the Context and pass it to fn add_link(&self, cx: SpanContext)

Copy link
Collaborator

Choose a reason for hiding this comment

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

So the add_link spec suggests a SpanContext directly, while the span creation spec explicitly requires a full Context to set a parent so the parameter discrepancy seems intentional.

Comment on lines 123 to 139
fn add_link(&self, cx: Context) {
let mut cx = Some(cx);
self.with_collector(move |(id, collector)| {
if let Some(get_context) = collector.downcast_ref::<WithContext>() {
get_context.with_context(collector, id, move |builder, _tracer| {
if let Some(cx) = cx.take() {
let follows_context = cx.span().span_context().clone();
let follows_link =
opentelemetry::trace::Link::new(follows_context, Vec::new());
if let Some(ref mut links) = builder.links {
links.push(follows_link);
} else {
builder.links = Some(vec![follows_link]);
}
}
});
}
Copy link
Member

Choose a reason for hiding this comment

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

i think that if we borrowed the Context parameter, as in my above suggestion, the implementation would be a bit simpler:

Suggested change
fn add_link(&self, cx: Context) {
let mut cx = Some(cx);
self.with_collector(move |(id, collector)| {
if let Some(get_context) = collector.downcast_ref::<WithContext>() {
get_context.with_context(collector, id, move |builder, _tracer| {
if let Some(cx) = cx.take() {
let follows_context = cx.span().span_context().clone();
let follows_link =
opentelemetry::trace::Link::new(follows_context, Vec::new());
if let Some(ref mut links) = builder.links {
links.push(follows_link);
} else {
builder.links = Some(vec![follows_link]);
}
}
});
}
fn add_link(&self, cx: &Context) {
self.with_collector(|(id, collector)| {
if let Some(get_context) = collector.downcast_ref::<WithContext>() {
get_context.with_context(collector, id, |builder, _tracer| {
let follows_context = cx.span().span_context().clone();
let follows_link =
opentelemetry::trace::Link::new(follows_context, Vec::new());
if let Some(ref mut links) = builder.links {
links.push(follows_link);
} else {
builder.links = Some(vec![follows_link]);
}
});
}

LehMaxence and others added 3 commits August 18, 2021 15:43
Co-authored-by: Eliza Weisman <eliza@buoyant.io>
Implement OpenTelemetry API specification for links
@hawkw hawkw merged commit eb9b685 into tokio-rs:master Aug 23, 2021
hawkw pushed a commit that referenced this pull request Sep 4, 2021
Repeat of #1480 to merge on master.

## Motivation

Discussed in #1121, the opentelemetry specifications allow adding a link
to a propagated span and/or a closed span. However, the implemented
`on_follows_from` of the `OpenTelemetryLayer` does not allow this.

## Solution

The solution follows the same model as the `set_parent` `Span` extension
function. A `add_link` function that takes the linked span context was
added to the `OpenTelemetrySpanExt`.
hawkw pushed a commit that referenced this pull request Sep 4, 2021
Repeat of #1480 to merge on master.

## Motivation

Discussed in #1121, the opentelemetry specifications allow adding a link
to a propagated span and/or a closed span. However, the implemented
`on_follows_from` of the `OpenTelemetryLayer` does not allow this.

## Solution

The solution follows the same model as the `set_parent` `Span` extension
function. A `add_link` function that takes the linked span context was
added to the `OpenTelemetrySpanExt`.
hawkw added a commit that referenced this pull request Oct 23, 2021
# 0.16.0 (October 23, 2021)

### Breaking Changes

- Upgrade to `v0.3.0` of `tracing-subscriber` ([#1677]) For list of
  breaking changes in `tracing-subscriber`, see the [v0.3.0 changelog].

### Added

- `OpenTelemetrySpanExt::add_link` method for adding a link between a
  `tracing` span and a provided OpenTelemetry `Context` ([#1516])

Thanks to @LehMaxence for contributing to this release!

[v0.3.0 changelog]: https://github.com/tokio-rs/tracing/releases/tag/tracing-subscriber-0.3.0
[#1516]: #1516
[#1677]: #1677
hawkw added a commit that referenced this pull request Oct 23, 2021
# 0.16.0 (October 23, 2021)

### Breaking Changes

- Upgrade to `v0.3.0` of `tracing-subscriber` ([#1677]) For list of
  breaking changes in `tracing-subscriber`, see the [v0.3.0 changelog].

### Added

- `OpenTelemetrySpanExt::add_link` method for adding a link between a
  `tracing` span and a provided OpenTelemetry `Context` ([#1516])

Thanks to @LehMaxence for contributing to this release!

[v0.3.0 changelog]: https://github.com/tokio-rs/tracing/releases/tag/tracing-subscriber-0.3.0
[#1516]: #1516
[#1677]: #1677
hawkw added a commit that referenced this pull request Oct 23, 2021
# 0.16.0 (October 23, 2021)

### Breaking Changes

- Upgrade to `v0.3.0` of `tracing-subscriber` ([#1677]) For list of
  breaking changes in `tracing-subscriber`, see the [v0.3.0 changelog].

### Added

- `OpenTelemetrySpanExt::add_link` method for adding a link between a
  `tracing` span and a provided OpenTelemetry `Context` ([#1516])

Thanks to @LehMaxence for contributing to this release!

[v0.3.0 changelog]: https://github.com/tokio-rs/tracing/releases/tag/tracing-subscriber-0.3.0
[#1516]: #1516
[#1677]: #1677
davidbarsky pushed a commit to tokio-rs/tracing-opentelemetry that referenced this pull request Mar 21, 2023
# 0.16.0 (October 23, 2021)

### Breaking Changes

- Upgrade to `v0.3.0` of `tracing-subscriber` ([#1677]) For list of
  breaking changes in `tracing-subscriber`, see the [v0.3.0 changelog].

### Added

- `OpenTelemetrySpanExt::add_link` method for adding a link between a
  `tracing` span and a provided OpenTelemetry `Context` ([#1516])

Thanks to @LehMaxence for contributing to this release!

[v0.3.0 changelog]: https://github.com/tokio-rs/tracing/releases/tag/tracing-subscriber-0.3.0
[#1516]: tokio-rs/tracing#1516
[#1677]: tokio-rs/tracing#1677
kaffarell pushed a commit to kaffarell/tracing that referenced this pull request May 22, 2024
Repeat of tokio-rs#1480 to merge on master.

## Motivation

Discussed in tokio-rs#1121, the opentelemetry specifications allow adding a link
to a propagated span and/or a closed span. However, the implemented
`on_follows_from` of the `OpenTelemetryLayer` does not allow this.

## Solution

The solution follows the same model as the `set_parent` `Span` extension
function. A `add_link` function that takes the linked span context was
added to the `OpenTelemetrySpanExt`.
kaffarell pushed a commit to kaffarell/tracing that referenced this pull request May 22, 2024
# 0.16.0 (October 23, 2021)

### Breaking Changes

- Upgrade to `v0.3.0` of `tracing-subscriber` ([tokio-rs#1677]) For list of
  breaking changes in `tracing-subscriber`, see the [v0.3.0 changelog].

### Added

- `OpenTelemetrySpanExt::add_link` method for adding a link between a
  `tracing` span and a provided OpenTelemetry `Context` ([tokio-rs#1516])

Thanks to @LehMaxence for contributing to this release!

[v0.3.0 changelog]: https://github.com/tokio-rs/tracing/releases/tag/tracing-subscriber-0.3.0
[tokio-rs#1516]: tokio-rs#1516
[tokio-rs#1677]: tokio-rs#1677
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants