Closed Bug 1499761 Opened 4 years ago Closed 3 years ago

Track errors through metrics

Categories

(Toolkit :: Telemetry, defect, P3)

defect
Points:
3

Tracking

()

RESOLVED FIXED
Tracking Status
firefox64 --- affected

People

(Reporter: Dexter, Assigned: mdroettboom)

References

Details

(Whiteboard: [telemetry:mobilesdk:m5])

Attachments

(4 files)

In glean, as defined by our spec [1], errors are tracked by accumulating in special metrics handled by Telemetry.

This bug is for enabling error tracking for all the available metric types.

[1] - https://docs.google.com/document/d/186GI_2ljdqWqWTBk5P3QjHD3BwpMyd8kRayRAuz1-dk/edit#
Blocks: 1491345
Points: --- → 3
Priority: -- → P3
Whiteboard: [telemetry:mobilesdk:m4]
Assignee: nobody → mdroettboom
Assignee: mdroettboom → nobody
This is blocked by the implementation of labeled counts.
Depends on: 1516527
No longer depends on: 1516527
Depends on: 1516527
Whiteboard: [telemetry:mobilesdk:m4] → [telemetry:mobilesdk:m5]
Assignee: nobody → mdroettboom
Comment on attachment 9043682 [details]
Data review request for glean error tracking

Thanks for requesting data review - the only nits I have are to update the Github PR to reference this bug in the yaml that acts as documentation.

Also, I noticed this is a permanent data collection request - is there a field for that in the metrics.yaml? e.g. expiry: never or something like that? I think that this functionality, as measuring basic library functionality, makes sense, but I'd like to see that documented in the metrics.yaml explicitly.

data-review+ only

1) Is there or will there be **documentation** that describes the schema for the ultimate data set available publicly, complete and accurate?
Yes, documentation is part of the metrics.yaml file in the Glean SDK PR on github
https://github.com/mozilla-mobile/android-components/pull/2050/commits/c0c92490bdb554f5ecbb813def12180e8c828146#diff-d4de534816154e154c7b697e51ad8357R150

2) Is there a control mechanism that allows the user to turn the data collection on and off? 
Yes, from product data controls, which every product using Glean must have

3) If the request is for permanent data collection, is there someone who will monitor the data over time?**
This is error reporting for the metrics library, and will be permanent data collection

4) Using the **[category system of data types](https://wiki.mozilla.org/Firefox/Data_Collection)** on the Mozilla wiki, what collection type of data do the requested measurements fall under?  **
Type 1/2 - technical data for errors in reporting, but those are triggered by various user interaction

5) Is the data collection request for default-on or default-off?
Default on

6) 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, incrementing counters for errors

7) Is the data collection covered by the existing Firefox privacy notice?
Yes, can be collected under privacy policy as it is library error info and doesn't collect any PI

8) Does there need to be a check-in in the future to determine whether to renew the data? (Yes/No) (If yes, set a todo reminder or file a bug if appropriate)**
No, basic metrics for library functionality
Attachment #9043682 - Flags: review?(liuche) → review+

Also, I noticed this is a permanent data collection request - is there a field for that in the metrics.yaml? e.g. expiry: never or something like that? I think that this functionality, as measuring basic library functionality, makes sense, but I'd like to see that documented in the metrics.yaml explicitly.

We have some requirements written about metric expiration in the Glean spec here. However, I think your suggestion that we should require metrics to say that they "expire: never" is a good one, and I've filed this bug to track that.

Attached file Design proposal
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.