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

feat(profiling): add profiling to debug_files commands #1325

Closed
wants to merge 15 commits into from

Conversation

viglia
Copy link

@viglia viglia commented Sep 13, 2022

No description provided.

@viglia viglia self-assigned this Sep 13, 2022
@viglia viglia added the feature label Sep 13, 2022
@kamilogorek
Copy link
Contributor

It looks like you rebased something on top of latest master branch and my recent commit is showing up here. Can you fix that please?

Copy link
Contributor

@kamilogorek kamilogorek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As for the tracing code itself, I need to ping @Swatinem as I've never used it in Rust.

.github/workflows/build.yml Outdated Show resolved Hide resolved
Cargo.toml Show resolved Hide resolved
Cargo.toml Outdated Show resolved Hide resolved
Cargo.toml Outdated
openssl-probe = "0.1.5"
signal-hook = "0.3.14"
crossbeam-channel = "0.5.5"
sentry = { git = "https://github.com/getsentry/sentry-rust", version = "0.27.0", default-features = false, features = ["anyhow", "curl", "profiling", "frame-pointer"] }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Specifying url should be unnecessary here.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Without the url it's going to pull the latest published crate I think.

I'm not sure made it to a release yet, plus I'm about to merge a PR to align to a new standard format for profiles across all the SDKs so that is def. not in any release yet.

We can coordinate this with @Swatinem to make sure we make a release and at that point we can use a specific version instead of pulling from master ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

getsentry/sentry-rust#504 is already approved, so lets merge it, release new sentry-rust and replace it with regular cargo index as it was previously.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll have to hold on for a bit for that.

I can merge that yet as the related Relay, Sentry and Snuba PRs have yet to be merged.

Once those are merged I'll be able to merge the sentry-rust, than I can use that as you suggested.

src/commands/mod.rs Outdated Show resolved Hide resolved
@kamilogorek
Copy link
Contributor

Fixed linting issue.

Copy link
Member

@Swatinem Swatinem left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe this example gives us a nice improvement opportunity for the global sentry API (wrapping a closure in a transaction)

I’m also not sure if some of these commands panic instead of returning an error, @kamilogorek can enlighten us here. I don’t think we currently finish a transaction when a panic occurs, and I’m also not sure that would work correctly the way that transactions can be shared by multiple hubs, or if that would even be desirable from a product point of view.

.github/workflows/ci.yml Show resolved Hide resolved
Comment on lines 20 to 21
cargo +nightly run -Z build-std --target ${TARGET};
RUSTFLAGS=\"-C force-frame-pointers=yes\" cargo build --release --target=${TARGET} --locked"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the CI job you use override which means cargo +nightly is the same as nightly, but I think here the second command is actually using stable Rust vs nightly.
Not quite sure how exactly build-std is supposed to work, I would need to look that up.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When I ran my experiments (both on Intel Mac and Linux VM) that seemed to work fine.

I'd run the second command without first enabling the nightly toolchain but simply using the stable one.

src/commands/debug_files/bundle_sources.rs Outdated Show resolved Hide resolved
src/commands/debug_files/upload.rs Outdated Show resolved Hide resolved
src/commands/mod.rs Outdated Show resolved Hide resolved
…ss of the results.

Also: remove explicit flush as by default the 2 seconds flush is already provided by the drop implementation.
@@ -70,6 +70,7 @@ trycmd = "0.13.4"
default = []
managed = []
with_crash_reporting = []
profiling = ["sentry"]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the SDK is still used for other things in sentry-cli. Only the profiling (and frame pointer) feature needs to be optional in this case.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that sentry get imported in line 43 in the "normal" dependency.

This is more for the optional one at line 90 specific to Unix.

I can't use the "package-name?/feature-name" syntax to simplify this because as you said sentry as a dependency is already used regardless of profiling and I would end up adding profiling even when I should not.

Not sure if there is a better way to handle this case but I'm open for suggestions.

@kamilogorek
Copy link
Contributor

I’m also not sure if some of these commands panic instead of returning an error, @kamilogorek can enlighten us here.

Yes, it can panic, and we have a hook for that in place as well

/// Initializes the backtrace support
pub fn init_backtrace() {
std::panic::set_hook(Box::new(|info| {
let backtrace = backtrace::Backtrace::new();
let thread = std::thread::current();
let thread = thread.name().unwrap_or("unnamed");
let msg = match info.payload().downcast_ref::<&'static str>() {
Some(s) => *s,
None => match info.payload().downcast_ref::<String>() {
Some(s) => &**s,
None => "Box<Any>",
},
};
match info.location() {
Some(location) => {
eprintln!(
"thread '{}' panicked at '{}': {}:{}\n\n{:?}",
thread,
msg,
location.file(),
location.line(),
backtrace
);
}
None => eprintln!("thread '{}' panicked at '{}'{:?}", thread, msg, backtrace),
}
}));
}

@kamilogorek
Copy link
Contributor

kamilogorek commented Sep 27, 2022

I'd revert all the changes from Wraps command in a closure to make sure the transaction ends regardless of the results commit tbh, it's very noisy, and changes this PRs diff by hundreds of lines.

Cleaner solution IMO (at least for now), would be to modify debug_files/mod.rs, where we actually register and execute those commands. This way commands are self-contained, and profiling is only added as sort of "instrumentation" of those commands.

sentry::ClientOptions {
release: sentry::release_name!(),
user_agent: crate::constants::USER_AGENT.into(),
traces_sample_rate: 0.05,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if its worth it to move traces_sample_rate and profiles_sample_rate to constants.rs

src/commands/mod.rs Outdated Show resolved Hide resolved
Unwrap execute functions from the closures and instrument the execute function in debug_files/mod.rs instead
@github-actions
Copy link

This pull request has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you label it Status: Backlog or Status: In Progress, I will leave it alone ... forever!


"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀

@szokeasaurusrex
Copy link
Member

@viglia looks like this PR has been open for some time. Are the changes still relevant, and if yes, is the PR ready for review?

@viglia
Copy link
Author

viglia commented Jan 31, 2024

@szokeasaurusrex, I'm closing it since it's not relevant anymore.

@viglia viglia closed this Jan 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants