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(performance): Adds trace_status_rate function to span metrics #70685

Merged
merged 1 commit into from
May 13, 2024

Conversation

edwardgou-sentry
Copy link
Contributor

Adds trace_status_rate function to span metrics

@github-actions github-actions bot added the Scope: Backend Automatically applied to PRs that change backend components label May 10, 2024
Copy link

codecov bot commented May 10, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 80.03%. Comparing base (5a883ee) to head (af9c62c).
Report is 4 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff             @@
##           master   #70685      +/-   ##
==========================================
- Coverage   80.04%   80.03%   -0.01%     
==========================================
  Files        6505     6505              
  Lines      290739   290742       +3     
  Branches    50102    50102              
==========================================
  Hits       232709   232709              
- Misses      57593    57596       +3     
  Partials      437      437              
Files Coverage Δ
src/sentry/search/events/datasets/spans_metrics.py 88.12% <100.00%> (+0.22%) ⬆️

... and 5 files with indirect coverage changes

@edwardgou-sentry edwardgou-sentry marked this pull request as ready for review May 10, 2024 21:43
@edwardgou-sentry edwardgou-sentry requested review from a team as code owners May 10, 2024 21:43
Comment on lines +577 to +588
"countIf",
[
Column("value"),
Function(
"equals",
[
Column("metric_id"),
self.resolve_metric("span.self_time"),
],
),
],
),
Copy link
Contributor

Choose a reason for hiding this comment

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

To make this more robust, should we only count if there is a trace.status? Or can we just assume its always there?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hmm, good point. I thought about this for a bit and I think there might scenarios where we want to include spans that don't have a trace.status. For cases where we only want to count spans that have a trace.status, we should be able to just add something like has:trace.status to the discover query to achieve that affect, so I think I'm going to leave this as is for the flexibility.

@edwardgou-sentry edwardgou-sentry merged commit fe3d721 into master May 13, 2024
50 checks passed
@edwardgou-sentry edwardgou-sentry deleted the egou/feat/trace-status-rate branch May 13, 2024 22:34
@github-actions github-actions bot locked and limited conversation to collaborators May 29, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Scope: Backend Automatically applied to PRs that change backend components
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants