Add in opentelemetry tracing as a feature#3287
Merged
rbtcollins merged 1 commit intorust-lang:masterfrom May 3, 2023
Merged
Conversation
Contributor
Author
5337e36 to
f2afa2a
Compare
Contributor
Author
bc14b7c to
8f4c55b
Compare
Member
|
I'll try it and review it recently. Thanks! |
0xPoe
reviewed
Apr 26, 2023
Member
0xPoe
left a comment
There was a problem hiding this comment.
Just go through it. The PR is conflicting now.
I will take a deep look tomorrow.
Thanks for adding it!
1fa56a8 to
baae569
Compare
Contributor
Author
|
Update to resolve conflicts |
Contributor
Author
|
Random MacOSX test failure with no visible cause :/ |
0xPoe
approved these changes
May 3, 2023
Member
0xPoe
left a comment
There was a problem hiding this comment.
Tested locally. Looks good to me! Thanks for adding it!
Sorry, I merged some PRs and make your pull request conflicts again.
| them temporarily while figuring out the shape of a problem) | ||
| - Be way of debug build timing - release optimisations make a huge difference, | ||
| though debug is a lot faster to iterate on. If something isn't a problem in | ||
| release don't pay it too much heed in debug. |
Member
There was a problem hiding this comment.
Suggested change
| release don't pay it too much heed in debug. | |
| release don't pay it too much heed in debug |
Contributor
Author
There was a problem hiding this comment.
Why don't you want the trailing period ('.')?
Member
There was a problem hiding this comment.
Because other sentences don't have it.
This is an evolution on the previous tracing support I added a few years back. See CONTRIBUTING for details. The rs_tracing crate is functionally fine but very limited in features compared to the tracing crate that provides the developer interface for opentelemetry instrumentation. As we start looking at performance again I think this tooling will be useful. Included is support for both tracing rustup-init and individual tests
1 task
1 task
bors
added a commit
to rust-lang/cargo
that referenced
this pull request
Mar 5, 2024
feat(cli): Allow logging to chrome traces ### What does this PR try to resolve? > The time from executing cargo to executing rustc is 230 ms. I wonder if there’s scope for caching whatever expensive computations cargo is doing here. *Source: https://davidlattimore.github.io/working-on-rust-iteration-time.html* This made me curious where the time was going. I've been meaning to try out `tracing-chrome` for a while and this gave me the opportunity. This adds `CARGO_LOG_PROFILE=<bool>` and `CARGO_LOG_PROFILE_CAPTURE_ARGS=<bool>` for enabling and controlling these trace files. These are perma-unstable env variables. Traces can be viewed at https://ui.perfetto.dev or `chrome://tracing`. Example: no-op `cargo check` run on `cargo-nextest`:  TODO - [ ] Find a place to document this, see https://doc.crates.io/contrib/tests/profiling.html#internal-profiler ### How should we test and review this PR? I looked in `config/` and didn't see a env variable parser to reuse (`get_cv_with_env` is too specialized). ### Additional information In past projects, I've been able to use features like this to better understand code bases, bugs, etc. Hopefully this can evolve to help on-board people one day. Most of the implementation was inspired by https://github.com/arxanas/git-branchless/blob/2923924dfbff07faa61d50771b6604cb18e64bc8/git-branchless-invoke/src/lib.rs#L55 `tracing-chrome` hasn't received updates recently, but it is also fairly quiet on Issues and PRs, so this might just be "maturity". It does have over a million downloads. It also is only enabled if explicitly opted into. rustup added trace visualization in rust-lang/rustup#3287 using [open telemetry](https://crates.io/crates/tracing-opentelemetry) but it is behind a feature flag and and requires running a server to receive the traces.
This file contains hidden or 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
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.


This is an evolution on the previous tracing support I added a few years
back. See CONTRIBUTING for details.
The rs_tracing crate is functionally fine but very limited in features
compared to the tracing crate that provides the developer interface for
opentelemetry instrumentation. As we start looking at performance again
I think this tooling will be useful.