opentelemetry: Add extension to link spans #1480
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
## Motivation The `tracing-macros` crate doesn't currently compile with the latest `tracing` release, because it uses internal private API that changed. We need to fix this so CI isn't broken. ## Solution I changed the `dbg!` macro so it no longer uses internal APIs. Ideally, we would implement `dbg!` using the support for string-literal field names that was recently added to `tracing`, but I couldn't actually get it to work --- I think the `event!` macros may not handle string literal field names properly (we only test them with the `span!` macros >_>). Will try to fix that later, but for now, this fixes CI and I don't think anyone actually uses the experimental, unreleased `tracing-macros` crate. Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Backports tokio-rs#1012 to v0.1.x. This adds support for having dashes in log target names, like: `target-name=info` ## Motivation We are using log targets with dashes in our project. ## Solution Extend the target parsing regex to support dashes.
…u64) (tokio-rs#1007) (tokio-rs#1013) This backports tokio-rs#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 04bbb15)
…io-rs#1021) ## Motivation Fixes tokio-rs#975. ## Solution This implements the warning in `tracing-subscriber` only, as mentioned in tokio-rs#975 (comment). It warns whenever directives are parsed, including programmatically and through environment variables. It does not include the suggested new API which returns the filters that wouldn't be parsed. - List filters that would be ignored - Mention 'static max level' - Describe how to enable the logging Example output: ``` $ RUST_LOG=off,debug,silenced[x]=trace cargo run -q warning: some trace filter directives would enable traces that are disabled statically | `debug` would enable the DEBUG level for all targets | `silenced[x]=trace` would enable the TRACE level for the `silenced` target = note: the static max level is info = note: to enable DEBUG logging, remove the `max_level_info` feature ``` 
This backports PR tokio-rs#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 tokio-rs#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 😆 rust-lang/rust-clippy#6089
### Changed - Updated `tracing-core` to 0.1.17 ([tokio-rs#992]) ### Added - **env-filter**: Added support for filtering on targets which contain dashes ([tokio-rs#1014]) - **env-filter**: Added a warning when creating an `EnvFilter` that contains directives that would enable a level disabled by the `tracing` crate's `static_max_level` features ([tokio-rs#1021]) Thanks to @jyn514 and @bkchr for contributing to this release! [tokio-rs#992]: tokio-rs#992 [tokio-rs#1014]: tokio-rs#1014 [tokio-rs#1021]: tokio-rs#1021
## 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.
…kio-rs#1059) This backports tokio-rs#1058 to v0.1.x. This was already approved on master. ## Motivation We've tried very hard to make sure that entering and exiting spans is lightweight...in the `tracing-core` core machinery. Unfortunately, we haven't done any benchmarking of how subscriber implementations actually handle enter/exit events. It turns out that in `tracing-subscriber`'s `Registry`, there's actually significant overhead for entering a span: calling `span.enter()` may take as long as 69 ns (on my machine). ## Solution I've written some microbenchmarks for entering and exiting enabled spans using `tracing-subscriber::fmt`, comparing them with the overhead of calling `enter` on an enabled span. Based on this, I've made some performance improvements. These optimizations include: - Removing the `HashSet` that's used for tracking previously entered span IDs, in favor of linear search. Span stacks probably never deep enough for a hashmap to be faster than iterating over a couple of vec indices. - Preallocating the vec used for the span stack to hold at least 64 elements. This means we'll never have a lag spike from reallocating, as I think it'll almost never be deeper than 64 IDs. - Only cloning/dropping an ID's ref count for the _first_ ID in the stack. This makes entering and exiting enabled spans significantly faster:  It would be nice to continue optimizing this, but this might be about the best it gets given the other requirements that we're now making assertions about. Signed-off-by: Eliza Weisman <eliza@buoyant.io>
This backports tokio-rs#1062 to v0.1.6. This has already been approved on master. hawkw/sharded-slab#45 changes `sharded-slab` so that the per-shard metadata is allocated only when a new shard is created, rather than all up front when the slab is created. This fixes the very large amount of memory allocated by simply creating a new `Registry` without actually collecting any traces. This branch updates `tracing-subscriber` to depend on `sharded-slab` 0.1.0, which includes the upstream fix. In addition, this branch the registry from using `sharded_slab::Slab` to `sharded_slab::Pool`. This allows us to clear hashmap allocations for extensions in-place, retaining the already allocated maps. This should improve `new_span` performance a bit. Fixes tokio-rs#1005 Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Fixed - **registry**: Fixed `Registry::new` allocating an excessively large amount of memory, most of which would never be used ([tokio-rs#1064]) Changed - **registry**: Improved `new_span` performance by reusing `HashMap` allocations for `Extensions` ([tokio-rs#1064]) - **registry**: Significantly improved the performance of `Registry::enter` and `Registry::exit` ([tokio-rs#1058]) [tokio-rs#1064]: tokio-rs#1064 [tokio-rs#1058]: tokio-rs#1058
…s#1080) This backports PR tokio-rs#1067 to v0.1.x. Since this has already been approved on master, I'm just going to go ahead and merge it when CI passes. ## Motivation Currently, the `tracing_subscriber::fmt` module contains only single-line event formatters. Some users have requested a human-readable, pretty-printing event formatter optimized for aesthetics. ## Solution This branch adds a new `Pretty` formatter which uses an _excessively_ pretty output format. It's neither compact, single-line oriented, nor easily machine-readable, but it looks _quite_ nice, in my opinion. This is well suited for local development or potentially for user-facing logs in a CLI application. Additionally, I tried to improve the docs for the different formatters currently provided, including example output. Check out [the Netlify preview][1]! [1]: https://deploy-preview-1067--tracing-rs.netlify.app/tracing_subscriber/fmt/index.html#formatters Signed-off-by: Eliza Weisman <eliza@buoyant.io>
…o-rs#1081) (tokio-rs#1082) This backports PR tokio-rs#1081 from v0.2.x. Since this has already been approved on master, I'll just go ahead and merge it when CI passes. ## Motivation Currently, the `FmtContext` type implements `FormatFields` using the subscriber's field formatter. However, this is difficult to use. The `FmtContext` may _not_ be passed to functions expecting a `for<'writer> FormatFields<'writer>`, because it only implements `FormatFields` for its _own_ lifetime. This means the writer must have the same lifetime as the context, which is not correct. ## Solution This branch fixes this by changing the impl of `FormatFields` for `FmtContext` to be generic over both the context's lifetime _and_ the field formatter's lifetime. Additionally, I've added a method for borrowing the actual field formatter as its concrete type, in case the `FormatEvent` impl puts additional constraints on its type or is only implemented for a specific named type, and wants to actually _use_ that type.
### Fixed - **fmt**: Fixed wrong lifetime parameters on `FormatFields` impl for `FmtContext` ([tokio-rs#1082]) ### Added - **fmt**: `format::Pretty`, an aesthetically pleasing, human-readable event formatter for local development and user-facing CLIs ([tokio-rs#1080]) - **fmt**: `FmtContext::field_format`, which returns the subscriber's field formatter ([tokio-rs#1082]) [tokio-rs#1082]: tokio-rs#1082 [tokio-rs#1080]: tokio-rs#1080
…okio-rs#1099) This backports tokio-rs#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
…kio-rs#1100) Closes tokio-rs#648 Install cargo-hack from GitHub release instead of using cache. See also taiki-e/cargo-hack#89 and taiki-e/cargo-hack#91.
…#1117) Currently, we are building and caching `cargo-audit` on CI. The GitHub Actions configuration we use for caching the `cargo-audit` binary is now deprecated and is [breaking our CI builds][2]. This PR switches to the [`actions-rs/audit-check` action][3]. This ought to fix CI. [1]: https://github.blog/changelog/2020-10-01-github-actions-deprecating-set-env-and-add-path-commands/ [2]: https://github.com/tokio-rs/tracing/pull/1116/checks?check_run_id=1444562432 [3]: https://github.com/actions-rs/audit-check
…io-rs#1116) * chore(deps): update pin-project-lite requirement from 0.1 to 0.2 This backports tokio-rs#1108 to v0.1.x. This was already approved on `master`, so I'll just merge it pending CI. Updates the requirements on [pin-project-lite](https://github.com/taiki-e/pin-project-lite) to permit the latest version. - [Release notes](https://github.com/taiki-e/pin-project-lite/releases) - [Changelog](https://github.com/taiki-e/pin-project-lite/blob/master/CHANGELOG.md) - [Commits](taiki-e/pin-project-lite@v0.1.0...v0.2.0) Signed-off-by: dependabot-preview[bot] <support@dependabot.com> Co-authored-by: dependabot-preview[bot] <27856297+dependabot-preview[bot]@users.noreply.github.com>
### Changed - Updated `pin-project-lite` dependency to 0.2 ([tokio-rs#1108]) [tokio-rs#1108]: tokio-rs#1108
## Motivation At Netlify we recently introduced native Rust support in the build system: netlify/build-image#477 ## Solution This PR cleans up the Netlify build config to use a more straight-forward way of building rust docs. This also introduces a workaround for netlify/build-image#505 ## Kudos We're big fans of the `tracing` crate at Netlify and using it for many new systems recently. Very happy we can give something back! Closes tokio-rs#1130
…nv_logger compat) (tokio-rs#1126) Hi Folks, This PR is about behavior compatibility with the `env_logger` and `log` crates. There are references in the `tracing-subscriber` docs noting some level of partial compatibility with `env_logger`, but it is not clear to me the extent to which that is a priority. If the intention is to keep the projects close in behavior where there is overlap in the representations of logging directive strings, then this PR is a step toward better compatibility. On the other hand, if such compatibility is more of a short-term nice-to-have than a long-term objective, then this PR might be a step in the wrong direction. If so, please feel free to reject it. I happened to notice the behavior difference (described below) while working on something else, and just thought I'd bring it up for discussion. On the *other* other hand, it is clear that some significant effort *has* been expended to have compatibly parsed logging directive strings. Which leads me to read the regex code modified in the second commit of this PR as possibly introducing a level of compatibility that was deliberately omitted; the existing regex was clearly structured to accept *only* all uppercase OR *only* all lowercase log level names. So I'm getting mixed signals :-) In the end, regardless of the specific outcome of this PR, understanding the degree to which `env_logger` compatibility is wanted would be useful to know in general. For my own use, `env_logger` compatibility is not something I need. ## Motivation Logging directive strings parsed to create `tracing_subscriber::filter::env::Directive`s are currently accepted as all-lower-case or all-upper-case representations of the log level names (like "info" and "INFO"), but mixed case representation (like "Info", "iNfo", and "infO") are rejected. This behavior is divergent with that of the `env_logger` crate, which accepts the mixed case names. The `env_logger` crate gets the behavior of parsing mixed case log level names from the underlying `log` crate, so there may be an element of user expectations involved in that regard, too, with `log` users expecting that case-insensitive log level names will be accepted. Accepting mixed case names would bring the behavior of the `tracing_subscriber` crate back into alignment those other crates in this regard. ## Solution Accept mixed case names for log levels in directive strings. This PR includes two commits: 1. The first adds unit tests that demonstrate the mixed case logging level names being rejected. 2. The second introduces an adjustment to `DIRECTIVE_RE` that accepts mixed case logging level names. With this change, the tests again all pass. * [1 of 2]: subscriber: add more parse_directives* tests These test parse_directives() against strings that contain only a legit log level name. The variants that submit the mixed case forms are currently failing: $ cargo test --lib 'filter::env::directive::test::parse_directives_' ... failures: filter::env::directive::test::parse_directives_global_bare_warn_mixed filter::env::directive::test::parse_directives_ralith_mixed test result: FAILED. 12 passed; 2 failed; 0 ignored; 0 measured; 61 filtered out Fix to come in a follow-up commit. Co-authored-by: Eliza Weisman <eliza@buoyant.io> Signed-off-by: Alan D. Salewski <ads@salewski.email> * [2 of 2]: subscriber: directives: accept log levels in mixed case Fix issue demonstrated by unit tests in commit f607b7f. With this commit, the unit tests all pass. The 'DIRECTIVE_RE' regex now uses a case-insensitive, non-capturing subgroup when matching log level names in logging directive strings. This allows correctly capturing not only, e.g., "info" and "INFO" (both of which were also accepted previously), but also "Info" and other combinations of mixed case variations for the legit log level names. This change makes the behavior of tracing-subscriber more consistent with that of the `env_logger` crate, which also accepts mixed case variations of the log level names. Co-authored-by: Eliza Weisman <eliza@buoyant.io> Signed-off-by: Alan D. Salewski <ads@salewski.email>
Update the closing-spans link.
We should allow configuring whether or not to display module_path or file/line in output. Co-authored-by: 李小鹏 <lixiaopeng.jetspark@bytedance.com> Co-authored-by: Jane Lusby <jlusby42@gmail.com> Co-authored-by: Eliza Weisman <eliza@buoyant.io>
## Motivation Tracing's examples depend on a number of external crates that the core `tracing` crates don't depend on. Sometimes, crates that we only depend on for examples will break compatibility with our MSRV. It's not ideal to bump our supported MSRV just for an example, since the actual `tracing` crates will still build fine. ## Solution Instead, this PR updates the CI config to exclude examples from the MSRV check. This way, we don't have to bump MSRV for examples-only dependencies. Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation Fixes the race condition outlined in tokio-rs#1120 . ## Solution `Worker` now uses a 2 stage shutdown approach. The first shutdown signal is sent through the main message channel to the `Worker` from `WorkerGuard` when it is dropped. Then `WorkerGuard` sends a second signal on a second channel that is zero-capacity. This means It will only succeed a `send()` when a `recv()` is called on the other end. This guarantees that the `Worker` has flushed all it's messages before the `WorkerGuard` can continue with its drop. With this solution I'm not able to reproduce the race anymore using the provided code sample from tokio-rs#1120 Co-authored-by: Zeki Sherif <zekshi@amazon.com>
…tokio-rs#1031) Updates the requirements on [crossbeam-channel](https://github.com/crossbeam-rs/crossbeam) to permit the latest version. - [Release notes](https://github.com/crossbeam-rs/crossbeam/releases) - [Changelog](https://github.com/crossbeam-rs/crossbeam/blob/master/CHANGELOG.md) - [Commits](crossbeam-rs/crossbeam@crossbeam-channel-0.4.3...crossbeam-channel-0.5.0) Signed-off-by: dependabot-preview[bot] <support@dependabot.com> Co-authored-by: dependabot-preview[bot] <27856297+dependabot-preview[bot]@users.noreply.github.com>
Changed - **non_blocking**: Updated `crossbeam-channel` dependency to 0.5 (tokio-rs#1031) Fixed - **non_blocking**: Fixed a race condition when logging on shutdown (tokio-rs#1125) - Several documentation improvements (tokio-rs#1109, tokio-rs#1110, tokio-rs#941, tokio-rs#953)
There is no struct named `Subscriber`, I think the `Subscriber` here is a trait.
This backports PR tokio-rs#1141 from `master`. subscriber: add `MakeWriter::make_writer_for` ## Motivation In some cases, it might be desirable to configure the writer used for writing out trace data based on the metadata of the span or event being written. For example, we might want to send different levels to different outputs, write logs from different targets to separate files, or wrap formatted output in ANSI color codes based on levels. Currently, it's not possible for the `MakeWriter` trait to model this kind of behavior --- it has one method, `make_writer`, which is completely unaware of *where* the data being written came from. In particular, this came up in PR tokio-rs#1137, when discussing a proposal that writing to syslog could be implemented as a `MakeWriter` implementation rather than as a `Subscribe` implementation, so that all the formatting logic from `tracing_subscriber::fmt` could be reused. See [here][1] for details. ## Solution This branch adds a new `make_writer_for` method to `MakeWriter`, taking a `Metadata`. Implementations can opt in to metadata-specific behavior by implementing this method. The method has a default implementation that just calls `self.make_writer()` and ignores the metadata, so it's only necessary to implement this when per-metadata behavior is required. This isn't a breaking change to existing implementations. There are a couple downsides to this approach: it's possible for callers to skip the metadata-specific behavior by calling `make_writer` rather than `make_writer_for`, and the impls for closures can't easily provide metadata-specific behavior. Since the upcoming release is going to be a breaking change anyway, we may want to just make the breaking change of having `MakeWriter::make_writer` _always_ take a `Metadata`, which solves these problems. However, that can't be backported to v0.1.x as easily. Additionally, that would mean that functions like `io::stdout` no longer implement `MakeWriter`; they would have to be wrapped in a wrapper type or closure that ignores metadata. [1]: tokio-rs#1137 (comment) Signed-off-by: Eliza Weisman <eliza@buoyant.io>
## Motivation The RAII pattern documentation has been moved. ## Solution Update the link to the document.
…io-rs#1411) 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>
This backports PR tokio-rs#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
This fixes a handful of new clippy lints. Should fix CI. Signed-off-by: Eliza Weisman <eliza@buoyant.io>
…fore if statement (tokio-rs#1433) This backports tokio-rs#1433 from `master`. * subscriber: explain why we always call `inner.register_callsite()` before if statement * Apply suggestions from code review Co-authored-by: Eliza Weisman <eliza@buoyant.io>
tokio-rs#1327) 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 tokio-rs#1274 from `master`. Depends on tokio-rs#1141. This branch adds a `MakeWriterExt` trait which adds a number of combinators for composing multiple types implementing `MakeWriter`. `MakeWriter`s can now be teed together, filtered with minimum and maximum levels, filtered with a `Metadata` predicate, and combined with a fallback for when a writer is _not_ made for a particular `Metadata`. I've also added a `MakeWriter` impl for `Arc<W>` when `&W` implements `Write`. This enables `File`s to be used as `MakeWriter`s similarly to how we will be able to in 0.3, with the additional overhead of having to do ref-counting because we can't return a reference from `MakeWriter` until the next breaking change. Signed-off-by: Eliza Weisman <eliza@buoyant.io>
This adds a section to the `Level` docs explaining the comparison rules for `Level` and `LevelFilter`. It turns out this wasn't really explicitly documented anywhere. I may have gone a bit overboard on this, but I think the new docs should be helpful... See tokio-rs#1274 (comment) Signed-off-by: Eliza Weisman <eliza@buoyant.io> Co-authored-by: David Barsky <me@davidbarsky.com>
# 0.2.19 (June 25, 2021) ### Deprecated - **registry**: `SpanRef::parents`, `SpanRef::from_root`, and `Context::scope` iterators, which are replaced by new `SpanRef::scope` and `Scope::from_root` iterators (tokio-rs#1413) ### Added - **registry**: `SpanRef::scope` method, which returns a leaf-to-root `Iterator` including the leaf span (tokio-rs#1413) - **registry**: `Scope::from_root` method, which reverses the `scope` iterator to iterate root-to-leaf (tokio-rs#1413) - **registry**: `Context::event_span` method, which looks up the parent span of an event (tokio-rs#1434) - **registry**: `Context::event_scope` method, returning a `Scope` iterator over the span scope of an event (tokio-rs#1434) - **fmt**: `MakeWriter::make_writer_for` method, which allows returning a different writer based on a span or event's metadata (tokio-rs#1141) - **fmt**: `MakeWriterExt` trait, with `with_max_level`, `with_min_level`, `with_filter`, `and`, and `or_else` combinators (tokio-rs#1274) - **fmt**: `MakeWriter` implementation for `Arc<W> where &W: io::Write` (tokio-rs#1274) Thanks to @teozkr and @Folyd for contributing to this release!
# 0.14.0 (July 9, 2021) ### Breaking Changes - Upgrade to `v0.15.0` of `opentelemetry` ([tokio-rs#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 ([tokio-rs#1411]) ### Changed - Improve performance by pre-allocating attribute `Vec`s ([tokio-rs#1327]) Thanks to @Drevoed, @lilymara-onesignal, and @Folyd for contributing to this release! Closes tokio-rs#1462
## Motivation Discussed in tokio-rs#1121, the purpose of adding the `add_link` extension is to allow adding a link to a propagated span and/or a closed span.
jtescher
added
the
crate/opentelemetry
jtescher
approved these changes
Jul 31, 2021
|
@LehMaxence oh this PR should probably be into |
LehMaxence
requested review from
carllerche,
davidbarsky,
hawkw and
yaahc
as code owners
Okay, I'll re-create a PR based on the master branch. |
hawkw
pushed a commit
that referenced
this pull request
Aug 23, 2021
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`.
hawkw
pushed a commit
that referenced
this pull request
Sep 4, 2021
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`.
hawkw
pushed a commit
that referenced
this pull request
Sep 4, 2021
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`.
kaffarell
pushed a commit
to kaffarell/tracing
that referenced
this pull request
May 22, 2024
Repeat of tokio-rs#1480 to merge on master. ## Motivation Discussed in tokio-rs#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`.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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_fromof theOpenTelemetryLayerdoes not allow this.Solution
The solution follows the same model as the
set_parentSpanextension function.A
add_linkfunction that takes the linked span context was added to theOpenTelemetrySpanExt.