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(profiles): Count processed profiles in billing metrics consumer #50047

Merged
merged 14 commits into from
Jun 5, 2023

Conversation

jjbayer
Copy link
Member

@jjbayer jjbayer commented May 31, 2023

Currently, accepted processed profiles are counted in Relay. To align processed transactions and processed profiles more consistently, we will change this by adding a tag to the transaction.duration metric (which we use for counting transactions), and defining num_processed_profiles := num_processed_transactions with profiles (see issue linked below for more information).

This PR needs to be deployed before getsentry/relay#2163 to prevent over-counting.

TODO:

  • Run end-to-end test

ref: getsentry/relay#2158

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

codecov bot commented May 31, 2023

Codecov Report

Merging #50047 (06cec21) into master (f374b2f) will increase coverage by 0.17%.
The diff coverage is 94.44%.

Additional details and impacted files
@@            Coverage Diff             @@
##           master   #50047      +/-   ##
==========================================
+ Coverage   80.93%   81.11%   +0.17%     
==========================================
  Files        4843     4843              
  Lines      203284   203296      +12     
  Branches    11253    11253              
==========================================
+ Hits       164537   164901     +364     
+ Misses      38498    38146     -352     
  Partials      249      249              
Impacted Files Coverage Δ
src/sentry/sentry_metrics/indexer/strings.py 100.00% <ø> (ø)
src/sentry/ingest/billing_metrics_consumer.py 83.13% <94.44%> (+2.85%) ⬆️

... and 47 files with indirect coverage changes


items = {DataCategory.TRANSACTION: quantity}

if bucket_payload["tags"].get(self.profile_tag) == "true":
Copy link
Member Author

Choose a reason for hiding this comment

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

@getsentry/sns does production code still need to consider the case where we index tag values for performance metrics? In that case, we would have to resolve the string "true" to an integer ID here.

I noticed that for queries, we don't even consider that case anymore (see this PR).

On the other hand, indexing tag values is still on by default:

# Flag to determine whether performance metrics indexer should index tag
# values or not
register("sentry-metrics.performance.index-tag-values", default=True)

Copy link
Contributor

@iker-barriocanal iker-barriocanal Jun 1, 2023

Choose a reason for hiding this comment

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

I may be missing context here, but why do we compare with "true"?

Just reviewing https://github.com/getsentry/relay/pull/2165/files#diff-b2075df0875b0e516d6354525c4509faef97412b6d221bbe079fa52cb8d198f3R109.

Copy link
Member

Choose a reason for hiding this comment

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

for the sake of consistency i would use resolve_tag_value like everywhere else. it might be that we want to mass-refactor this sort of code in the future, and being able to find all code that deals with query results by searching for resolve calls definitely would help there

@jjbayer jjbayer marked this pull request as ready for review May 31, 2023 14:30
@jjbayer jjbayer requested a review from a team May 31, 2023 14:30
@jjbayer jjbayer requested a review from a team as a code owner May 31, 2023 14:30
@jjbayer jjbayer requested review from a team May 31, 2023 14:35
@@ -139,6 +139,8 @@
"span.description": PREFIX + 249,
"http.status_code": PREFIX + 250,
"geo.country_code": PREFIX + 251,
# More Transactions
"has_profile": PREFIX + 300,
Copy link
Contributor

Choose a reason for hiding this comment

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

Why not +252?

Copy link
Member Author

Choose a reason for hiding this comment

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

I wanted to reserve some space for the span tags listed above, but it's probably a waste. Changed to 252 now.


items = {DataCategory.TRANSACTION: quantity}

if bucket_payload["tags"].get(self.profile_tag) == "true":
Copy link
Contributor

@iker-barriocanal iker-barriocanal Jun 1, 2023

Choose a reason for hiding this comment

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

I may be missing context here, but why do we compare with "true"?

Just reviewing https://github.com/getsentry/relay/pull/2165/files#diff-b2075df0875b0e516d6354525c4509faef97412b6d221bbe079fa52cb8d198f3R109.

@jjbayer jjbayer merged commit 22a4550 into master Jun 5, 2023
54 checks passed
@jjbayer jjbayer deleted the ref/profiles-billing-consumer branch June 5, 2023 09:08
jjbayer added a commit to getsentry/relay that referenced this pull request Jun 5, 2023
Instead of counting processed profiles in two different places (see
#2054), add a `has_profile` tag
to the transaction counter metric, and define

```
processed_profiles := count(processed_transactions) WHERE has_profile = true
```

## Changes

This PR contains the following changes:

* Revert PRs around counting profiles.
* Add `has_profile(s)` tag on `transaction.duration` metric.
#2165
* Update metrics billing consumer to emit `accepted` outcome for
profiles. getsentry/sentry#50047


## Caveats

With this PR, rate limits will be applied consistently if they are
issued for `DataCategory.Transaction`. However, if a rate limit (e.g.
spike protection) is issued _only_ for `DataCategory.Profile`, it will
not be enforced.

## Rollout Order

1. Merge and deploy getsentry/sentry#50047. The
billing metrics consumer will now listen for profiles, but not receive
any.
3. Deploy processing Relays. Profile counts will go down, because
PoP-Relays are not sending the `has_profile` tag yet.
4. Deploy PoP Relays. Profile counts should go back to normal.

## In case of rollback

1. First revert the sentry change
(getsentry/sentry#50047) and deploy it to stop
counting profiles.
2. Then revert the Relay change (this PR) and deploy to processing
Relays and PoPs.

ref: #2158

---------

Co-authored-by: Iker Barriocanal <32816711+iker-barriocanal@users.noreply.github.com>
jan-auer added a commit that referenced this pull request Jun 5, 2023
* master: (52 commits)
  feat(replays): Add dead click issue detector (#50149)
  fix(sourcemaps): Improve metrics collection (#50293)
  ref(dynamic-sampling): Implement new abstraction for models (#50227)
  Revert "feat(backpressure): Proof of concept for queue monitoring service (#49872)"
  fix(dynamic-sampling): Remove duplicated queue declaration (#50283)
  feat(backpressure): Proof of concept for queue monitoring service (#49872)
  feat: Add pages for org auth tokens (#50225)
  feat(strings): Add span.category tag (#50286)
  feat(profiles): Count processed profiles in billing metrics consumer (#50047)
  feat(strings): Add `transaction.method` tag (#50237)
  ref(txnames): Increase sample size (#50278)
  ref(framework-suggestion-modal): Sort platforms by popularity (#50235)
  ref(hc): Only set the organizationmembermapping.member_id for monolith (#49789)
  ref(hc): Region name is set for organization mappings (#50257)
  fix(alert-details): Prevent environments call from being cancelled (#50270)
  fix(post-process-group): retry retrieving events from eventstore up to 3 times (#50210)
  fix(functions): Ensure selected functions projects are returned (#50194)
  styles(functions): Handle function name overflow in suspect functions (#50251)
  feat(functions): Add tooltip to slowest functions score (#50167)
  ref(routes): Avoid named exports for routes for now (#50255)
  ...
@github-actions github-actions bot locked and limited conversation to collaborators Jun 20, 2023
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

3 participants