Add more meta fields to Histograms.json

RESOLVED WORKSFORME

Status

()

defect
RESOLVED WORKSFORME
5 years ago
2 years ago

People

(Reporter: rvitillo, Unassigned)

Tracking

Trunk
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

We should add some more fields to Histograms.json:

- an author field which would come in handy to associate histograms with teams; if every team had a mail alias we could use alert_emails for that purpose

- a tri-state field that tells us whether higher values of the metric are to be considered a regression or an improvement; this would be useful for our distribution change detector as of right now we can't distinguish between improvements and regressions
It would probably be interesting to know whether a distribution change was an improvement or a regression, but  in my opinion, the system should continue to alert in both cases.  Devs should find out whether a change had noticeable positive impact too - it may have been expected, or it may be a surprise (and thus an indicator of some other problem).
I agree, we definitively want to alert in both cases.
Assignee: rvitillo → nobody
Another suggestion is adding a "tags" field, which would be helpful for finding measures when you're not sure what their exact names are - this would make measures more discoverable.

A possible way to do this without any extra fields would be to allow searching through descriptions, and simply have the tags in descriptions. These would just be a convention to make search work better.

Ref:

> 17:30 <vladan> can you file a bug for the hisogram tagging idea? basically add a "tag" field to Histograms.json so you can have "tag": "perf, startup, top-priority"
> 17:31 <vladan> and then we'd want to expose the tags in the dash somehow
(In reply to Roberto Agostino Vitillo (:rvitillo) from comment #0)
> We should add some more fields to Histograms.json:
> 
> - an author field which would come in handy to associate histograms with
> teams; if every team had a mail alias we could use alert_emails for that
> purpose

alert_emails is now required and used for ownership.

> - a tri-state field that tells us whether higher values of the metric are to
> be considered a regression or an improvement; this would be useful for our
> distribution change detector as of right now we can't distinguish between
> improvements and regressions

Is this still interesting? If yes, please file a specific bug about it.

(In reply to Anthony Zhang [:azhang] (last day at Mozilla: 2016-04-29) from comment #3)
> Another suggestion is adding a "tags" field, which would be helpful for
> finding measures when you're not sure what their exact names are - this
> would make measures more discoverable.
> 
> A possible way to do this without any extra fields would be to allow
> searching through descriptions, and simply have the tags in descriptions.
> These would just be a convention to make search work better.

We experiment with discoverability & text search here:
http://georgf.github.io/fx-data-explorer/

Instead of tagging, we're trying to approach this with "categories", which allow grouping probes together for scalars and events.
This is not yet implemented for Histograms.json, but will be added at some point.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.