Short summary of Thursday:

• Started looking at the work in https://gitlab.wikimedia.org/repos/wmde/wikidata-query-gui/-/merge_requests/11
  • hopeful that maybe we could use a similar method of identifying queries in JS but clearly it's not trivial
• Considered that to get metrics out of this we're very happy to see the move to prometheus but we'd still need to set up the stats/statsv equivalent endpoints for us
• Open question to check: do Wikibase Queryservice UIs actually already submit stats to query.wikidata.org accidentally?

Open question to check: do Wikibase Queryservice UIs actually already submit stats to query.wikidata.org accidentally?

From my quick checking inspecting the requests from my browser this doesn't seem to be the case.

I looked a bit more at the query service UI tracking stuff and I discovered that it only works for wikidata.org where it was recently fixed see T391532 and this specific line of code: https://gitlab.wikimedia.org/repos/wmde/wikidata-query-gui/-/blob/main/wikibase/queryService/api/TrackingFactory.js#L9

I've gone ahead and tried to ask a bit about the details on that ticket to get an idea of how that might work on either cloud or suite

Looked a small amount at wdqs-gui and came the the conclusion that if we wanted to benefit from the work upstream the lowest effort workflow collecting metrics from the UI would probably look like:

• reconcile all upstream changes (DRAFT PR doing this rebase in an unwise way) in order to benefit from:
  • new "stats" collection (now via dogstatsd and prometheus)
  • any work done on parsing queries and trying to identify types of them
• introduce new config option to enable metric collection not only on wikidata but also on wikibases with a custom "stats" endpoint
• deploy a prometheus statsd exporter for wikibase clouds to phone home to
• introduce our own query parsing and then report metrics after categorising queries into the above buckets
• deploy on wikidata and on cloud
• talk to suite about turning on this metrics collection too
  • see if they would want to by default push metrics up to WMF
  • or to a locally hosted prometheus-statsd-exporter + prometheus

@dena and I think that a great first step is to sync our fork with upstream and try and rationalise the changes. We would want to then ship this to our staging and production. This would put in place the ground work for collecting metrics using prometheus. We'll make a new ticket for this bit of work.