-
Notifications
You must be signed in to change notification settings - Fork 721
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
tracing-subscriber: span events don't include span fields with json formatter #1032
Comments
The behavior here is actually the same: in both cases, the span events are treated as children of the span that generated them. When using the human-readable formatter, the parent span context (including the span's fields) is displayed first. With the JSON formatter, displaying span contexts on events needs to be enabled by calling either I believe
should get you analogous behavior to the human-readable formatter. In |
Thanks for the quick reply. I don't think this works quite as expected. I created a more complex example to demonstrate: use tracing_subscriber::fmt::format::FmtSpan;
fn main() {
tracing_subscriber::fmt()
.json()
.with_current_span(true)
.with_span_list(true)
.with_span_events(FmtSpan::FULL)
.init();
tracing::info_span!("testspan", data="testdata").in_scope(|| {
tracing::info!("testevent")
});
}here
The |
Hmm, that does indeed look like a bug. I'll take a look to see why those fields are missing. |
New, exit and close span events are generated while the current context is set to either `None` or the parent span of the span the event relates to. This causes spans data to be absent from the JSON output in the case of the `None`, or causes the span data to reference the parent's span data. Changing the way the current span is determined allows the correct span to be identified for these events. Trying to access the events `.parent()` allows access of the correct span for the `on_event` actions, while using `.current_span()` works for normal events. Ref: tokio-rs#1032
* subscriber: fix span data for new, exit, and close events New, exit and close span events are generated while the current context is set to either `None` or the parent span of the span the event relates to. This causes spans data to be absent from the JSON output in the case of the `None`, or causes the span data to reference the parent's span data. Changing the way the current span is determined allows the correct span to be identified for these events. Trying to access the events `.parent()` allows access of the correct span for the `on_event` actions, while using `.current_span()` works for normal events. Ref: #1032 * Fix style * subscriber: improve test for #1333 Based on feedback by @hawkw, I've improved the test for #1333 to parse the json output. This is more specifc for the bug and allows easier testing of the different span `on_events`. Ref: #1333 (review) * subscriber: improve #1334 tests covering all span states Use the `on_records` test method check all events have the correct context as described in the PR. * Apply suggestions from code review Co-authored-by: Eliza Weisman <eliza@buoyant.io>
* subscriber: fix span data for new, exit, and close events New, exit and close span events are generated while the current context is set to either `None` or the parent span of the span the event relates to. This causes spans data to be absent from the JSON output in the case of the `None`, or causes the span data to reference the parent's span data. Changing the way the current span is determined allows the correct span to be identified for these events. Trying to access the events `.parent()` allows access of the correct span for the `on_event` actions, while using `.current_span()` works for normal events. Ref: #1032 * Fix style * subscriber: improve test for #1333 Based on feedback by @hawkw, I've improved the test for #1333 to parse the json output. This is more specifc for the bug and allows easier testing of the different span `on_events`. Ref: #1333 (review) * subscriber: improve #1334 tests covering all span states Use the `on_records` test method check all events have the correct context as described in the PR. * Apply suggestions from code review Co-authored-by: Eliza Weisman <eliza@buoyant.io>
* subscriber: fix span data for new, exit, and close events New, exit and close span events are generated while the current context is set to either `None` or the parent span of the span the event relates to. This causes spans data to be absent from the JSON output in the case of the `None`, or causes the span data to reference the parent's span data. Changing the way the current span is determined allows the correct span to be identified for these events. Trying to access the events `.parent()` allows access of the correct span for the `on_event` actions, while using `.current_span()` works for normal events. Ref: #1032 * Fix style * subscriber: improve test for #1333 Based on feedback by @hawkw, I've improved the test for #1333 to parse the json output. This is more specifc for the bug and allows easier testing of the different span `on_events`. Ref: #1333 (review) * subscriber: improve #1334 tests covering all span states Use the `on_records` test method check all events have the correct context as described in the PR. * Apply suggestions from code review Co-authored-by: Eliza Weisman <eliza@buoyant.io>
Bug Report
Version
Platform
Linux saren 5.8.14-arch1-1 #1 SMP PREEMPT Wed, 07 Oct 2020 23:59:46 +0000 x86_64 GNU/Linux
Crates
tracing-subscriber
Description
Span events that are enabled by
SubscriberBuilder::with_span_events
include the span's fields when the default formatter (that prints human-friendly logs) is used. I also expected this to be the case when the json formatter is used (SubscriberBuilder::json
) but no span fields are included in the json.Without json:
Field data is shown here.
With json:
Field data is not shown here.
Code:
The text was updated successfully, but these errors were encountered: