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.
## 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>
