We had some broken link formatting in the `tracing-journald` docs which
clippy picked up (the text looked like a link definition, but wasn't
meant to be).
The incorrect links have now been corrected. They have to link to the
`tracing-core` crate because `tracing-journald` doesn't depend on
`tracing` directly.
Fixes for a broken link in the `tracing-subscriber` main page and
correcting the link to `Collect` from `tracing-log` (which also doesn't
depend on `tracing` directly) were also included.
This allows to manually map tracing levels to journald levels.
It seems that @little-dude, who started the original PR, doesn't have
time to finish this, so I picked it up. Reapplied the changes to the
newest master branch and fixed the latest comments/issues.
This will also fix/close:
Closes#2649Closes#2661Closes#2347 (the original pr)
The latest Clippy emits warnings for uses of `unwrap_or_else` with
functions that return a type's `Default::default` value, such as
`.unwrap_or_else(String::new)`. Clippy would prefer us to use
`unwrap_or_default` instead, which does the same thing.
This commit fixes the lint. Personally, I don't really care about this,
but it makes the warning go away...
## Motivation
It's currently not possible to customize how messages will get send to journald.
This became apparent in #2425, where first a specific API got designed, but then
it was decided that users should not get restricted in only a subset of fields,
but should be able to simply choose by themselves what fields get set with what
values.
So in a sense, this is the successor/rework of #2425.
## Solution
Allow custom fields to be set in tracing-journald.
## Open Questions
- [x] How should we deal with fields that also get supplied by other options?
For example, setting `SYSLOG_IDENTIFIER` here and also setting
`.with_syslog_identifier()` will send said field twice, potentially with
differing values. Is that a problem?
- Answer: No, this is not a problem.
Closes#2425
As part of upgrading syn to 2.0 (e.g.,
https://github.com/tokio-rs/tracing/pull/2516), we need to bump the MSRV
to 1.56. As part of this PR, I've:
- Updated the text descriptions of what would be an in-policy MSRV bump
to use more recent versions of rustc. The _niceness_ of said version
numbers are purely coincidental.
- I've removed some of the exceptions made in CI.yml in order to support
some crates with a higher MSRV.
## Motivation
Fix minimal-versions failure.
## Solution
Upgrade all the dependencies to their most recent semver-compatible
version, adjusting back down as necessary for MSRV.
## Context
[cargo-minimal-versions](https://lib.rs/crates/cargo-minimal-versions)
is wonderful. With this PR, the full repo passes under all of
- `cargo hack --workspace minimal-versions check --all-features`
- `cargo +1.49 hack --workspace --exclude tracing-appender
minimal-versions check --all-features`
- `cargo +1.53 hack -p tracing-appender minimal-versions check
--all-features`
- All of CI 😇
## Motivation
Closes#1465.
## Solution
I'm just disabling the default features of `tracing-journald`'s
dependency on `tracing-subscriber`. The original issue talked about the
crate's dependencies more broadly but considering that the standard
library is already depended upon I didn't think it made sense to change
the `tracing-core` dependency's features (which are just `no_std`
support).
## Motivation
Currently, `tracing-journald` prefixes event fields with the number
of parent spans, if present, in order to namespace field values. This
turned out to be unnecessary as journald preserves values for duplicated
field names.
## Solution
This branch removes event field prefixes and emits parent span names
and their field/value pairs as additional key/value pairs.
On 32 bit targets (e.g. armv7) the syscall in memfd_create_syscall()
returns an i32, so this compilation error is printed:
| error[E0308]: mismatched types
| --> .../tracing-journald-0.2.3/src/memfd.rs:27:9
| |
| 25 | fn memfd_create_syscall(flags: c_uint) -> i64 {
| | --- expected `i64`
| | because of return type
| 26 | unsafe {
| 27 | / syscall(
| 28 | | SYS_memfd_create,
| 29 | | "tracing-journald\0".as_ptr() as *const c_char,
| 30 | | flags,
| 31 | | )
| | |_________^ expected `i64`, found `i32`
| |
| help: you can convert an `i32` to an `i64`
| |
| 31 | ).into()
| | +++++++
|
| For more information about this error, try `rustc --explain E0308`.
| error: could not compile `tracing-journald` due to previous error
|
This commit fixes this issue.
Fixes#1879
## Motivation
`journald-tracing>=0.2.1` doesn't build with old glibc.
## Solution
Make the `memfd_create` syscall ourselves.
cc @lunaryorn @Ralith
This updates all crates' MSRVs to 1.49 if they were not already greater
than that (`tracing-appender` is at 1.53). Rust 1.49+ is required to
update `parking_lot` to v0.12 (see #1878). Also, `futures-task` (which I
believe is only needed as a transitive dep) now needs 1.45+, so this
also fixes our CI build.
Because `tracing-opentelemetry` previously required 1.46.0, it had a
separate CI MSRV job. Since 1.49.0 is greater than 1.46.0, the separate
check for `tracing-opentelemetry` is no longer needed.
In the process, I removed deprecated uses of
`core::atomic::spin_loop_hint`, which is replaced with
`core::hint::spin_loop` in 1.49.
Set the `SYSLOG_IDENTIFIER` field on all events. I noticed that the
subscriber didn't do this so far.
## Motivation
The identifier is used with `journalctl -t`, and while it's normally
better to filter by unit with `journalctl -u` the identifier is still
nice for processes that are not started through systemd units.
Upstream does this as well, see [here]:
`program_invocation_short_name` is a glibc variable which holds the file
name of the current executable; I tried to replicate this behaviour in
Rust.
## Solution
Add a syslog identifier field to the subscriber, defaulting to the
filename of the current executable, and write this value as
`SYSLOG_IDENTIFIER` with every event. It's not written for spans, because
it's a global value and inevitably the same for each span.
[here]: 81218ac1e1/src/libsystemd/sd-journal/journal-send.c (L270)
Lets journald subscribers survive a journald restart.
Closes#1745
## Motivation
Currently the journald subscriber immediately connects to the journald
socket. As such I understand it'd not survive a full restart of
journald.
## Solution
Do not connect the client socket immediately; instead pass the socket
pathname every time we send a message. This is also what upstream does.
See #1698: Properly write large payloads to journal.
I'd appreciate a very careful review; this cmsg stuff is nasty, and
while it's well documented in `cmsg(3)` I had to fiddle a bit because
the corresponding functions in libc aren't const and thus don't permit a
direct allocation of the buffer as most `cmsg` C code around does.
Closes#1698
## Motivation
Linux limits the maximum amount of data permitted for a single Unix
datagram; sending large payloads directly will fail.
## Solution
Follow systemd.io/JOURNAL_NATIVE_PROTOCOL/ and check for `EMSGSIZE` from
`send()`; in this case write the payload to a memfd, seal it, and pass
it on to journald via a corresponding SCM_RIGHTS control message.
Per discussion in #1698 this adds no dependency on `nix`, and instead
implements fd forwarding directly with some bits of unsafe `libc` code.
See #1710: Do not write strings in Debug representation.
## Motivation
As discussed in #1710 writing strings literally makes tracing-journald
behave like other journal clients, and allows 3rd party journal readers
to extract the original value from the journal without having to
"un"-parse the Debug representation of Rust strings.
Fixes#1710.
Per discussion with @hawkw in #1698 I'm adding a few simple integration
tests for the journald subscriber, to have some safety net when
implementing the actual issue in #1698.
These tests send messages of various complexity to the journal, and then
use `journalctl`'s JSON output to get them back out, to check whether
the message arrives in the systemd journal as it was intended to.
## Motivation
Increase test coverage for the journald subscriber and codify a known
good state before approaching a fix for #1698.
Forward-port of #1431 and #1434
* subscriber: unify span traversal (#1431)
## Motivation
Fixes#1429 (forwardport from v0.1.x branch)
## Solution
Implemented as described in #1429, and migrated all internal uses of the
deprecated methods. All tests passed both before and after the migration
(9ec8130).
- Add a new method `SpanRef::scope(&self)` that returns a leaf-to-root
`Iterator`, including the specified leaf
- Add a new method `Scope::from_root(self)` (where `Scope` is the type
returned by `SpanRef::scope` defined earlier) that returns a
root-to-leaf `Iterator` that ends at the current leaf (in other
words: it's essentially the same as
`Scope::collect::<Vec<_>>().into_iter().rev()`)
- Deprecate all existing iterators, since they can be replaced by the
new unified mechanism:
- `Span::parents` is equivalent to `Span::scope().skip(1)` (although
the `skip` is typically a bug)
- `Span::from_root` is equivalent to `Span::scope().skip(1).from_root()`
(although the `skip` is typically a bug)
- `Context::scope` is equivalent to
`Context::lookup_current().scope().from_root()` (although the
`lookup_current` is sometimes a bug, see also #1428)
* subscriber: add Context method for resolving an Event's SpanRef (#1434)
## Motivation
Fixes#1428 (forward-port from v0.1.x)
## Solution
Adds a new `Context::event_span` method as proposed in the issue.
No existing formatters were changed to use it yet, that seems like a
secondary issue (especially if they already work correctly).
## Motivation
#940
## Solution
This changes the docs.rs links, many of which were broken (or would have
been broken on the next release). It also converts some links I missed
the first time (maybe they were added after I opened the PR?).
This PR renames the following:
- `tracing_core::Subscriber` to `tracing_core::Collect`
- `tracing_subscriber::layer::Layer` to `tracing_subscriber::layer::Subscribe`
Authored-by: David Barsksy <dbarsky@amazon.com>
Co-authored-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
This will avoid breaking CI on new releases of clippy. It also makes the
code a little easier to read.
## Solution
- Convert `match val { pat => true, _ => false }` to `matches!(val, pat)`
- Remove unnecessary closures
- Convert `self: &mut Self` to `&mut self`
This bumps the MSRV to 1.42.0 for `matches!`.
The latest version of rust is 1.46.0, so as per
https://github.com/tokio-rs/tracing#supported-rust-versions this is not
considered a breaking change.
I didn't fix the following warning because the fix was not trivial/needed
a decision:
```
warning: you are deriving `Ord` but have implemented `PartialOrd` explicitly
--> tracing-subscriber/src/filter/env/field.rs:16:32
|
16 | #[derive(Debug, Eq, PartialEq, Ord)]
| ^^^
|
= note: `#[warn(clippy::derive_ord_xor_partial_ord)]` on by default
note: `PartialOrd` implemented here
--> tracing-subscriber/src/filter/env/field.rs:98:1
|
98 | / impl PartialOrd for Match {
99 | | fn partial_cmp(&self, other: &Self) -> Option<Ordering> {
100 | | // Ordering for `Match` directives is based first on _whether_ a value
101 | | // is matched or not. This is semantically meaningful --- we would
... |
121 | | }
122 | | }
| |_^
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#derive_ord_xor_partial_ord
```
As a side note, this found a bug in clippy 😆https://github.com/rust-lang/rust-clippy/issues/6089
This branch updates all crate versions to 0.2.x. After this PR merges,
we can now develop `tracing`/`tracing-core` v0.2.x on `master`.
There is now a separate, protected `v0.1.x` branch. Changes backported
to 0.1 versions of `tracing` crates can be merged to that branch.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
In order to get a compiler warning (or error) when links are broken.
Closes#940
## Solution
- [x] add `deny(broken_intra_doc_links)`
- [x] add a note to the CONTRIBUTING.md documentation on building docs locally
Co-authored-by: Eliza Weisman <eliza@buoyant.io>
Co-authored-by: Joshua Nelson <joshua@yottadb.com>
This changes the logo to a wordmark. This should be consistent
with the ones for all the other Tokio crates, when we add them
elsewhere.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
PR #934 fixed a bug in the CI configuration where MSRV checks were not
being run correctly. After this was fixed, it was necessary to bump the
MSRV to 1.40.0, as the tests were no longer actually passing on 1.39,
because some dependencies no longer support it.
While updating the documentation to indicate that the new MSRV is 1.40,
I noticed that the note on the MSRV was located inconsistently in the
READMEs and `lib.rs` documentation of various crates, and missing
entirely in some cases. Additionally, there have been some questions on
what our MSRV _policies_ are, and whether MSRV bumps are considered
breaking changes (see e.g. #936).
## Solution
I've updated all the MSRV notes in the documentation and READMEs to
indicate that the MSRV is 1.40. I've also ensured that the MSRV note is
in the same place for every crate (at the end of the "Overview" section
in the docs), and that it's formatted consistently.
Furthermore, I added a new section to the READMEs and `lib.rs` docs
explaining the current MSRV policy in some detail. Hopefully, this
should answer questions like #936 in the future. The MSRV note in the
overview section includes a link to the section with further details.
Finally, while doing this, I noticed a couple of crates
(`tracing-journald` and `tracing-serde`) were missing top-level `lib.rs`
docs. Rather than just adding an MSRV note and nothing else, I went
ahead and fixed this using documentation from those crate's READMEs.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
This puts the splash SVG in every crate's README, so
that it will be rendered on crates.io.
I also changed the link to an absolute URL, to ensure that
it works even outside of the repo.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
The MIT license states:
> The above copyright notice and this permission notice
> shall be included in all copies or substantial portions
> of the Software.
## Solution
Therefore the LICENSE files should be present in each crate directory,
so they are included with `cargo publish`.
Now that the new https://tokio.rs is live, we can add the new Tracing
logo to the RustDoc!
I also added a couple missing `html_root_url` attributes in published
crates.
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
