## Motivation
This fixes a discrepancy in the `tracing-opentelemetry` docs for the new
MetricsLayer. The docs refer to `value.` as a way to collect discrete
data point, but this doesn't match any of the prefix constant mentioned
in the same file.
```rust
const METRIC_PREFIX_MONOTONIC_COUNTER: &str = "monotonic_counter.";
const METRIC_PREFIX_COUNTER: &str = "counter.";
const METRIC_PREFIX_HISTOGRAM: &str = "histogram.";
```
## Solution
This fixes the documentation and test by referring to `histogram.`
instead of `value.`.
One can want to have an event added from outside context of a span,
especially in an async code (e.g. between polls of the future, or
between polling multiple futures instrumented with that span). Then it
is expected that the event will be attached indeed to the span specified
as the parent and not the contextual one.
Fixes: #2295
See #2295
## Motivation
Support the latest OpenTelemetry specification.
## Solution
Update `opentelemetry` to the latest `0.18.x` release. Breaking changes
in the metrics spec have removed value recorders and added histograms so
the metrics layer's `value.` prefix has been changed to `histogram.` and
behaves accordingly. Additionally the `PushController` configuration for
the metrics layer has been simplified to accept a `BasicController` that
can act in either push or pull modes. Finally trace sampling in the
sdk's `PreSampledTracer` impl has been updated to match the sampling
logic in https://github.com/open-telemetry/opentelemetry-rust/pull/839.
* Update MSRV to 1.56
* Update examples
* Fix async-trait dep
* Update msrv action
Co-authored-by: Eliza Weisman <eliza@buoyant.io>
In the upstream `opentelemetry` crate, the `trace` and `metrics`
features are gated by separate feature flags. This allows users who are
only using OpenTelemetry for tracing, or who are only using it for
metrics, to pick and choose what they depend on.
Currently, the release version of `tracing-opentelemetry` only provides
tracing functionality, and therefore, it only depends on `opentelemetry`
with the `trace` feature enabled. However, the metrics support added in
#2185 adds a dependency on the `opentelemetry/metrics` feature. This is
currently always enabled. We should probably follow the same approach as
upstream `opentelemetry`, and allow enabling/disabling metrics and
tracing separately.
This branch adds a `metrics` feature to `tracing-opentelemetry`, and
makes the `MetricsLayer` from #2185 gated on the `metrics` feature.
This feature flag is on by default, like the upstream
`opentelemetry/metrics` feature, but it can be disabled using
`default-features = false`.
We should probably do something similar for the tracing components of
the crate, and make them gated on a `trace` feature flag, but adding a
feature flag to released APIs is not semver-compatible, so we should
save that until the next breaking release.
Motivation:
Currently, there is no way to publish metrics via tracing.
Solution:
Update the tracing-opentelemetry crate to publish metrics for event
fields that contain specific prefixes in the name.
Right now, we lazily instantiate and store one metrics object
per-callsite, but a future improvement that we should add to tracing
itself is the ability to store data per-callsite, so that we don't have
to do a HashMap lookup each time we want to publish a metric.
Co-authored-by: Eliza Weisman <eliza@buoyant.io>
Co-authored-by: David Barsky <me@davidbarsky.com>
## Motivation
Fix minimal-versions failure.
## Solution
Upgrade all the dependencies to their most recent semver-compatible
version, adjusting back down as necessary for MSRV.
Essentially a cherry-pick of #2231, but redone by hand.
## Tests
- `cargo minimal-versions msrv verify -- cargo check --all-features`
- `cargo minimal-versions msrv verify -- cargo check --no-default-features`
## Methodology
- `cargo update && cargo upgrade --to-lockfile`
- Identify [a bug](https://github.com/killercup/cargo-edit/issues/750) and manually resolve it
- loop; upgrade transitive deps
- `cargo minimal-versions check --all-features`
- Identify failing dep
- `cargo minimal-versions tree -i dep --all-features`
- Find the closest dependency leading to pulling in `dep`
- `cargo add fixdep --optional` to force a more recent more-minimal-versions-correct version
- loop; downgrade to msrv
- `cargo minimal-versions msrv verify -- cargo check --all-features`
- Identify failing dep
- `cargo minimal-versions tree -i dep --all-features`
- Find the version that supports MSRV from lib.rs
- `cargo upgrade dep@msrv`
# 0.17.4 (July 1, 2022)
This release adds optional support for recording `std::error::Error`s
using OpenTelemetry's [semantic conventions for exceptions][exn-semconv].
### Added
- `Layer::with_exception_fields` to enable emitting `exception.message`
and `exception.backtrace` semantic-convention fields when an `Error`
is recorded as a span or event field ([#2135])
- `Layer::with_exception_field_propagation` to enable setting
`exception.message` and `exception.backtrace` semantic-convention
fields on the current span when an event with an `Error` field is
recorded ([#2135])
Thanks to @lilymara-onesignal for contributing to this release!
[thread-semconv]: https://opentelemetry.io/docs/reference/specification/trace/semantic_conventions/exceptions/
[#2135]: https://github.com/tokio-rs/tracing/pull/2135
## Motivation
Currently, the `tracing-opentelemetry` docs indicate that the support
for OpenTelemetry's exception semantic conventions added in #2135 is
enabled by default. However, this is not the case --- this feature was
changed to opt-in rather than opt-out prior to merging PR #2135.
## Solution
This branch updates the docs to state that these features are disabled
by default, rather than enabled by default.
This fixes a Clippy lint for explicitly calling `drop` on a value
without a `Drop` impl, and a lint for `let` bindings whose
value is `()`.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
When an error value is recorded, it should add the `exception.message` and
`exception.stacktrace` fields from the opentelemetry semantic conventions to the
span/event. Ideally the `exception.type` field would be provided also, but there
is currently not a mechanism to determine the type name of a trait object.
# 0.17.3 (June 7, 2022)
This release adds support for emitting thread names and IDs to
OpenTelemetry, as well as recording `std::error::Error` values in a
structured manner with their source chain included. Additionally, this
release fixes issues related to event and span source code locations.
### Added
- `Layer::with_threads` to enable recording thread names/IDs according
to [OpenTelemetry semantic conventions][thread-semconv] ([#2134])
- `Error::source` chain when recording `std::error::Error` values
([#2122])
- `Layer::with_location` method (replaces `Layer::with_event_location`)
([#2124])
### Changed
- `std::error::Error` values are now recorded using `fmt::Display`
rather than `fmt::Debug` ([#2122])
### Fixed
- Fixed event source code locations overwriting the parent span's source
location ([#2099])
- Fixed `Layer::with_event_location` not controlling whether locations
are emitted for spans as well as events ([#2124])
### Deprecated
- `Layer::with_event_location`: renamed to `Layer::with_location`, as it
now controls both span and event locations ([#2124])
Thanks to new contributors @lilymara-onesignal, @hubertbudzynski,
and @DevinCarr for contributing to this release!
[thread-semconv]: https://opentelemetry.io/docs/reference/specification/trace/semantic_conventions/span-general/#source-code-attributes
[#2134]: https://github.com/tokio-rs/tracing/pull/2134
[#2122]: https://github.com/tokio-rs/tracing/pull/2122
[#2124]: https://github.com/tokio-rs/tracing/pull/2124
[#2099]: https://github.com/tokio-rs/tracing/pull/2099
Previously error values were recorded using their `Debug`
representation. They are now reported with their `Display`
implementation. This is more in line with current best practices for
error handling.
This is a change in how error values are recorded in the opentelemetry
adapter. For a given field `x` that contains an error type, record an
additional dynamic field `x.chain` that contains an array of all errors
in the source chain. This allows users to determine where a high-level
error originated.
## Motivation
Rust's `Error` type includes a `source` method which allows library
authors to compose errors on top of one another in a way that indicates
how errors originated down to the OS level. Surfacing this information
to the users will allow them to determine why errors are occurring with
more detail.
## Solution
Walking the `source` chain until there are no errors left and storing
this at a new field called `{fieldname}.chain` allows operators to
determine the causal chain of complex errors.
The example code for `tracing-opentelemetry` in the README.md file was based on
older versions of `tracing`, `tracing-opentelemetry` and `opentelemetry`. It
did not compile with the latest versions of these crates.
## Motivation
Developers should be able to copy/paste example code and it should work.
## Solution
Following some type renames allows this code to work.
This is @lilymara-onesignal's branch #1414 but rebased to point at the
`v0.1.x` branch as the base. I think we will also want to update the use
of the otel APIs on `master`, but `master` currently uses the correct
`tracing` type names _for v0.2.x_.
Co-authored-by: Lily Mara <lilymara@onesignal.com>
Closes#1414
* docs: `cargo intraconv` for more intra-doc links
... also it deleted some redundant ones, and it got some things wrong,
and it was gonna delete some of the cross-crate docs.rs links we can't
do as intra-doc links so I passed `--no-favored`.
* docs: convert https:// links to std/core/alloc to intra-doc links
Note that this adds some more broken intra doc links when building
without std support, but that was already a thing and I expect people
who build their own docs without std support can handle it.
This time I gave up on sed and used ruby.
find -name '*.rs' -exec ruby -i -p blah.rb {} +
with
$_.gsub!(%r{
https://doc\.rust-lang\.org/
(?: stable/)?
((?:core | std | alloc)(?:/\S+?)*)
/(\w+)\.(\w+)\.html}x
) {
path, kind, name = $~.captures
suffix = case kind
when 'method' then '()'
when 'macro' then '!'
else ''
end
r = [path.gsub('/', '::'), '::', name, suffix].join
STDERR.puts [path, kind, name, suffix, r].inspect
r
}
$_.gsub!(%r{
https://doc\.rust-lang\.org/
(?: stable/)?
((?: core | std | alloc)(?:/\S+?)*)
/(?:
index\.html
| $
| (?= \#)
)}x
) {
path, _ = $~.captures
r = path.gsub('/', '::')
STDERR.puts [path, r].inspect
r
}
* docs: more cross-crate intra-doc links
cargo intraconv doesn't seem to get them reliably and also plenty of
links to other crates aren't actually intra-doc because they're in
crates that don't depend (or only dev-depend, or only conditionally
depend) on those crates, so this wasn't very automated.
I tried to only convert docs.rs links to unconditional dependencies to
intra-crate links, but it's possible that some slipped through in either
direction.
## Motivation
Currently, `tracing-opentelemetry` v0.17.1 fails to compile with
`default-features = false`. This is because there's a `let` binding for
`normalized_metadata` with a `None` where the `Some` type can't be
inferred. This managed to slip past CI and get released because we were
never actually building the crate with its default features disabled, an
oversight in our CI configuration.
## Solution
This branch fixes the issue by adding an explicit type annotation to the
`let` binding, so the `Option`'s type is known and the type error no
longer occurs. I also removed a feature-flagged import that was not
actually used.
I also added `tracing-opentelemetry` to the `cargo hack` CI job. This
way, we will now ensure that all its feature combinations are built on
CI (including no features), which should prevent this kind of thing from
occurring in the future. Without the fix, we can confirm that this job does
fail: https://github.com/tokio-rs/tracing/runs/5279139893?check_suite_focus=true
Fixes #1944
# 0.17.1 (February 11, 2022)
### Added
- `OpenTelemetryLayer` can now add detailed location information to
forwarded events (defaults to on) ([#1911])
- `OpenTelemetryLayer::with_event_location` to control whether source
locations are recorded ([#1911])
### Changed
- Avoid unnecessary allocations to improve performance when recording
events ([#1917])
Thanks to @djc for contributing to this release!
[#1917]: https://github.com/tokio-rs/tracing/pull/1917
[#1911]: https://github.com/tokio-rs/tracing/pull/1911Closes#1919
## Motivation
Currently, the `tracing-opentelemetry` subscriber will allocate several
strings for opentelemetry key-value fields in its `on_event`
implementation. Some of these allocations are not necessary, since
`opentelemetry::Value::String` can take a `Cow`, allowing `&'static str`s
to be used without allocating a new `String`.
Since this happens for _every_ event that's recorded to opentelemetry,
this probably has a meaningful performance impact.
## Solution
This branch makes two primary changes:
+ Change the `on_event` method to subscriber to use `&'static str`s for
event targets when possible, similarly to how we did this for source
locations in #1911. This way, when events were not recorded via the
`tracing-log` adapter, we will use the `&'static` tracing metadata
string for their targets, rather than allocating a new `String`. New
`String`s are only allocated when an event came from the `log` crate
and its target is not valid for the `'static` lifetime.
* Use `Level::as_str` for the `Level` key-value field, instead of
`Level::to_string`. `to_string` calls `fmt::Display` and returns a
`String`, while `as_str` returns an `&'static str`. This way, levels
will never allocate a `String`.
This branch adds the source code file, module path, and line number to
OpenTelemetry events as the OpenTelemetry `code.filepath`,
`code.namespace`, and `code.lineno` fields, respectively, if they are
set in the `tracing` event's metadata.
Fixes#1910
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.
## Motivation
Support the latest OpenTelemetry specification.
## Solution
Update `opentelemetry` to the latest `0.17.x` release. Breaking changes
upstream in the tracking of parent contexts in otel's `SpanBuilder` have
necessitated a new `OtelData` struct to continue pairing tracing spans
with their associated otel `Context`.
# Conflicts:
# .github/workflows/check_msrv.yml
# tracing-opentelemetry/Cargo.toml
# tracing-opentelemetry/benches/trace.rs
# tracing-opentelemetry/src/layer.rs
# tracing-opentelemetry/src/span_ext.rs
# tracing-opentelemetry/tests/trace_state_propagation.rs
# 0.3.0 (Oct 22, 2021)
This is a breaking release of `tracing-subscriber`. The primary breaking
change in this release is the removal of the dependency on the [`chrono`
crate], due to [RUSTSEC-2020-0159]. To replace `chrono`, support is
added for formatting timestamps using the [`time` crate] instead.
In addition, this release includes a number of other breaking API
changes, such as adding (limited) support for `#![no_std]` targets,
removing previously deprecated APIs, and more.
### Breaking Changes
- Removed APIs deprecated in the v0.2.x release series.
- Renamed `Layer::new_span` to `Layer::on_new_span` ([#1674])
- Removed `Layer` impl for `Arc<L: Layer<S>>` and `Arc<dyn Layer<S> +
...>` ([#1649])
- Replaced the [`chrono` crate] with the [`time` crate] for timestamp
formatting, to resolve [RUSTSEC-2020-0159] ([#1646])
- Removed `json` and `env-filter` from default features. They must now
be enabled explictly ([#1647])
- Changed `FormatEvent::format_event` and `FormatFields::format_fields`
trait methods to take a `Writer` type, rather than a `&mut dyn
fmt::Write` trait object ([#1661])
- Changed the signature of the `MakeWriter` trait by adding a lifetime
parameter ([#781])
### Changed
- **layer**: Renamed `Layer::new_span` to `Layer::on_new_span` ([#1674])
- **fmt**: Changed `FormatEvent::format_event` and
`FormatFields::format_fields` trait methods to take a `Writer` type,
rather than a `&mut dyn fmt::Write` trait object ([#1661])
- **json**, **env-filter**: `json` and `env-filter` feature flags are no
longer enabled by default ([#1647])
### Removed
- Removed deprecated `CurrentSpan` type ([#1320])
- **registry**: Removed deprecated `SpanRef::parents` iterator, replaced
by `SpanRef::scope` in [#1431] ([#1648)])
- **layer**: Removed deprecated `Context::scope` iterator, replaced by
`Context::span_scope` and `Context::event_scope` in [#1431] and
[#1434] ([#1648)])
- **layer**: Removed `Layer` impl for `Arc<L: Layer<S>>` and `Arc<dyn
Layer<S> + ...>`. These interfere with per-layer filtering. ([#1649])
- **fmt**: Removed deprecated `LayerBuilder` type ([#1673])
- **fmt**: Removed `fmt::Layer::on_event` (renamed to
`fmt::Layer::fmt_event`) ([#1673])
- **fmt**, **chrono**: Removed the `chrono` feature flag and APIs for
using the [`chrono` crate] for timestamp formatting ([#1646])
### Added
- **fmt**, **time**: `LocalTime` and `UtcTime` types for formatting
timestamps using the [`time` crate] ([#1646])
- **fmt**: Added a lifetime parameter to the `MakeWriter` trait,
allowing it to return a borrowed writer. This enables implementations
of `MakeWriter` for types such as `Mutex<T: io::Write>` and
`std::fs::File`. ([#781])
- **env-filter**: Documentation improvements ([#1637])
- Support for some APIs on `#![no_std]` targets, by disabling the `std`
feature flag ([#1660])
Thanks to @Folyd and @nmathewson for contributing to this release!
[#1320]: https://github.com/tokio-rs/tracing/pull/1320
[#1673]: https://github.com/tokio-rs/tracing/pull/1673
[#1674]: https://github.com/tokio-rs/tracing/pull/1674
[#1646]: https://github.com/tokio-rs/tracing/pull/1646
[#1647]: https://github.com/tokio-rs/tracing/pull/1647
[#1648]: https://github.com/tokio-rs/tracing/pull/1648
[#1649]: https://github.com/tokio-rs/tracing/pull/1649
[#1660]: https://github.com/tokio-rs/tracing/pull/1660
[#1661]: https://github.com/tokio-rs/tracing/pull/1661
[#1431]: https://github.com/tokio-rs/tracing/pull/1431
[#1434]: https://github.com/tokio-rs/tracing/pull/1434
[#781]: https://github.com/tokio-rs/tracing/pull/781
[`chrono` crate]: https://crates.io/crates/chrono
[`time` crate]: https://crates.io/crates/time
[RUSTSEC-2020-0159]: https://rustsec.org/advisories/RUSTSEC-2020-0159.html
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Backports #1648 from `master`.
Depends on #1649
## Motivation
Presently, the `tracing-subscriber` crate requires the Rust standard
library and doesn't build with `#![no_std]` targets. For the most part,
this is fine, as much of `tracing-subscriber` inherently depends on
`std` APIs.
However, `tracing-subscriber` also contains some key abstractions that
are necessary for interoperability: the `Layer` and `LookupSpan`
traits. Since these traits are in `tracing-subscriber`, `no-std` users
cannot currently access them.
Some of the other utilities in this crate, such as the field visitor
combinators, may also be useful for `#![no_std]` projects.
## Solution
This branch adds "std" and "alloc" feature flags to
`tracing-subscriber`, for conditionally enabling `libstd` and
`liballoc`, respectively. The `registry`, `fmt`, `EnvFilter`, and
`reload` APIs all require libstd, and cannot be implemented without it,
but the core `Layer` and `LookupSpan` traits are now available with
`#![no_std]`.
Fixes#999
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
I noticed a handful of places where `v0.1.x` refers to `Subscriber`s as
"collectors". This probably happened because we backported some commits
from master and forgot to change every instance of "collector" back to
"subscriber".
This commit fixes that. Whoops.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Repeat of #1480 to merge on master.
## Motivation
Discussed in #1121, the opentelemetry specifications allow adding a link
to a propagated span and/or a closed span. However, the implemented
`on_follows_from` of the `OpenTelemetryLayer` does not allow this.
## Solution
The solution follows the same model as the `set_parent` `Span` extension
function. A `add_link` function that takes the linked span context was
added to the `OpenTelemetrySpanExt`.
This branch fixes some minor RustDoc issues. In particular:
- The `broken_intra_doc_links` lint was renamed to
`rustdoc::broken_intra_doc_links`. This generates a warning, since the
old name was deprecated.
- `ignore` code blocks are specifically for _Rust_ code that should not
be compiled, not for other text blocks. We were using `ignore` on JSON
blocks, which generates a warning.
- A bunch of links in `tracing-subscriber`'s RustDocs were broken. This
fixes that.
I also changed the Netlify configuration to run with `-D warnings`, so that
we can surface RustDoc warnings in CI builds.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
# 0.14.0 (July 9, 2021)
### Breaking Changes
- Upgrade to `v0.15.0` of `opentelemetry` ([#1441])
For list of breaking changes in OpenTelemetry, see the
[v0.14.0 changelog](https://github.com/open-telemetry/opentelemetry-rust/blob/main/opentelemetry/CHANGELOG.md#v0140).
### Added
- Spans now include Opentelemetry `code.namespace`, `code.filepath`, and
`code.lineno` attributes ([#1411])
### Changed
- Improve performance by pre-allocating attribute `Vec`s ([#1327])
Thanks to @Drevoed, @lilymara-onesignal, and @Folyd for contributing
to this release!
Closes#1462
The `SpanBuilder` uses `Vec` to store span's fields. However, the
current solution can be slightly improved by preparing the capacity of
`Vec` in advance, this can reduce a few memory reallocations.
Since the max number of tracing's span fields is 32, we can replace
`Vec` with `SmallVec` to further improve performance. Maybe, we should
add a new feature (such as `smallvec`?) to the `opentelemetry` crate.
Well, this should be discussed in the `opentelemetry` repo.
Co-authored-by: Eliza Weisman <eliza@buoyant.io>
This backports PR #1441 from `master`
## Motivation
Newest versions of opentelemetry and opentelemetry-jaeger don't work
with the tracing-opentelemtry due to the latter still depending on a
0.14 version.
## Solution
Adjust dependencies and use new TraceFlags struct instead of constants
The opentelemetry specification calls for a number of attributes to correlate
traces to their location in the code. They are documented here [1]. This commit
adds support for the following fields based on the tracing span metadata (all
relative to span creation):
- `code.namespace`: Crate & module path (`my_crate::my_mod`)
- `code.filepath`: Relative path to the source code file (`src/my_mod.rs`)
- `code.lineno`: Line number in the file indicated by `code.filepath` (`72`)
As written this will annotate all spans with these attributes. If we want to be
a bit more conservative, I could add an instance variable to the Subscriber that
allows users to opt-in or opt-out of this functionality.
[1]: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/semantic_conventions/span-general.md#source-code-attributes
Co-authored-by: Lily Mara <lilymara@onesignal.com>
## Motivation
Support the latest OpenTelemetry specification.
## Solution
Update `opentelemetry` to the latest `0.14.x` release. Despite breaking
changes upstream, no additional public API or behavioral changes are
necessary in `tracing-opentelemetry`, but simplifications in the
propagation of span information have removed the need for the current
internal `CompatSpan` and custom parent context construction.
Performance has improved by ~30% on current benchmarks.
## Motivation
Currently, the default `Compact` and `Full` formatters in
`tracing-subscriber` will prefix log lines with a single space when
timestamps are disabled. The space is emitted in order to pad the
timestamp from the rest of the log line, but it shouldn't be emitted
when timestamps are turned off. This should be fixed.
## Solution
This branch fixes the issue by skipping `time::write` entirely when
timestamps are disabled. This is done by tracking an additional boolean
flag for disabling timestamps.
Incidentally, this now means that span lifecycle timing can be enabled
even if event timestamps are disabled, like this:
```rust
use tracing_subscriber::fmt;
let subscriber = fmt::subscriber()
.without_time()
.with_timer(SystemTime::now)
.with_span_events(fmt::FmtSpan::FULL);
```
or similar.
I also added a new test reproducing the issue, and did a little
refactoring to try and clean up the timestamp formatting code a bit.
Closes#1354
## Motivation
Allow users to set custom span status codes and messages to follow
opentelemetry semantic conventions.
## Solution
Support the status code and status message fields in
`OpenTelemetrySubscriber`
Proposal to close#1346
## Motivation
Understand the overhead added by recording OpenTelemetry data so that it
can be minimized.
## Solution
Add criterion benchmarks, initially tracking request/response style
workloads (1 main span with 99 children).
This patch adds benchmarks for standard `tracing-opentelemetry` usage,
as well as baselines for understanding the overhead specific to the
usage of the otel tracer, and registry span access patterns.
