### Fixed
- **docs**: Incorrect formatting (#862)
### Changed
- **filter**: `LevelFilter` is now a re-export of the
`tracing_core::LevelFilter` type, it can now be used interchangably
with the versions in `tracing` and `tracing-core` (#853)
- **filter**: Significant performance improvements when comparing
`LevelFilter`s and `Level`s (#853)
- Updated the minimum `tracing-core` dependency to 0.1.12 (#853)
### Added
- **filter**: `LevelFilter` and `EnvFilter` now participate in
`tracing-core`'s max level hinting, improving performance
significantly in some use cases where levels are disabled globally
(#853)
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
Some opentracing systems use fields with : in the names, which are not
legal rust identifiers. We could special case :, but then we have
complicated double-nested patterns (repeated idents separated by : and a
nested repeat separated by .), and this may by a case of always being
one-step-behind as more cases turn up; so this patch instead just gets
in front and lets users put in whatever they want: as they are not rust
identifiers, they miss out on some niceness.
## Solution
This permits : in field names but also potentially anything
stringifiable, which may be overly liberal.
Signed-off-by: Robert Collins <robert.collins@cognite.com>
### Fixed
- **fmt**: Fixed compilation failure on MSRV when the `chrono` feature
is disabled (#844)
### Added
- **fmt**: Span lookup methods defined by `layer::Context` are now also
provided by `FmtContext` (#834)
### Changed
- **fmt**: When the `chrono` dependency is enabled, the `SystemTime`
timestamp now emits human-readable timestamps rather than using
`SystemTime`'s fmt::Debug`implementation (`chrono` is still required
for customized timestamp formatting) (#807)
- **ansi**: Updated `ansi_term` dependency to 0.12 (#816)
### Added
- **json**: `with_span_list` method to configure the JSON formatter to
include a list of all spans in the current trace in formatting events
(similarly to the text formatter) (#741)
- **json**: `with_current_span` method to configure the JSON formatter
to include a field for the _current_ span (the leaf of the trace) in
formatted events (#741)
- **fmt**: `with_thread_names` and `with_thread_ids` methods to
configure `fmt::Subscriber`s and `fmt::Layer`s to include the thread
name and/or thread ID of the current thread when formatting events
(#818)
Thanks to new contributors @mockersf, @keetonian, and @Pothulapati for
contributing to this release!
## Motivation
Fixes#809
## Solution
This PR adds two new methods i.e `with_thread_ids` and
`with_thread_names` to the fmt Layer which passed till
the pre-configured Format type, where the check is performed
and these the above values are formatted based on the flags.
The formatting is done by creating to new Types that impl Display
for Id and Name. For Thread Name, we keep track of the max length
of the thread name that occured till now using a thread safe static
type and pad accordingly. For Thread Id, we pad directly with 2
as in most cases we would see a double digit number of threads.
Signed-off-by: Tarun Pothulapati <tarunpothulapati@outlook.com>
## Motivation
The usage of the older version prevents crates from using newer
`env_logger` versions, as they aren't compatible with each other during
compilation.
## Solution
Move to `env_logger@0.7`
### Changed
- **parking_lot**: Updated the optional `parking_lot` dependency to
accept the latest `parking_lot` version (#774)
### Fixed
- **fmt**: Fixed events with explicitly overridden parent spans being
formatted as though they were children of the current span (#767)
### Added
- **fmt**: Added the option to print synthesized events when spans are
created, entered, exited, and closed, including span durations (#761)
- Documentation clarification and improvement (#762, #769)
Thanks to @rkuhn, @greenwoodcm, and @Ralith for contributing to this
release!
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
Support for writing tracing-based logs directly to their standard
destination while preserving both standard and custom metadata on Linux
systems. Improves usability of Linux services and for Linux applications
executing outside of a terminal.
## Solution
It turns out [journald's native protocol][1] is very simple and spoken
over a Unix datagram socket at a fixed location (see [discussion of
stability of these interfaces][2], allowing high quality native support
with ~100LoC.
[journald conventions][3] for structured field names differ from typical
tracing idioms, and journald discards fields which violate its
conventions. Hence, this layer automatically sanitizes field names by
translating `.`s into `_`s, stripping leading `_`s and
non-ascii-alphanumeric characters other than `_`, and upcasing.
Levels are mapped losslessly to journald `PRIORITY` values as follows:
- `ERROR` => Error (3)
- `WARN` => Warning (4)
- `INFO` => Notice (5)
- `DEBUG` => Informational (6)
- `TRACE` => Debug (7)
Note that the naming scheme differs slightly for the latter half.
The standard journald `CODE_LINE` and `CODE_FILE` fields are
automatically emitted. A `TARGET` field is emitted containing the
event's target. Enclosing spans are numbered counting up from the root,
and their fields and metadata are included in fields prefixed by `Sn_`
where `n` is that number.
User-defined fields other than the event `message` field have a prefix
applied by default to prevent collision with standard fields.
[1]: https://www.freedesktop.org/wiki/Software/systemd/export/
[2]: https://systemd-devel.freedesktop.narkive.com/i5tlUyjz/client-logging-to-journald-without-libsystemd-journal-so#post6
[3]: https://www.freedesktop.org/software/systemd/man/systemd.journal-fields.html
## Motivation
Currently, the default formatter implementations in
`tracing-subscriber`'s `fmt` module do not handle explicitly set parent
spans for events, such as
```rust
let span = tracing::info_span!("some_interesting_span");
tracing::info!(parent: &span, "something is happening!");
```
Instead, when formatting the span context of an event, the context is
_always_ generated from the current span, even when the event has an
overridden parent. This is not correct.
## Solution
This branch changes the default context formatters to use the explicit
parent ID, if it is present. Otherwise, the contexual parent is used, as
it was previously.
I've also added tests ensuring that this works correctly, and removed
some workarounds for the previous incorrect behavior from the examples.
Fixes#766
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Fixed
- **fmt**: Fixed an issue in the JSON formatter where using
`Span::record` would result in malformed spans (#709)
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
The [OpenTelemetry Propagation
Spec](https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/context/api-propagators.md)
has been changed from operating primarily on `SpanContext`s to a more
generic `Context` struct which is a propagation mechanism that carries
execution-scoped values across API boundaries and between logically
associated execution units.
The following APIs are updated to facilitate this change:
* OpenTelemetrySpanExt's `set_parent` now accepts a reference to an
extracted parent context.
* OpenTelemetrySpanExt's `context` now returns a context.
Additionally the need to sample spans before their context can be
injected into `Carrier`s necessitates that a `Sampler` is stored in the
`OpenTelemetryLayer`. Accordingly:
* `OpenTelemetryLayer::with_tracer(tracer)` has been removed in favor of
`tracing_opentelemetry::layer().with_tracer(tracer).with_sampler(sampler)`
Co-authored-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
It looks like Rust 1.43's version of clippy added a new lint for
redundant `use` statements with just a crate name. These are unnecessary
because the root module of an external crate is always available without
imports. Apparently, `tracing-log`, `tracing-subscriber`, `tracing`, and
`tracing-tower` all had some redundant `use` statements, which clippy now
warns us about.
## Solution
This PR removes them.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
# 0.2.4 (April 6, 2020)
This release includes several API ergonomics improvements, including
shorthand constructors for many types, and an extension trait for
initializing subscribers using method-chaining style. Additionally,
several bugs in less commonly used `fmt` APIs were fixed.
### Added
- **fmt**: Shorthand free functions for constructing most types in `fmt`
(including `tracing_subscriber::fmt()` to return a
`SubscriberBuilder`, `tracing_subscriber::fmt::layer()` to return a
format `Layer`, etc) (#660)
- **registry**: Shorthand free function `tracing_subscriber::registry()`
to construct a new registry (#660)
- Added `SubscriberInitExt` extension trait for more ergonomic
subscriber initialization (#660)
### Changed
- **fmt**: Moved `LayerBuilder` methods to `Layer` (#655)
### Deprecated
- **fmt**: `LayerBuilder`, as `Layer` now implements all builder methods
(#655)
### Fixed
- **fmt**: Fixed `Compact` formatter not omitting levels with
`with_level(false)` (#657)
- **fmt**: Fixed `fmt::Layer` duplicating the fields for a new span if
another layer has already formatted its fields (#634)
- **fmt**: Added missing space when using `record` to add new fields to
a span that already has fields (#659)
- Updated outdated documentation (#647)
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
* subscriber: add less-verbose configuration APIs
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
* even nicer easymode
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
* wip## Motivation
Users have said fairly frequently that configuring new subscribers in an
application is unnecessarily verbose and confusing. We should try to
make this nicer, especially as it's a common "on ramp" for new `tracing`
users.
## Solution
This branch adds new APIs, inspired by `tonic` and `warp`, that should
make setting up a subscriber a little less verbose. This includes:
- Many modules in `tracing-subscriber` now expose free functions
that construct default instances of various types. This makes
configuring subscribers using these types more concise, a la `warp`.
- An extension trait for adding `.set_default`, `.init`, and `.try_init`
methods to subscribers. This generalizes the similar functions on
`fmt`'s `SubscriberBuilder` to work with other subscribers.
All the old APIs are still left as they were previously. The new APIs
just provide shorthand for them.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
A recent change to `tower-util` contains a deprecation in `ServiceExt`.
The deprecation means that the `deny(warnings)` CI build fails for the
`tower-load` example.
Additionally, the `tower-h2` examples depend on a Git version of
`tower-h2`. These examples are currently commented out, since they used
an earlier version of `tower-h2`, but their dependencies are still
specified in the `examples` crate.
## Solution
I removed the use of the deprecated `ready` method.
Furthermore, I removed the broken `tower-h2` examples, and thus the git
dependency on a different version of Tower. There are 3 other examples
(`tower-client`, `tower-server`, and `tower-load`) that also demonstrate
using `tracing` together with Tower, so these broken examples aren't
really worth keeping around.
This ought to fix CI.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
# 0.2.3 (March 5, 2020)
### Fixed
- **env-filter**: Regression where filter directives were selected in the order
they were listed, rather than most specific first (#624)
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
The tracing_error crate should provide some basic functionality for
instrumenting Errors with `SpanTraces` generically. The goal is to make
it easy for users to instrument their errors without needing to add a
`SpanTrace` to every error they construct.
## Solution
Critically this trait provides 3 traits for instrumenting errors,
`InstrumentResult`, `InstrumentError`, and `ExtractSpanTrace`. The first
two traits expose a `in_current_span()` method that can work on a
`Result<T, E: InstrumentError>` and an `Error`, respectively, that wraps
the error type in a `TracedError` that stores the inner error and a
SpanTrace. The third trait, `ExtractSpanTrace`, is used to retrieve the
span_trace member of a `TracedError` from a `&dyn Error` trait object.
This is done by downcasting the error to a `TracedError` and returning
the inner `span_trace` if it is successful. By default this only works
because the inner error is stored in a Box as a trait object, which
prevents it from being part of the type signature for `TracedError`.
However, this crate also exposes a second version of `TracedError` that
does not box the inner error, thus avoiding the need for heap
allocation, which it accomplishes by type erasing the `TracedError<E>`
into a `TracedError<()>` while iterating through the error `source()`
chain.
### Changed
- **filter**: `EnvFilter` directive selection now behaves correctly
(i.e. like `env_logger`) (#583)
### Fixed
- **filter**: Fixed `EnvFilter` incorrectly allowing less-specific
filter directives to enable events that are disabled by more-specific
filters (#583)
- **filter**: Multiple significant `EnvFilter` performance
improvements, especially when filtering events generated by `log`
records (#578, #583)
- **filter**: Replaced `BTreeMap` with `Vec` in `DirectiveSet`,
improving iteration performance significantly with typical numbers of
filter directives (#580)
A big thank-you to @samschlegel for lots of help with `EnvFilter`
performance tuning in this release!
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
This PR changes the SpanTrace display format so that it no longer outputs a header prior to the output of the spans, and it changes the debug format to add one without newlines and support pretty formatting when formatting with `{:#?}`. These changes match recent changes made to the format of std::backtrace::Backtrace.
## Motivation
Intra-workspace dependencies can go out of sync if only referencing
crates.io, where changing one crate locally and testing the whole
library will result in errors stemming from two different versions of
the same trait etc. This is hard to keep track of and makes development
more difficult than it needs to be.
## Solution
Afaik it's common practice to specify both a version and a path as per
[the cargo docs][1]. This is what tokio does with its subcrates too.
[1]: https://github.com/rust-lang/cargo/blob/master/src/doc/src/reference/specifying-dependencies.md#multiple-locations.
This updates `tracing-error` to depend on `tracing-subscriber` from
crates.io, rather than via a path dependency. This means that git deps
on `tracing-error` should "actually work" now.
Additionally, I've updated the `tracing-subscriber` dep to only enable
the feature flags `tracing-error` requires. This means that depending on
`tracing-error` won't enable `tracing-subscriber`'s default features
unless they are actually needed.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
A lot of folks have expressed interest in being able to capture the
current `tracing` span context when an error type is _constructed_, so
it can eventually be displayed when the error is handled. Since span
entry is stackful, the error may not be formatted or otherwise handled
within a span context that is in any way related to the one where the
error occurred — and this is only made worse when "channels" are
involved.
## Solution
This branch introduces a new crate, `tracing-error`, which will contain
integrations and types for enriching errors with `tracing` span contexts.
Currently, this crate contains the following:
- A `SpanTrace` type, which captures the current span and allows it to be
inspected later.
- A `Layer` implementation which may be added to a `Subscriber` to
enable capturing traces for errors. This layer will format fields and
insert them into span extensions, **if no other layer has already
added such an extension** using the same formatter. This reuses the
formatting traits from `tracing-subscriber`'s `fmt` module.
## Notes
Note that we have not actually added any new error types or error
wrapper types. I would like to provide these in the future, so that
span capturing can be seamlessly integrated into the rest of the Rust
error handling ecosystem. However, this will take some additional
experimentation. For now, we want to release the `SpanTrace` type so
that other libraries and applications may use _it_ as an integration point.
We'll need to add more documentation and examples for these APIs, and
can do that in follow-up branches.
Closes#464
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Co-authored-by: Jane Lusby <jlusby@yaah.dev>
This PR fixes all reported clippy lints. In most cases I have made the
suggested changes. In a few cases (e.g., `blacklisted_name` and
`cognitive_complexity`) I've just silenced the warning.
I can make stylistic changes or discard some of the lint fixes if
preferred.
## Motivation
PR #441 increased the minimum supported Rust version, but it only
changed the Azure Pipelines CI configuration, and not the GitHub Actions
one. Additionally, upstream changes to `tower` has broken some of the
examples.
## Solution
This branch bumps the MSRV on GitHub Actions as well, and comments
out examples that depend on code broken upstream.
Additionally, it turns out that — due to Cool Cargo Semver Reasons —
it's more or less impossible to depend on both tokio 0.2.0-alpha.6 *and*
tokio 0.2 release versions. This branch therefore just drops the 0.2.0-alpha.6
support; the next `tracing-futures` will be a breaking change anyway.
Co-authored-by: David Barsky <me@davidbarsky.com>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
* futures: futures-03 & std-future is the default
Also upgrades futures-03 to the non-preview crate and
renames the `futures` feature to `futures-01`.
Fixes#418
* Update tracing-futures/CHANGELOG.md
Co-Authored-By: Eliza Weisman <eliza@buoyant.io>
* futures: Remove tokio feature from defaults
This branch introduces:
- A registry build atop of https://github.com/hawkw/sharded-slab. Layers
are expected to consume this registry through the traits `SpanData`,
`LookupSpan`, and `LookupMetadata`. Layer-specific data, such as
formatted spans and events, are stored in the `Extensions` typemap. Data
is writable via the `ExtensionsMut` view struct of the typemap. This
enables layers to read and write data that they are specifically
interested in.
- The `tracing_subscriber::fmt::Subscriber` has been re-implemented in
terms of `tracing_subscriber::registry::Registry` and
`tracing_subscriber::fmt::Layer`.
- The event/field formatters have been modified (in a non-backwards
compatible way) to accept a `tracing_subscriber::fmt::FmtContext`. A
similar structure existed in `tracing_subscriber::fmt::Subscriber`, but
it was not publicly exposed.
Resolves#135Resolves#157Resolves#391
Signed-off-by: David Barsky <me@davidbarsky.com>
Coauthored-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
I thought the boxing errors solution implemented in #400 was equivalent
to the enum solution in
f22bae5a2d,
but the current master doesn't actually work to install the global
`LogTracer`.
I can't figure out why the current cargo features don't end up turning
on [this line][1], but I confirmed with the log example in
4511325b29
that it's not currently working.
[1]: https://github.com/tokio-rs/tracing/blob/master/tracing-subscriber/src/fmt/mod.rs#L452-L453
* subscriber: use InitError enum instead of Box
the Boxing solution while using the feature tracing-log/std didn't actually seem to work
* examples: log compatibility
* fix dependencies
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
* fix boxed errors
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
* cargo fmt
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
Currently, most crates in `tracing` are configured to deny all compiler
warnings when compiling tests. This means that if the compiler reports
any warnings, the build will fail. This can be an issue when changes are
made locally that introduce warnings (i.e. unused code is added, imports
are no longer needed, etc) and a contributor wishes to test an
incomplete state to ensure their changes are on the right path. With
warnings denied, tests will not run if the project contains any
warnings, so contributors must either fix all warnings or disable the
deny attribute. Disabling the deny attribute when making changes locally
has become a fairly common practice, but it's error-prone: sometimes,
the deny attribute is commented out and then accidentally committed.
## Solution
This branch removes all `#![deny(warnings)]` attributes, in order to
allow code with warnings to compile and be tested locally while changes
are in progress. We already have [a CI job][1] that checks for compiler
warnings by trying to compile `tracing` with `RUSTFLAGS="-Dwarnings"`.
If we make this CI job required rather than allowing it to fail, we'll
still be able to ensure that no code with warnings is merged.
Additionally, I've updated all crates to use the same consistent list of
lints to apply in the `#![warn]` attribute. Previously, some crates
warned on more lints than others, which is not great. I've fixed all the
new warnings produced by the additional lints.
* chore: consistent warnings, don't deny locally
* fix warnings from new attributes
* remove warning that no longer exists on nightly
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
This branch prepares for an initial stable release of `tracing-futures`.
I've done some pre-release cleanup and docs work as well as updating
versions.
* futures: improve docs
* futures: pre-release cleanup
* futures: update futures-preview version
* futures: nicer readme/lib docs
* fix breaky path dep
* also fix examples path dep
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
