Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

backport 13 commits from master #2150

Merged
merged 13 commits into from Jun 7, 2022
Merged

backport 13 commits from master #2150

merged 13 commits into from Jun 7, 2022

Conversation

hawkw
Copy link
Member

@hawkw hawkw commented Jun 6, 2022

This branch backports the following commits:

hubertbudzynski and others added 12 commits June 6, 2022 11:13
Fixes: #2094

## Motivation 

Properly attach event's source locations.

## Solution

Append the locations to events' attributes instead of span's
attributes.
This attempts to address #2106 by disabling the `tracing-core`
crate's default features in `tracing-subscriber`'s dependency.
Now, `tracing-core`'s optional "alloc" feature is only enabled
when "tracing-subscriber/alloc" is enabled.

Closes #2106
Updates the requirements on [tokio-test](https://github.com/tokio-rs/tokio) to permit the latest version.
- [Release notes](https://github.com/tokio-rs/tokio/releases)
- [Commits](tokio-rs/tokio@tokio-0.2.0...tokio-0.3.0)

Signed-off-by: dependabot[bot] <support@github.com>

Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Eliza Weisman <eliza@buoyant.io>
## Motivation

Closes #1465.

## Solution

I'm just disabling the default features of `tracing-journald`'s
dependency on `tracing-subscriber`. The original issue talked about the
crate's dependencies more broadly but considering that the standard
library is already depended upon I didn't think it made sense to change
the `tracing-core` dependency's features (which are just `no_std`
support).
…cs. (#1088)

Co-authored-by: Bryan Garza <1396101+bryangarza@users.noreply.github.com>
Co-authored-by: Bryan Garza <1396101+bryangarza@users.noreply.github.com>
The `with_event_location(false)` method will now properly omit `code.*`
tags from spans.

## Motivation

Recently, I attempted to remove the `code.*` tags from opentelemetry
tracing spans utilizing the [`with_event_location`] of
OpenTelemetrySubscriber. This did not work as expected because the
[`on_new_span`] doesn't account for the `event_location` boolean similar
to how [`on_event`] does.

## Solution

The change presented will expand the use of the `location` field to
check before adding the `code.*` KeyValue attributes in `on_new_span`.

In addition, `with_event_location` was renamed to `with_location`, as it
now controls both span *and* event locations, and the
`with_event_location` method has been deprecated.

## Testing

Additional unit tests are included in
[tracing-opentelemetry/src/subscriber.rs] to cover both boolean cases of
`with_location`.

[`with_event_location`]: https://github.com/tokio-rs/tracing/blob/master/tracing-opentelemetry/src/subscriber.rs#L343
[`on_new_span`]: https://github.com/tokio-rs/tracing/blob/master/tracing-opentelemetry/src/subscriber.rs#L448-L460
[`on_event`]: https://github.com/tokio-rs/tracing/blob/master/tracing-opentelemetry/src/subscriber.rs#L582
[tracing-opentelemetry/src/subscriber.rs]: https://github.com/tokio-rs/tracing/pull/2124/files#diff-69011e8b23dffcbe19b9b72e5ac54330a7871f424a90700ed7f5c5686daf431bR911-R975)
* appender: add initial set of benches

This patch adds blocking and nonblocking benchmarks. This code is from
an old PR (#703) that was never merged, and now ported to TOT so that it
compiles.

Co-authored-by: Zeki Sherif <9832640+zekisherif@users.noreply.github.com>

* switch to no-op writers in benchmarks

* fix macro resolution issue

Co-authored-by: Zeki Sherif <9832640+zekisherif@users.noreply.github.com>
Co-authored-by: David Barsky <me@davidbarsky.com>
`tracing`'s lib.rs incorrectly states its MSRV; this commit removes it.
OpenTelemetry has [semantic conventions][1] for reporting thread names
and IDs on spans. This branch adds support for recording thread names
and IDs according to these conventions.

[1]: https://opentelemetry.io/docs/reference/specification/trace/semantic_conventions/span-general/#source-code-attributes

Signed-off-by: Eliza Weisman <eliza@buoyant.io>
… >= 0.9.0, <= 0.13 (#2143)

Updates the requirements on [parking_lot](https://github.com/Amanieu/parking_lot) to permit the latest version.
- [Release notes](https://github.com/Amanieu/parking_lot/releases)
- [Changelog](https://github.com/Amanieu/parking_lot/blob/master/CHANGELOG.md)
- [Commits](Amanieu/parking_lot@0.12.0...0.12.1)

---
updated-dependencies:
- dependency-name: parking_lot
  dependency-type: direct:production
...

Signed-off-by: dependabot[bot] <support@github.com>

Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
@hawkw hawkw requested review from a team, jtescher and yaahc as code owners June 6, 2022 18:40
@hawkw hawkw force-pushed the eliza/backport-2099 branch 2 times, most recently from ef4991b to 7591fa1 Compare June 6, 2022 18:57
Replace `lazy_static` with `once_cell`. Fixes #2146.

## Motivation

`lazy_static!`, while a declarative macro, is a macro nonetheless. It
can add quite a bit of additional compilation time cost.
`once_cell::sync::Lazy` does the same thing with generics, and can be
used more flexibly (i.e. non-static lazily initialized values), and has
been proposed to be added to `std` (see linked issue).

I'm trying to reduce the compile time and dependency tree complexity of
a dependent project: [bevy](https://bevyengine.org), which is using
tracing. `lazy_static` and `once_cell` are both in our dependency tree
and both end up doing the same thing.

## Solution

Migrate to `once_cell`.
@hawkw hawkw merged commit 29b265d into v0.1.x Jun 7, 2022
@hawkw hawkw deleted the eliza/backport-2099 branch June 7, 2022 17:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet