2ea0cceca5
## 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 #78 Closes #108 Signed-off-by: Eliza Weisman <eliza@buoyant.io>
tracing
Application-level tracing for Rust.
Overview
tracing is a framework for instrumenting Rust programs to collect
structured, event-based diagnostic information. tracing is maintained by the
Tokio project, but does not require the tokio runtime to be used.
Getting Help
First, see if the answer to your question can be found in the API documentation. If the answer is not there, there is an active community in the Tracing Gitter channel. We would be happy to try to answer your question. Last, if that doesn't work, try opening an issue with the question.
Contributing
🎈 Thanks for your help improving the project! We are so happy to have you! We have a contributing guide to help you get involved in the Tracing project.
Project layout
The tracing crate contains the primary instrumentation API, used for
instrumenting libraries and applications to emit trace data. The tracing-core
crate contains the core API primitives on which the rest of tracing is
instrumented. Authors of trace subscribers may depend on tracing-core, which
guarantees a higher level of stability.
Additionally, this repository contains several compatibility and utility
libraries built on top of tracing. Some of these crates are in a pre-release
state, and are less stable than the tracing and tracing-core crates.
The crates included as part of Tracing are:
-
tracing-fmt: A subscriber for formatting and logging trace events. -
tracing-futures: Utilities for instrumentingfutures(unstable). -
tracing-macros: Experimental macros for emitting trace events (unstable). -
tracing-proc-macros: Procedural macro attributes for automatically instrumenting functions (unstable). -
tracing-log: Compatibility with thelogcrate (unstable). -
tracing-env-logger: A subscriber that logs trace events using theenv_loggercrate (unstable). -
tracing-serde: A compatibility layer for serializing trace data withserde(unstable). -
tracing-subscriber: Utilities for subscriber implementations (unstable). -
tracing-tower: Compatibility with thetowerecosystem (unstable). -
tracing-tower-http:towercompatibility for HTTP services (unstable).
License
This project is licensed under the MIT license.
Contribution
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in Tracing by you, shall be licensed as MIT, without any additional terms or conditions.