## Motivation
Optional inactivity tracking should have minimal overhead when disabled.
## Solution
Check to see if inactivity tracking is enabled before doing more
expensive operations. Performance improvement of ~6% using current
benchmarks.
* Address comments and switch to i64 timing values
Authored-by: Julian Tescher
Co-authored-by: Eliza Weisman <eliza@buoyant.io>
This backports #1322 from `master` to `v0.1.x`,
* opentelemetry: support otel 0.13.0
Switches to `Cow<'static, str>` for otel event names and updates docs to
show simplified install methods.
* Add simple vs batch comment
Co-authored-by: Julian Tescher <jatescher@gmail.com>
Co-authored-by: Eliza Weisman <eliza@buoyant.io>
This patch resolves the field value capitalization ambiguity currently
in `otel.kind` by instead recommending an enum value. This also brings
type safety to the value, further reducing the risk of typos and other
misuse.
Resolves#1209
## Motivation
Support the latest OpenTelemetry specification
## Solution
In order to support the latest spec, this patch makes the following
breaking API changes:
* Update `opentelemetry` to 0.11.x
* Update `OpenTelemetrySpanExt::set_parent` to take a context by value
as it is now stored and propagated.
* Rename `PreSampledTracer::sampled_span_context` to
`PreSampledTracer::sampled_context` as it now returns a full otel
context
Additionally the following doc and example changes:
* Show w3c trace context propagator as recommendation in examples
This backports #1049, which was already approved on master.
## Motivation
Support the latest OpenTelemetry specification
## Solution
In order to support the latest spec, this patch makes the following
breaking API changes:
* Update `opentelemetry` to 0.10.x
* Update `CompatSpan` to reflect changes to `Span` trait
* Record `u64` values as strings as they are no longer supported in
OpenTelemetry.
Additionally the following non-public api, doc, and example changes:
* Update examples and docs to use new simplified pipeline builder.
* As `opentelemetry::api` no longer exports trace types, internally use
`opentelemetry::trace as otel` to disambiguate from tracing types.
* Remove `rand` dependency as it is no longer needed
Co-authored-by: Eliza Weisman <eliza@buoyant.io>
# Conflicts:
# examples/examples/opentelemetry-remote-context.rs
# tracing-opentelemetry/Cargo.toml
# tracing-opentelemetry/src/layer.rs
# tracing-opentelemetry/src/span_ext.rs
# tracing-opentelemetry/src/tracer.rs
## Motivation
It is currently possible to create a span graph which includes a span
that has both an invalid parent otel context _and_ a missing trace id by
assigning an invalid extracted parent context to a non-root span.
Constructing this particular graph will currently cause a panic.
## Solution
Explicitly assign invalid trace / span ids when sampling using the otel
SDK if the span builder does not contain these values.
This backports PR #991 to v0.1.x. This is primarily necessary for the MSRV
bump, since some dependencies no longer compile on Rust 1.40.0.
This has already been approved on `master`, in PR #991, so it should be
fine to ship.
## 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 backports #1007 to v0.1.x.
## Motivation
While using `tracing-opentelemetry` I noticed all the data gets sent to the
collector as a string. This implements the additional data types and (possibly)
saves bandwidth.
## Solution
I just implemented additional `fn record_$type(...)` methods of the
`field::Visit` trait to `SpanEventVisitor` and `SpanAttributeVisitor`.
(cherry picked from commit 04bbb15d3a4c0f74027312b8951484807ca22d48)
## 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>
## Motivation
Currently the `OpenTelemetryLayer` is coupled to the opentelemetry SDK
in a way that makes using alternate API implementations difficult (they
would have to use the SDK's sampler and id generator) as well as causing
duplication when specifying sampler configuration (it must currently be
set on both the tracer provider configuration as well as the layer
configuration, which is difficult to remember to keep in sync).
## Solution
This change creates an interface for working with pre-sampled tracers,
and implements it for the current opentelemetry SDK. This simplifies the
layer as it no longer needs to track an id generator or sampler, and
allows other otel API implementations to implement the trait rather than
rely on the current SDK.
Co-authored-by: Eliza Weisman <eliza@buoyant.io>
## Motivation
There are cases where an `opentelemetry` span will be created before a
`tracing` span (e.g. some server middleware). In this case it would be
helpful for `tracing-opentelemetry` to connect generated spans to the
existing trace rather than starting a new trace.
## Solution
If a parent trace id does not exist, check the current otel context and
only generate a new trace id if no valid id is found.
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>
OpenTelemetry supports a span kind as special metadata to spans. The
span kind defines relationships between spans (e.g. server vs client).
Some distributed tracing providers use this information to enrich their
UIs.
This makes it possible to set the span kind by adding a special
attribute called `otel.kind`, similar to the existing `otel.name`.
## 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
Currently, when converting `log::Record`s to `tracing::Event`s using
`tracing-log`, data from `log`'s metadata is converted to special fields
prefixed with `log.`, rather than being recorded as `tracing` metadata.
In order to properly display this data from `log`, the `tracing-log`
crate provides the [`NormalizeMetadata`
trait](https://docs.rs/tracing-log/0.1.1/tracing_log/trait.NormalizeEvent.html).
`tracing-opentelemetry` does not currently use this, however, and
location data from `log` events is treated as a regular field rather
than a source code location in OpenTelemetry logs.
## Solution
Update `tracing-opentelemetry`'s `on_event` implementation to format
recorded logs similarly to how `tracing-subscriber::fmt` does. Event
metadata is normalized and intermediate `log.` prefixed values are
properly ignored. This is flagged under a new `tracing-log` feature that
is enabled by default but allows for opting-out.
opentelemetry: Add dynamic span name field
## Motivation
The OpenTelemetry [spec for HTTP server
request](https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/trace/semantic_conventions/http.md#http-server-semantic-conventions)
span names states that:
> Given an inbound request for a route (e.g. "/users/:userID?") the name
> attribute of the span SHOULD be set to this route. If the route does not
> include the application root, it SHOULD be prepended to the span name.
However, `tracing` span names must be `'static`, so it is currently not
always possible to add this dynamic information.
## Solution
This patch adds support for setting OpenTelemetry span names by
specifying a field named `otel.name` for a given span.
Resolves#720
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>
