## Motivation
I was checking the example from `/examples/` and saw that
some of the module names were incorrect in README, so I
fixed them.
## Solution
Changed the incorrect name to the correct name.
This PR removes tracing-opentelemetry to a dedicated repo located at
https://github.com/tokio-rs/tracing-opentelemetry. (Note that at time of
writing this PR, the new repo has not be made public). We're moving
tracing-opentelemetry to a dedicated repository for the following
reasons:
1. opentelemetry's MSRV is higher than that of `tracing`'s.
2. more importantly, the main `tracing` repo is getting a bit unweildy
and it feels unreasonable to maintain backports for crates that
integrate with the larger tracing ecosystem.
(https://github.com/tokio-rs/tracing-opentelemetry does not have the
examples present in this repo; this will occur in a PR that will be
linked from _this_ PR.)
## Motivation
Currently, the RustDoc for the `format::Compact` formatter in
`tracing-subscriber` describes the output from the `master` (v0.2.x)
version of the formatter, not the version on the v0.1.x branch.
## Solution
This PR updates the documentation to describe the actual output format.
Also, I added an example of the formatter in the `examples` directory.
Closes#1909
## Motivation
Logging line numbers and file names can be useful for debugging. This
feature was suggested by #1326
## Solution
As per @hawkw's suggestions, fields were added on `Format`, along with
builder methods. Filename and line number information was gathered from
the `meta` variable.
The `Pretty` formatter already supports printing source locations, but
this is configured separately on the `Pretty` formatter rather than on
the `Format` type. This branch also changes `Pretty` to honor the
`Format`-level configurations and deprecates the `Pretty`-specific
method.
Fixes#1326Closes#1804
Co-authored-by: David Barsky <me@davidbarsky.com>
Co-authored-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
Fixes#894
## Solution
This PR implements Layer for Option, allowing users to wrap a Layer with
an Option, allowing it to be passed internally wherever Layer is used
there by allowing by allowing layers to be enabled or disabled.
Using this with `reload` further allows a Layer to be dynamically
toggled based by using `handle.modify`
This PR also consists of a basic example.
Signed-off-by: Tarun Pothulapati <tarunpothulapati@outlook.com>
## 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>
## 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
* 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>
## Motivation
Currently, most crates in this repository have `examples` directories
that contain demonstrations of how to use that crate. In many cases,
these examples also use APIs from _other_ crates in this repository ---
for example, the `tracing-subscriber` `FmtSubscriber` is used by many
examples to format the output generated by instrumentation APIs, so that
users can see the generated output.
The disadvantage to this approach is that it requires crates in this
repository to have dev-dependencies on each other. This is problematic
for a few reasons:
* It makes it easy to inadvertently create cyclic dependencies between
`tracing` crates.
* When building a crate that depends on a crate with dev-dependencies,
those dev-dependencies are downloaded and compiled, despite not being
linked into the dependent crate. This means that users depending on a
tracing crate will pull in a larger dependency tree, since the
dev-dependencies used by examples are also downloaded, although they
are not required by the dependent. This makes the tracing crate
appear to be a much larger dependency than it actually is, and can
make users' build times slower.
* Finally, it means that the examples are scattered throughout the
repository. In some cases, the examples demonstrate the functionality
of multiple crates, but only live in one crate's `examples` dir. This
can hurt the discoverability of the examples, especially for new
users.
## Solution
This branch moves all the examples out of individual crates and into a
new `examples` crate (which is otherwise empty and cannot be published
to crates.io). The `examples` crate is part of the root `tracing`
workspace, so it's still possible to `cargo run --example WHATEVER`.
Similarly, `cargo test --all` will still build the examples.
All dev-dependencies which were only required by examples and not tests
have been removed, which has a drastic impact on the dependency
footprint of some crates.
Finally, I've added a README to the `examples` crate, listing the
available examples and what functionality they demonstrate.
Refs: #315, #308
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
