## Motivation
Currently, the `tracing-log` crate represents `log` metadata as fields
on the `tracing` events it emits, rather than as `tracing` metadata.
This results in inconsistent formatting for `tracing` events versus
events generated from `log` records.
`tracing-fmt` should format the `log.module`, `log.target`, `log.file`,
and `log.line` fields the way it formats the same metadata on `tracing`
events. The output will look nicer this way.
## Solution
This branch introduces a new `NormalizeMetadata` extension trait to
`tracing-log`, which is implemented for `Event`s. When an `Event` has
fields indicating log metadata, its `normalized_metadata` method will
return a new `Metadata` with the metadata from the `log` crate
populated.
`tracing-fmt` has been updated to use this trait when support for
`tracing-log` is enabled.
Signed-off-by: Alexis Mousset <contact@amousset.me>
## Motivation
People writing libraries using tracing may wish to expose regular `log`
support via the `tracing/log` feature. At the same time, to get tracing
support for crates using `log`, users may turn to
`tracing_log::LogTracer`. Enabling both means logging events twice.
## Solution
This branch adds a `Builder` to the `tracing_log::LogTracer` type, which
allows configuring the `LogTracer` to ignore log records with targets
beginning with a certain string. This can be used to ignore any crates
which are emitting log records via the `tracing/log` feature.
Ideally, we would provide a way to do this automatically, without
requiring configuration, but that'll take some thinking. The ability to
ignore certain sets of log records may be valuable even if we have an
automatic method for crates to signal that they are using the
`tracing/log` feature in the future.
I've also moved the `LogTracer` and `TraceLogger` types in `tracing-log`
out of `lib.rs` into their own modules, since the main lib file was
getting a bit lengthy.
Refs: #204
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
This branch makes a few small README and Cargo.toml changes:
* Add Azure Pipelines build status badges to Cargo.tomls
* Change README build status badges to Azure Pipelines
* Add "maintenance: experimental" badges to unreleased crates
* Link to `tracing` docs and crates.io page in the root README,
rather than `tracing-core`.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
As we started discussing in #197, setting up level filter for log is a
bit complicated, and currently has to be done twice (not counting
optional filtering in subscriber):
* Once in `log` with `log::set_max_level`
* Once in `tracing_log` with `LogTracer::with_filter`
Both use `log::LevelFilter` and have exactly the same behavior (but a
different default level).
## Solution
This PR removes the filter in `LogTracer`, and adds a function to allow
easily setting up a logger and a filter directly from `tracing_log`.
The equivalent in the `env_logger` crate are:
```rust
pub fn try_init() -> Result<(), SetLoggerError> {
try_init_from_env(Env::default())
}
pub fn init() {
try_init().expect("env_logger::init should not be called after logger initialized");
}
```
Co-Authored-By: Eliza Weisman <eliza@buoyant.io>
## Motivation
The metadata produced for logs by `as_trace` (used for filtering), when
using `tracing-log`, have inverted file and module path fields:
```
Metadata { name: "log record", target: "tokio_reactor", level: Level(Trace),
module_path: "/.../.cargo/registry/src/github.com-.../tokio-reactor-0.1.9/src/lib.rs",
location: tokio_reactor:390, [...] }
```
## Solution
It is fixed by passing them in the right order in the `Metadata` constructor.
## Motivation
`tracing-core` 0.1.2 deprecated the `Subscriber::drop_span` function in
favour of `try_close`.
## Solution
This branch updates all other crates to depend on core 0.1.2, and
replaces uses of `drop_span` with `try_close`.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
It would be nice if `Event`s created by `tracing-log` (which are derived
from `log::Record`) include the additional metadata that `log` includes:
target, module, file, and line information. This can be used by
subscribers to print this metadata to make the events look more like
tracing events.
In fact, the static `Callsite` in `tracing-log` includes those as
fields, so I hoped this was the intended behaviour.
## Solution
This follows the same patterns as existed for adding values to the
`ValueSet` included with a dispatched event.
## Motivation
#122 updated all crates to use Rust 2018 syntax, but I neglected to add
`edition = "2018"` to the `Cargo.toml`s.
## Solution
This fixes that.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Revert "update crates to depend on core from crates.io (#113)" and let tracing-core use tracing from crates.io
This reverts commit 1c6b4388d49aa3202ae39fd396500677cb3c5730.
This branch updates `tracing`, `tracing-fmt`, and `tracing-log`
to depend on `tracing-core` 0.1 from crates.io.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
Currently, the `span::Attributes` type in `tokio-trace-core` contains a
reference to `Metadata` with a generic lifetime `'a`. This means that if
a `Subscriber` wishes to store span metadata, it cannot simply store a
`&'static Metadata<'static>`. Instead, it must extract the individual
components from the metadata and store them in its own structure. In
addition, while the `name` and `FieldSet` in a `Metadata` are always
`'static`, the target and file path are not. If the `Subscriber` needs
to store those values, they must be cloned into a `String` on the heap.
This is somewhat unergonomic for subscriber implementors, in comparison
to being able to use a `&'static Metadata<'static>` reference. In
addition, it implies additional overhead when using certain parts of a
span's metadata.
## Solution
This branch changes the `Metadata` fields in `Event` and `Attributes` to
be `'static`, and `Subscriber::register_callsite` to take an
`&'static Metadata<'static>`. Unlike PR #108, this branch leaves
`Metadata` generic over a lifetime, and `Subscriber::enabled` takes an
`&'a Metadata<'a>`.
Since subscribers are provided all span metadata as a static reference
in both `register_callsite` and `new_span`, they can clone _those_
static references, but `Subscriber::enabled` can still be called with
`Metadata` constructed from a `log::Record`. This means that log records
can still be filtered as normal. A different callsite, which does not
have metadata from the log record, is used when actually recording
events constructed from `log::Records`; in a follow-up, we can propagate
the log metadata as fields there.
Closes#78Closes#108
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
PR #106 broke some APIs that the nursery crates `tracing-fmt` and
`tracing-log` depended on. At the time, we didn't catch this, as those
crates still depended on `tokio-trace`/`tokio-trace-core` from
crates.io. However, after merging #101, which updated those crates to
use path dependencies on `tracing`/`tracing-core`, those crates broke.
## Solution
This branch updates `tracing-fmt` and `tracing-log` to compile with the
changed APIs. `tracing-log` was also changed to depend on `tracing-core`
rather than `tracing`, as only the `core API is required by that crate,
and the `identify_callsite!` macro is not publically re-exported by
`tracing`.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
This branch updates the "nursery" crates to depend on `tracing` and
`tracing-core` as path dependencies, rather than depending on the
crates.io releases of `tokio-trace` and `tokio-trace-core`. When
`tracing` and `tracing-core` are released, we will change these from
path dependencies to crates.io dependencies.
This branch also updates those crates to track API changes in `tracing`
and `tracing-core`.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
See #95
This branch renames everything from `tokio-trace` to `tracing`.
Unlike PR #98, the nursery crates still depend on the crates.io
versions of `tokio-trace` and `tokio-trace-core`, but renamed
to `tracing`/`tracing-core` in `Cargo.toml`. We can update the
nursery crates to depend on local path dependencies in a
subsequent PR, as that will require making code changes to the
nursery crates.
This branch _also_ updates the minimum Rust version to 1.34.0,
to the shock and horror of the millions of `tracing` users still
on Rust 1.26.0. This was necessary in order to allow renaming
crates in `Cargo.toml`, and to resolve that not using the `dyn`
keyword is now a warning on nightly.
Closes#98Closes#95
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
