Remove or update probes expiring in Firefox 87: QM_QUOTA_INFO_LOAD_TIME_V0
Categories
(Core :: Storage: Quota Manager, task)
Tracking
()
Tracking | Status | |
---|---|---|
firefox86 | --- | fixed |
People
(Reporter: telemetry-probes, Assigned: tt)
References
Details
(Whiteboard: [probe-expiry-alert])
Attachments
(2 files)
48 bytes,
text/x-phabricator-request
|
Details | Review | |
2.53 KB,
text/plain
|
tdsmith
:
data-review+
|
Details |
The following Firefox probes will expire in the next major Firefox nightly release: version 87 [1].
QM_QUOTA_INFO_LOAD_TIME_V0
What to do about this:
- If one, some, or all of the metrics are no longer needed, please remove them from their definitions files (Histograms.json, Scalars.yaml, Events.yaml).
- If one, some, or all of the metrics are still required, please submit a Data Collection Review [2] and patch to extend their expiry. There is a shorter form for data collection renewal [3].
If you have any problems, please ask for help on the #data-help Slack channel or the #telemetry Matrix room at https://chat.mozilla.org/#/room/#telemetry:mozilla.org. We'll give you a hand.
Your Friendly, Neighborhood Telemetry Team
[1] https://wiki.mozilla.org/Release_Management/Calendar
[2] https://wiki.mozilla.org/Firefox/Data_Collection
[3] https://github.com/mozilla/data-review/blob/master/renewal_request.md
This is an automated message sent from probe-scraper. See https://github.com/mozilla/probe-scraper for details.
Assignee | ||
Comment 1•5 years ago
|
||
We want to either extending this or have another permanent one. Will probably update a patch tomorrow.
Assignee | ||
Comment 2•5 years ago
|
||
Assignee | ||
Comment 3•5 years ago
|
||
Updated•5 years ago
|
Assignee | ||
Comment 4•5 years ago
|
||
Comment 5•5 years ago
|
||
What about TimeStampErr1 and TimeStampErr2, does it make sense to support them, do we have any cases like that ?
Also, one thing that is a bit annoying, when I go to the dashboard, I don't see statistics like median because there are multiple keys. Is there a way to see the statistics for given key in the dashboard directly ?
Should we rather create two histograms (for Normal and WasSuspended case) ?
Comment 6•5 years ago
|
||
fwiw you can view aggregations of keyed histograms by key in Glam, which replaces the current t.m.o measurement dashboard; look for the "key" dropdown box at https://glam.telemetry.mozilla.org/firefox/probe/qm_quota_info_load_time_v0/explore?channel=beta&process=parent&ref=20201217185930.
Weirdly, the key dropdown doesn't appear for nightly -- only for beta and release; I just filed https://github.com/mozilla/glam/issues/1097.
Comment 7•5 years ago
|
||
Thanks for the info. We don't need two histograms then.
The question about timestamp errors is still open.
Comment 8•5 years ago
|
||
Comment on attachment 9194223 [details]
request-bug1683102.md
Tom, I've asserted that you intend to monitor the collection. Please also include a description of the keys (i.e. why is the collection keyed; what do collections for each of the different keys represent?) in the Histograms.json file.
- Is there or will there be documentation that describes the schema for the ultimate data set in a public, complete, and accurate way?
Yes, in the probe definition files and the Probe Dictionary.
- Is there a control mechanism that allows the user to turn the data collection on and off?
Yes, the Firefox telemetry opt-out.
- If the request is for permanent data collection, is there someone who will monitor the data over time?
Yes, Tom.
- Using the category system of data types on the Mozilla wiki, what collection type of data do the requested measurements fall under?
Category 1, technical data.
- Is the data collection request for default-on or default-off?
Default-on.
- Does the instrumentation include the addition of any new identifiers (whether anonymous or otherwise; e.g., username, random IDs, etc. See the appendix for more details)?
No.
- Is the data collection covered by the existing Firefox privacy notice?
Yes.
- Does there need to be a check-in in the future to determine whether to renew the data?
No, permanent collection.
- Does the data collection use a third-party collection tool?
No.
Assignee | ||
Comment 9•5 years ago
|
||
(In reply to Jan Varga [:janv] from comment #5)
What about TimeStampErr1 and TimeStampErr2, does it make sense to support them, do we have any cases like that ?
Yes, from the query for counting "TimeStampErr1" and "TimeStampErr2" cases in December, we got 2 cases for each of them.
Also, one thing that is a bit annoying, when I go to the dashboard, I don't see statistics like median because there are multiple keys. Is there a way to see the statistics for given key in the dashboard directly ?
I think we can still see the graph for them in "Evolution Dashboard" like: https://mzl.la/2Jfnr9i
Should we rather create two histograms (for Normal and WasSuspended case) ?
If we want to modify the telemetry, a question that comes to my mind is that do we really want to track the time for "WasSuspended"? Should we then just have one histogram for "Normal"?
We want to record "Normal" because we want to know how long it takes for loading quota info for normal cases and it can be a baseline.
We wanted to record "WasSuspended" because we were not so sure about whether that works or not.
Assignee | ||
Comment 10•5 years ago
|
||
Talked with Jan through private message and we decided to keep these keys to prove this telemetry probe work fine (e.g. the "WasSuspended" still gets data such that the logic for that works properly).
Comment 11•5 years ago
|
||
Comment 12•5 years ago
|
||
bugherder |
Description
•