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

metrics(processor): emit counter for feedback screenshots #3603

Merged
merged 17 commits into from
Jun 6, 2024

Conversation

aliu39
Copy link
Member

@aliu39 aliu39 commented May 15, 2024

Follow up from #3403

A useful metric for our product team to gauge the success of user feedback screenshots, after the new release of Javascript SDK v8. Unfortunately we have no way to track this in the Sentry backend, since the two event types split into separate pipelines after Relay. The only alternative is to add a field to the msg payload, which we'd prefer not to do.

6/3 update: Bruno spoke w/SDK team and they thought it made more sense to emit the metric here. We want to monitor the num of attachments sent in the same envelope as feedback (aka user report v2).

#skip-changelog

@aliu39 aliu39 requested a review from a team as a code owner May 15, 2024 21:44
@aliu39 aliu39 requested a review from a team May 15, 2024 21:44
@aliu39 aliu39 changed the title metrics(feedback): create a counter for feedback screenshots metrics(store): create a counter for feedback screenshots May 15, 2024
Copy link
Member

@Dav1dde Dav1dde left a comment

Choose a reason for hiding this comment

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

The metric should probably live in the processor not in the store, in a feedback specific code path which has access to the entire envelope.

The information you want to be tracking here is way to high cardinality.

Note: as an informative metric adding this to Relay is fine, but building processes etc. on top is a bad idea.

CHANGELOG.md Outdated Show resolved Hide resolved
relay-server/src/services/store.rs Outdated Show resolved Hide resolved
relay-server/src/services/store.rs Outdated Show resolved Hide resolved
@aliu39
Copy link
Member Author

aliu39 commented May 16, 2024

but building processes etc. on top is a bad idea.

Wdym by this?

@Dav1dde
Copy link
Member

Dav1dde commented May 16, 2024

Informational yes, automatically including it in reports and building other processes ontop of the metric.

Copy link
Member

@jjbayer jjbayer left a comment

Choose a reason for hiding this comment

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

The only alternative is to add a field to the msg payload, which we'd prefer not to do.

  1. Why not actually?

  2. Do you want to measure this number before or after quotas are applied? If before, moving this metric to the envelope processor would make sense.

  3. It probably makes sense to also count feedback items without attachments, i.e. "measure baseline". Could be a single metric tagged by has_attachment: true/false.

relay-server/src/statsd.rs Outdated Show resolved Hide resolved
@@ -347,6 +349,10 @@ impl StoreService {
}
}

if has_feedback && !attachments.is_empty() {
metric!(counter(RelayCounters::FeedbackAttachments) += attachments.len() as i64);
Copy link
Member

Choose a reason for hiding this comment

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

What exactly do we want to count here, the number of feedback envelopes that have an attachment, or the total number of attachments? Can a single feedback envelope contain multiple screenshots?

Copy link
Member Author

@aliu39 aliu39 May 21, 2024

Choose a reason for hiding this comment

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

Thanks so much for the considerations! I'm thinking it might be better to add a metadata field to the payload instead. Will close and come back to this if not

Copy link
Member Author

@aliu39 aliu39 May 21, 2024

Choose a reason for hiding this comment

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

What exactly do we want to count here, the number of feedback envelopes that have an attachment, or the total number of attachments? Can a single feedback envelope contain multiple screenshots?

We'd just be counting the total number of attachments for now. Currently we only support 1 ss/attachment per feedback, don't expect this to change for a while

It probably makes sense to also count feedback items without attachments, i.e. "measure baseline". Could be a single metric tagged by has_attachment: true/false.

Atm we're using the event.produced counter, filter by topic, for this

Co-authored-by: Joris Bayer <joris.bayer@sentry.io>
@aliu39 aliu39 closed this May 21, 2024
@bruno-garcia bruno-garcia deleted the aliu/feedback-attachment-counter branch June 3, 2024 14:43
@bruno-garcia
Copy link
Member

Informational yes, automatically including it in reports and building other processes ontop of the metric.

What processes are we building on top of it?

For context: We'd like to monitor usage of it

@aliu39 aliu39 restored the aliu/feedback-attachment-counter branch June 3, 2024 17:13
@aliu39 aliu39 reopened this Jun 3, 2024
@aliu39 aliu39 marked this pull request as draft June 3, 2024 17:13
@@ -720,6 +723,8 @@ impl CounterMetric for RelayCounters {
#[cfg(feature = "processing")]
RelayCounters::TransactionsFromSpans => "transactions_from_spans",
RelayCounters::MissingDynamicSamplingContext => "missing_dynamic_sampling_context",
#[cfg(feature = "processing")]
RelayCounters::FeedbackAttachments => "processing.feedback_attachments",
Copy link
Member Author

Choose a reason for hiding this comment

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

open to other names

@aliu39 aliu39 requested review from Dav1dde and jjbayer June 3, 2024 22:23
@aliu39 aliu39 changed the title metrics(store): create a counter for feedback screenshots metrics(processor): emit a counter for feedback screenshots Jun 3, 2024
@aliu39 aliu39 changed the title metrics(processor): emit a counter for feedback screenshots metrics(processor): emit counter for feedback screenshots Jun 3, 2024
Copy link
Member

@jjbayer jjbayer left a comment

Choose a reason for hiding this comment

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

Looks OK to me.

@@ -420,6 +420,26 @@ pub fn has_unprintable_fields(event: &Annotated<Event>) -> bool {
}
}

//TODO: comment
//TODO: add test: all incr/no incr cases, envelope unchanged
pub fn emit_feedback_metrics(envelope: &Envelope) -> i64 {
Copy link
Member

Choose a reason for hiding this comment

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

Why does this function return the count? To make it testable?

Copy link
Member Author

Choose a reason for hiding this comment

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

Removed the return value since we're ok with no tests

relay-server/src/services/processor/event.rs Outdated Show resolved Hide resolved
@aliu39 aliu39 marked this pull request as ready for review June 4, 2024 17:21
@aliu39
Copy link
Member Author

aliu39 commented Jun 5, 2024

Not sure why this lint keeps failing. make lint && make style is successful for me locally, and I added the cfg(feature) attribute to the emit_feedback_metrics fx call. @Dav1dde @jjbayer any ideas why?

@aliu39 aliu39 requested review from jjbayer and Dav1dde June 5, 2024 19:34
@Dav1dde
Copy link
Member

Dav1dde commented Jun 6, 2024

@aliu3ntry you only made the call to the function conditional on the feature, but not the function itself (it still exists so all it references also must exist).

I pushed a commit which removes all of the conditionals, don't think this is necessary here.

@aliu39
Copy link
Member Author

aliu39 commented Jun 6, 2024

Ok - thanks!

@aliu39 aliu39 merged commit 1900e1f into master Jun 6, 2024
22 checks passed
@aliu39 aliu39 deleted the aliu/feedback-attachment-counter branch June 6, 2024 07:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants