Page MenuHomePhabricator

Add config override for instrumentation sampling rate
Closed, ResolvedPublic

Description

Currently the instrumentation is tied to the sampling rate of the schema in WikimediaEvents ($wgWMESchemaEditAttemptStepSamplingRate). We'd like to override it for just DiscussionTools, so we need a new config variable for the rate. This is akin to some tool-specific overrides that MobileFrontend already has in place.

Event Timeline

Change 588427 had a related patch set uploaded (by DLynch; owner: DLynch):
[mediawiki/extensions/DiscussionTools@master] Add override config for instrumentation rates

https://gerrit.wikimedia.org/r/588427

Change 588427 merged by jenkins-bot:
[mediawiki/extensions/DiscussionTools@master] Add override config for instrumentation rates

https://gerrit.wikimedia.org/r/588427

Please set sampling rate for Discussion Tools related events to 1/5

Increase Sampling Rate of DiscussionTools edits :

While doing the data QA we have observed that we are getting very few ‘discussion tools’ related events in the EditAttemptStep schema. This is possibly because the Replying V1.0 feature is deployed on 4 small wikis - nl, hu, ar, fr as an opt-in feature and the schema is sampled at 1/16 rate.
These are all the events on each wiki from Mar 31 to Apr 10.

Screen Shot 2020-04-13 at 5.06.49 PM.png (280×628 px, 23 KB)

My request is to oversample all DiscussionTools events to 1/5.

Reasoning :
Looked into Talk page edits by users in the four target wikis over the last 3 years in Superset, focusing on edits in Feb and Mar (that could continue to April and beyond).
If we consider our upper bound to be all these edits being made using DiscussionTools then we can expect around 1300 events per hour.
Sampled at 1/5th rate would mean 264 events per hour or 6350 events per day from the 4 wikis.

@Mayakp.wiki, @Ryasmeen and I were just chatting and we came to wonder: are you best positioned to QA this task considering it affects the number of events landing in the DB?

If this was a task related to events firing on the client, I assume Rummana would handle it, but this doesn't seem to be the case with this task.

Hi @ppelberg , we have not made any changes to how client side events are logged, just changed the number of events that make it to the db. Hence it should be okay for me to QA it.
In case I do not see an increase as expected in the events, we can dig further and check if there was an issue with event logging.

We also haven't actually changed the event rate yet. Train was still going out until this afternoon, so we need to get a config-change patch out via a SWAT window now that's done.

Change 589641 had a related patch set uploaded (by DLynch; owner: DLynch):
[operations/mediawiki-config@master] DiscussionTools EditAttemptStepSamplingRate increase for some wikis

https://gerrit.wikimedia.org/r/589641

Hi @ppelberg , we have not made any changes to how client side events are logged, just changed the number of events that make it to the db. Hence it should be okay for me to QA it.
In case I do not see an increase as expected in the events, we can dig further and check if there was an issue with event logging.

Understood. Thank you for confirming, @Mayakp.wiki. In this case, I will remove Editing QA from this ticket.

Change 589641 merged by jenkins-bot:
[operations/mediawiki-config@master] DiscussionTools EditAttemptStepSamplingRate increase for some wikis

https://gerrit.wikimedia.org/r/589641

Mentioned in SAL (#wikimedia-operations) [2020-04-20T18:05:03Z] <jforrester@deploy1001> Synchronized wmf-config/InitialiseSettings.php: DiscussionTools: EditAttemptStepSamplingRate increase for some wikis T250086 (duration: 01m 10s)

Confirmed in T247152, this task is good to be closed.