Allow restricting histogram keys to a known set in Histograms.json

[Georg Fritzsche]

Considering the example, without using a keyed histogram it would end up as
multiple definitions:
"STORAGE_UPDATE_RESULT_BLOCKLISTS_ADDONS": {
  "kind": "categorical",
  "labels": ["success", "backoff", "network_error", "server_error",
"sign_error"],
  ...
},
"STORAGE_UPDATE_RESULT_BLOCKLISTS_CERTIFICATES": {
  "kind": "categorical",
  "labels": ["success", "backoff", "network_error", "server_error",
"sign_error"],
  ...
},
...

... instead of the one histogram definition below.
They all share basically the same histogram definition, but repeat it over
multiple definitions.

On Thu, Mar 2, 2017 at 3:42 PM, Frank Bertsch <fbertsch at mozilla.com> wrote:

> Georg, what did you mean by "Without using a keyed histogram, the label
> definition would be repeated over multiple histogram definitions."?
>
> On 3/2/17 08:18, Georg Fritzsche wrote:
>
> Originally we added keyed histograms to allow using string keys that were
> not all known before.
> However, we have use-cases were it makes sense to use the two-level keyed
> histogram structure (name, key), even when the set of keys is known before
> (e.g. to share common definitions).
>
> So in bug 1343855 <https://bugzilla.mozilla.org/show_bug.cgi?id=1343855>
> we plan to add an additional optional field "keys" for keyed histograms
> that allows specifying the valid key strings.
> Any recording to the histogram with an invalid key string will be ignored
> and a warning/error be print
>
> E.g. consider:
> "STORAGE_UPDATE_RESULT": {
>   "keyed": true,
>   "kind": "categorical",
>   "keys": ["blocklists.addons", "blocklists.certificates", "pinning.pins"],
>   "labels": ["success", "backoff", "network_error", "server_error",
> "sign_error"],
>   ...
> }
>
> Without using a keyed histogram, the label definition would be repeated
> over multiple histogram definitions.
>
> Feedback, concerns?
>
> Georg
>
>
> _______________________________________________
> fhr-dev mailing listfhr-dev at mozilla.orghttps://mail.mozilla.org/listinfo/fhr-dev
>
>
>
> _______________________________________________
> fhr-dev mailing list
> fhr-dev at mozilla.org
> https://mail.mozilla.org/listinfo/fhr-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/fhr-dev/attachments/20170302/af09c382/attachment-0001.html>