Closed Bug 1683102 Opened 5 years ago Closed 5 years ago

Remove or update probes expiring in Firefox 87: QM_QUOTA_INFO_LOAD_TIME_V0

Categories

(Core :: Storage: Quota Manager, task)

task

Tracking

()

RESOLVED FIXED
86 Branch
Tracking Status
firefox86 --- fixed

People

(Reporter: telemetry-probes, Assigned: tt)

References

Details

(Whiteboard: [probe-expiry-alert])

Attachments

(2 files)

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:

  1. 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).
  2. 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.

Flags: needinfo?(ttung)

We want to either extending this or have another permanent one. Will probably update a patch tomorrow.

Assignee: nobody → ttung
Status: NEW → ASSIGNED
Attached file request-bug1683102.md
Flags: needinfo?(ttung)
Attachment #9194223 - Flags: data-review?(tdsmith)

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) ?

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.

Thanks for the info. We don't need two histograms then.
The question about timestamp errors is still open.

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.

  1. 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.

  1. Is there a control mechanism that allows the user to turn the data collection on and off?

Yes, the Firefox telemetry opt-out.

  1. If the request is for permanent data collection, is there someone who will monitor the data over time?

Yes, Tom.

  1. 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.

  1. Is the data collection request for default-on or default-off?

Default-on.

  1. 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.

  1. Is the data collection covered by the existing Firefox privacy notice?

Yes.

  1. Does there need to be a check-in in the future to determine whether to renew the data?

No, permanent collection.

  1. Does the data collection use a third-party collection tool?

No.

Attachment #9194223 - Flags: data-review?(tdsmith) → data-review+

(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.

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).

Pushed by ttung@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/3c51847b3c80 Make the QM_QUOTA_INFO_LOAD_TIME permanent; r=dom-workers-and-storage-reviewers,janv
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → 86 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: