1206117 - Make Telemetry Histograms.json "build faster" friendly

Status: RESOLVED FIXED

(Toolkit :: Telemetry, defect, P4)

Description

[Nick Alexander :nalexander [he/him]]

Right now, Telemetry is a compiled component.  That means that "build faster" type of builds based on --disable-compile-environment -- like Fennec's |mach artificat| based build (Bug 1162191 and friends), and glandium's proposal in https://groups.google.com/d/msg/mozilla.dev.builds/GF6GjygF7ZY/v4l19USaGQAJ -- will have a hard time adding Telemetry.  That's unfortunate.

This ticket is to track making (part of) Telemetry extensible without requiring a compile environment.  I expect there to be a long history of hard performance requirements and C++ and JS accessibility that inform the current solution; I'd like to understand what it would look like to make at least part of Histograms.json run-time defined.

Comment 1

[Nick Alexander :nalexander [he/him]]

bsmedberg, gfritzsche: perhaps one of you could provide some history and explain what problems we might see if we try to make some parts of Telemetry defined at run time?  We already have support for add-on defined Telemetry probes, so perhaps this functionality already exists and just needs some in-tree build support?

glandium, gps, mfinkle, rhelmer, rnewman: just raising this as a "build faster" sub-ticket.

Comment 2

[Benjamin Smedberg]

Here are some of the complications:

* privacy reviews and documentation - we want to be able to list explicitly the data we're collecting, and have confidence that it is well-owned, expires, etc. See bug 1194287 for doc stuff.
* server components: the telemetry server uses the histogram definitions to drive the telemetry.mo dashboards.
* parsing JSON at runtime harms startup times, so we definitely don't want to do that.

It will be a fun challange to to go faster while still being able to explicitly list/document the piece sof data that we collect and drive the server-side reporting.

Comment 3

[Georg Fritzsche [:gfritzsche]]

Making new Telemetry probes available with artifact builds would have performance implications, i don't think we'll generally do that.

We are gradually working towards supporting faster builds though, by making it feasible to split up registry files (and build impact) across the tree.
Given the current work this will still take a while.

Comment 4

[Chris H-C :chutten]

bug 1425909 for scalar support, bug 1448945 for events support.