feat(metrics): Extract user satisfaction as tag [INGEST-589] #1197
Conversation
| let end = end.timestamp_millis(); | ||
| Some(end.saturating_sub(start) as f64) | ||
| } | ||
| _ => None, |
There was a problem hiding this comment.
Open question: Should a transaction without duration count towards satisfied users?
There was a problem hiding this comment.
If we have to choose between satisfied, tolerated, and frustrated, I say yes. However, do we know what cases cause transactions without duration count? If there are cases where SDKs aren't able to measure the duration, we may want to include an additional satisfaction value. I don't know how feasible this is though. If a transaction couldn't be measured, I don't think counting it as satisfaction provides any value. It could take a long time, and having another value could lead to users updating SDK code to correctly capture these transactions and have more valuable data.
There was a problem hiding this comment.
We do not have to choose, we can simply leave the metric untagged. So I will leave None here. This is an exceptional case anyway, because both timestamp and start_timestamp are required fields: https://develop.sentry.dev/sdk/event-payloads/transaction/.
There was a problem hiding this comment.
Now refactored so that we do an early exit when the transaction is invalid. Metrics for invalid transactions are dropped later on anyway.
|
@lynnagara, @wmak: We're trying to model user satisfaction (for Apdex and User Misery) as metrics tags here, and I want to be as consistent with the transactions-based functions as possible. Are the following assumptions correct?
Here's what I base those assumptions on:
|
| let end = end.timestamp_millis(); | ||
| Some(end.saturating_sub(start) as f64) | ||
| } | ||
| _ => None, |
There was a problem hiding this comment.
If we have to choose between satisfied, tolerated, and frustrated, I say yes. However, do we know what cases cause transactions without duration count? If there are cases where SDKs aren't able to measure the duration, we may want to include an additional satisfaction value. I don't know how feasible this is though. If a transaction couldn't be measured, I don't think counting it as satisfaction provides any value. It could take a long time, and having another value could lead to users updating SDK code to correctly capture these transactions and have more valuable data.
| }, | ||
| }); | ||
|
|
||
| // User | ||
| if let Some(user) = event.user.value() { | ||
| if let Some(user_id) = user.id.as_str() { | ||
| // TODO: If we have a transaction duration of 0 or no transaction at all, does the user count as satisfied? |
There was a problem hiding this comment.
I think transactions of duration 0 should count as satisfied. No transaction shouldn't count towards user satisfaction, that's misleading because we actually don't have data.
|
@lynnagara, @wmak: Ignore my previous question, I figured out that Relay rejects invalid transactions, so handling of special cases (missing |
* master: ref(make): Simplify M1 exports in Makefile (#1206) fix(metrics): Wait for project states during aggregator shutdown (#1205) fix(test): Find librdkafka on Apple M1 (#1204) build: Bump sentry-relay in dev dependencies to 0.8.9 (#1202) ref(metrics): Tag backdated bucket creations in statsd (#1200) feat(metrics): Extract user satisfaction as tag (#1197) fix(statsd): Add new metric_type tag to existing metrics (#1199) fix: Apply clippy 1.59 suggestions (#1198)
Use the config exposed in getsentry/sentry#32116 to extract user satisfaction tags for apdex and user misery.