Add filters for emitting Tracing diagnostics #656
Conversation
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
...we can still avoid round-tripping through the subscriber to clone the span, though. Signed-off-by: Eliza Weisman <eliza@buoyant.io>
we are not building an access log with our structured fields Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
|
I merged #655, which looks like this was based on. Mind rebasing master with this? |
|
@seanmonstar should be good now, I think? |
Co-authored-by: Billy Main <wmain@netflix.com>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
|
@seanmonstar okay, I fixed the mismatched targets, and also made a couple more tweaks to hopefully get more readable logs from the default Hopefully you folks agree that this is more usable? |
|
Yes, that's a nice improvement! Looking again, perhaps the user-agent shouldn't be included separately if the full headers are also included, because then it appears twice. |
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Good call --- fixed it! |
| Ok((Traced(resp),)) => { | ||
| tracing::info!(target: "warp::filters::trace", status = resp.status().as_u16(), "finished processing with success"); | ||
| } |
There was a problem hiding this comment.
Is it intentional that the log level (INFO/WARN/ERROR) is determined based on whether the result is Ok or a Err(Rejection)?
I would expect that if a filter returns an explicit reply (*) with 4xx or 5xx, this should still be logged as WARN/ERROR respectively, same as built-in known rejections that result in 4xx/5xx.
(*) such as when adhering to "not all errors are rejections" philosophy
The
tracingcrate and related libraries provide an interface for Rustlibraries and applications to emit and consume structured, contextual,
and async-aware diagnostic information.
tracingis maintained by theTokio project and is becoming widely adopted by other libraries in the
stack Warp uses, such as
hyper,h2, andtonicand in otherparts of the broader Rust ecosystem.
This PR provides a new
warp::tracemodule with filters to be usedwhen instrumenting Warp applications with
tracing. This has to beimplemented inside of
warp, because correctly instrumenting futureswith
tracingspans requires the ability to wrap the future returnedby the inner filter. This branch is based on my PR #655, which migrates
Warp's internal diagnostics to Tracing.
This branch builds on the work done by @barskern in #408. I've updated
his branch to be based on the latest Warp master, added the convenience
filter for naming routes, example, and improved documentation from [my
initial attempt][1] at adding Tracing support to Warp, and made some
tweaks to the formatting of the generated traces and the user-facing
API. But, an equal amount of the credit goes to @barskern! <3
Here's some sample output from the tracing example:
Closes #288
Depends on #655
Co-authored-by: Ole Martin Ruud barskern@outlook.com
Signed-off-by: Eliza Weisman eliza@buoyant.io