-
Notifications
You must be signed in to change notification settings - Fork 729
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
Allow specifying parent and/or follows_from of spans made by #[instrument] #879
Comments
Now that we accept arbitrary expressions in struct MyGreatStruct {
/* ... my great fields */
span: tracing::Span,
}
impl MyGreatStruct {
#[instrument(parent = &self.span), skip(self)]
pub fn do_something_interesting(&self, /* ... cool method parameters ... */) {
/* do something interesting and cool */
}
} I think adding this should be pretty simple. We would add a new custom keyword for tracing/tracing-attributes/src/lib.rs Lines 776 to 783 in c9f8b6d
and then add logic for parsing the parent keyword in InstrumentArgs::parse :tracing/tracing-attributes/src/lib.rs Lines 553 to 558 in c9f8b6d
We would parse any expression after the We could probably do something similar for a
I don't think this strictly relies on skipping |
I will implement this :) thanks for the explanation |
## Motivation Resolves part of tokio-rs#879.
#2091) This PR extends the `#[instrument]` attribute to accept an optionally `parent = …` argument that provides an explicit parent to the generated `Span`. ## Motivation This PR resolves #2021 and partially resolves #879. (It only partly resolves #879 in that it only provides a mechanism for specifying an explicit parent, but *not* for invoking `follows_from`.) ## Solution This PR follows the implementation strategy articulated by @hawkw: #879 (comment). The user-provided value to the `parent` argument may be any expression, and this expression is provided directly to the invocation of [`span!`](https://tracing.rs/tracing/macro.span.html).
The optional `follows_from` argument allows users to specify any number of `Span::follows_from` relationships. The value to this argument is an expression of type: `impl IntoIterator<Item = impl Into<Option<Id>>>` Fixes: tokio-rs#879
This PR extends the `#[instrument]` attribute to accept an optional `follows_from = …` argument that supplies any number of `Span::follows_from` relationships to the generated `Span`. ## Motivation This PR resolves #879. ## Solution This PR largely follows the implementation strategy articulated by @hawkw: #879 (comment) In that comment, @hawkw suggests taking one of two approaches: 1. each `follows_from` relationship is supplied with a distinct `follows_from` argument 2. the `follows_from` argument is provided once, and its value is a **list** of indirect causes I take the second approach, since it is slightly more flexible: it allows for the number of indirect causes to vary at runtime. This addition is complemented by changes to `tracing-mock` to permit making `follows_from` assertions for testing purposes.
#2091) This PR extends the `#[instrument]` attribute to accept an optionally `parent = …` argument that provides an explicit parent to the generated `Span`. ## Motivation This PR resolves #2021 and partially resolves #879. (It only partly resolves #879 in that it only provides a mechanism for specifying an explicit parent, but *not* for invoking `follows_from`.) ## Solution This PR follows the implementation strategy articulated by @hawkw: #879 (comment). The user-provided value to the `parent` argument may be any expression, and this expression is provided directly to the invocation of [`span!`](https://tracing.rs/tracing/macro.span.html).
This PR extends the `#[instrument]` attribute to accept an optional `follows_from = …` argument that supplies any number of `Span::follows_from` relationships to the generated `Span`. ## Motivation This PR resolves #879. ## Solution This PR largely follows the implementation strategy articulated by @hawkw: #879 (comment) In that comment, @hawkw suggests taking one of two approaches: 1. each `follows_from` relationship is supplied with a distinct `follows_from` argument 2. the `follows_from` argument is provided once, and its value is a **list** of indirect causes I take the second approach, since it is slightly more flexible: it allows for the number of indirect causes to vary at runtime. This addition is complemented by changes to `tracing-mock` to permit making `follows_from` assertions for testing purposes.
#2091) This PR extends the `#[instrument]` attribute to accept an optionally `parent = …` argument that provides an explicit parent to the generated `Span`. ## Motivation This PR resolves #2021 and partially resolves #879. (It only partly resolves #879 in that it only provides a mechanism for specifying an explicit parent, but *not* for invoking `follows_from`.) ## Solution This PR follows the implementation strategy articulated by @hawkw: #879 (comment). The user-provided value to the `parent` argument may be any expression, and this expression is provided directly to the invocation of [`span!`](https://tracing.rs/tracing/macro.span.html).
This PR extends the `#[instrument]` attribute to accept an optional `follows_from = …` argument that supplies any number of `Span::follows_from` relationships to the generated `Span`. ## Motivation This PR resolves #879. ## Solution This PR largely follows the implementation strategy articulated by @hawkw: #879 (comment) In that comment, @hawkw suggests taking one of two approaches: 1. each `follows_from` relationship is supplied with a distinct `follows_from` argument 2. the `follows_from` argument is provided once, and its value is a **list** of indirect causes I take the second approach, since it is slightly more flexible: it allows for the number of indirect causes to vary at runtime. This addition is complemented by changes to `tracing-mock` to permit making `follows_from` assertions for testing purposes.
#2091) This PR extends the `#[instrument]` attribute to accept an optionally `parent = …` argument that provides an explicit parent to the generated `Span`. ## Motivation This PR resolves #2021 and partially resolves #879. (It only partly resolves #879 in that it only provides a mechanism for specifying an explicit parent, but *not* for invoking `follows_from`.) ## Solution This PR follows the implementation strategy articulated by @hawkw: #879 (comment). The user-provided value to the `parent` argument may be any expression, and this expression is provided directly to the invocation of [`span!`](https://tracing.rs/tracing/macro.span.html).
This PR extends the `#[instrument]` attribute to accept an optional `follows_from = …` argument that supplies any number of `Span::follows_from` relationships to the generated `Span`. ## Motivation This PR resolves #879. ## Solution This PR largely follows the implementation strategy articulated by @hawkw: #879 (comment) In that comment, @hawkw suggests taking one of two approaches: 1. each `follows_from` relationship is supplied with a distinct `follows_from` argument 2. the `follows_from` argument is provided once, and its value is a **list** of indirect causes I take the second approach, since it is slightly more flexible: it allows for the number of indirect causes to vary at runtime. This addition is complemented by changes to `tracing-mock` to permit making `follows_from` assertions for testing purposes.
This PR extends the `#[instrument]` attribute to accept an optional `follows_from = …` argument that supplies any number of `Span::follows_from` relationships to the generated `Span`. ## Motivation This PR resolves #879. ## Solution This PR largely follows the implementation strategy articulated by @hawkw: #879 (comment) In that comment, @hawkw suggests taking one of two approaches: 1. each `follows_from` relationship is supplied with a distinct `follows_from` argument 2. the `follows_from` argument is provided once, and its value is a **list** of indirect causes I take the second approach, since it is slightly more flexible: it allows for the number of indirect causes to vary at runtime. This addition is complemented by changes to `tracing-mock` to permit making `follows_from` assertions for testing purposes.
This PR extends the `#[instrument]` attribute to accept an optional `follows_from = …` argument that supplies any number of `Span::follows_from` relationships to the generated `Span`. ## Motivation This PR resolves #879. ## Solution This PR largely follows the implementation strategy articulated by @hawkw: #879 (comment) In that comment, @hawkw suggests taking one of two approaches: 1. each `follows_from` relationship is supplied with a distinct `follows_from` argument 2. the `follows_from` argument is provided once, and its value is a **list** of indirect causes I take the second approach, since it is slightly more flexible: it allows for the number of indirect causes to vary at runtime. This addition is complemented by changes to `tracing-mock` to permit making `follows_from` assertions for testing purposes.
#2091) This PR extends the `#[instrument]` attribute to accept an optionally `parent = …` argument that provides an explicit parent to the generated `Span`. ## Motivation This PR resolves #2021 and partially resolves #879. (It only partly resolves #879 in that it only provides a mechanism for specifying an explicit parent, but *not* for invoking `follows_from`.) ## Solution This PR follows the implementation strategy articulated by @hawkw: #879 (comment). The user-provided value to the `parent` argument may be any expression, and this expression is provided directly to the invocation of [`span!`](https://tracing.rs/tracing/macro.span.html).
This PR extends the `#[instrument]` attribute to accept an optional `follows_from = …` argument that supplies any number of `Span::follows_from` relationships to the generated `Span`. ## Motivation This PR resolves #879. ## Solution This PR largely follows the implementation strategy articulated by @hawkw: #879 (comment) In that comment, @hawkw suggests taking one of two approaches: 1. each `follows_from` relationship is supplied with a distinct `follows_from` argument 2. the `follows_from` argument is provided once, and its value is a **list** of indirect causes I take the second approach, since it is slightly more flexible: it allows for the number of indirect causes to vary at runtime. This addition is complemented by changes to `tracing-mock` to permit making `follows_from` assertions for testing purposes.
…` (#2091) This PR extends the `#[instrument]` attribute to accept an optionally `parent = …` argument that provides an explicit parent to the generated `Span`. ## Motivation This PR resolves #2021 and partially resolves #879. (It only partly resolves #879 in that it only provides a mechanism for specifying an explicit parent, but *not* for invoking `follows_from`.) ## Solution This PR follows the implementation strategy articulated by @hawkw: tokio-rs/tracing#879 (comment). The user-provided value to the `parent` argument may be any expression, and this expression is provided directly to the invocation of [`span!`](https://tracing.rs/tracing/macro.span.html).
This PR extends the `#[instrument]` attribute to accept an optional `follows_from = …` argument that supplies any number of `Span::follows_from` relationships to the generated `Span`. ## Motivation This PR resolves #879. ## Solution This PR largely follows the implementation strategy articulated by @hawkw: tokio-rs/tracing#879 (comment) In that comment, @hawkw suggests taking one of two approaches: 1. each `follows_from` relationship is supplied with a distinct `follows_from` argument 2. the `follows_from` argument is provided once, and its value is a **list** of indirect causes I take the second approach, since it is slightly more flexible: it allows for the number of indirect causes to vary at runtime. This addition is complemented by changes to `tracing-mock` to permit making `follows_from` assertions for testing purposes.
This PR extends the `#[instrument]` attribute to accept an optional `follows_from = …` argument that supplies any number of `Span::follows_from` relationships to the generated `Span`. ## Motivation This PR resolves tokio-rs#879. ## Solution This PR largely follows the implementation strategy articulated by @hawkw: tokio-rs#879 (comment) In that comment, @hawkw suggests taking one of two approaches: 1. each `follows_from` relationship is supplied with a distinct `follows_from` argument 2. the `follows_from` argument is provided once, and its value is a **list** of indirect causes I take the second approach, since it is slightly more flexible: it allows for the number of indirect causes to vary at runtime. This addition is complemented by changes to `tracing-mock` to permit making `follows_from` assertions for testing purposes.
Feature Request
Crates
tracing & tracing-core, I think.
Motivation
It would be very useful to have support for
#[instrument]
on methods of a type which holds a span corresponding to its lifecycle.Proposal
It's not (yet?) possible to inject fields into a struct from a derive, so we'll assume that a user has added a span field to the type whose lifecycle we're tracking:
What I think we want is a way for that span to be used as the immediate span for method calls that are annotated with instrument:
In this example,
send_response
's span would have the value's span as its parent. I think we'd also want a way to say that the method's span follows from the span which was active when the call was made, so that the method's span is connected both to the object and to the active tree of spans. Maybe that should be implicit or have a convenient shorthand?Alternatives
We could express these semantics in terms of a trait, like
Then
#[instrument]
could have a shorthand for usingself
's span:Related
This relies on #651 to omit
self
by default from instrumentation. The core idea is to provide a less verbose way to instrumentself
.The text was updated successfully, but these errors were encountered: