-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Conversation
Codecov Report
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
|
|
||
items = {DataCategory.TRANSACTION: quantity} | ||
|
||
if bucket_payload["tags"].get(self.profile_tag) == "true": |
There was a problem hiding this comment.
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:
sentry/src/sentry/options/defaults.py
Lines 578 to 580 in 92cd949
# Flag to determine whether performance metrics indexer should index tag | |
# values or not | |
register("sentry-metrics.performance.index-tag-values", default=True) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
@@ -139,6 +139,8 @@ | |||
"span.description": PREFIX + 249, | |||
"http.status_code": PREFIX + 250, | |||
"geo.country_code": PREFIX + 251, | |||
# More Transactions | |||
"has_profile": PREFIX + 300, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not +252
?
There was a problem hiding this comment.
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": |
There was a problem hiding this comment.
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.
tests/sentry/ingest/billing_metrics_consumer/test_billing_metrics_consumer_kafka.py
Outdated
Show resolved
Hide resolved
…ics_consumer_kafka.py
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>
* 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) ...
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 definingnum_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:
ref: getsentry/relay#2158