1499761 - Track errors through metrics

Status: RESOLVED FIXED

(Toolkit :: Telemetry, defect, P3)

Description

[Alessio Placitelli [:Dexter]]

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#

Comment 1

[Michael Droettboom [:mdroettboom]]

This is blocked by the implementation of labeled counts.

Comment 2

[Michael Droettboom [:mdroettboom]]

Attachment: GitHub Pull Request

Comment 3

[Michael Droettboom [:mdroettboom]]

Attachment: GitHub Pull Request

Comment 4

[Michael Droettboom [:mdroettboom]]

Attachment: Data review request for glean error tracking

Comment 5

[Chenxia Liu [:liuche]]

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

Comment 6

[Michael Droettboom [:mdroettboom]]

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.

Comment 7

[Michael Droettboom [:mdroettboom]]

Attachment: Design proposal

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/1b2e2e6c67a8
[components] 1499761: Track errors on metrics