FHR & Telemetry unification: client-side and spec status

Georg Fritzsche gfritzsche at mozilla.com
Fri Jan 16 07:33:38 PST 2015


As previously discussed, we want to unify the FHR & Telemetry data to use a common system. This is going from the initial plan here:
https://docs.google.com/a/mozilla.com/document/d/1IGpzsYGi_sq3YFQDAPyKOkU_BKvXAC95fZYA2i4ceVs/

From the client-side, we are moving FHR data over to Telemetry and extend & change Telemetry so it covers our needs. This work is targeting Firefox 38.

The main bug for the client-side dependency tree is here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1122515

We are doing this in multiple phases:
* Phase 1 (bug 1040800):
  * was reduced to adding a stable client id to telemetry
* Phase 2 (bug 1069869):
  * specifications & format design and
  * the things we need to change in the common Telemetry implementation
* Phase 3 (bug 1120356):
  * remaining data migrations to have data equivalency to FHR
  * other open work that should go into Fx 38 and doesn't directly block the data migrations
* Phase 4 (bug 1122482):
  * contains work that doesn't block for Fx 38

Phase 1 is already complete.
We are now basically done with the design & specification parts of phase 2:
* Bug 1120981 - Properly specify a common Ping format
* Bug 1069880 - Redesign telemetry environment data
* Bug 1120982 - Redesign the main ping format (session ping)

We will have different ping types, e.g. "main" to cover the current telemetry data etc., "activation" to send a base set of data after installation, "upgrade", etc.
All pings will have a basic set of info (bug 1120981) and can additionally submit a stable client id and the environment (bug 1069880).
The actual data for the specific ping type will be then submitted in the payload field. For the "main" ping, we have a basic specification in bug 1120982.

So, as a simple example ping:
{
    version: 2,
    type: "main", // this has the Telemetry payload data
    ..., // some fields common to all pings
    clientId: "5768d94a-ca83-459d-9457-17ab6921b24f", // opt-in per ping type
    environment: { ... }, // opt-in, information about the session environment like app-info & HW
    payload: { ... }, // the actual ping-specific data like histograms for the "main" ping.
                            // This is mostly the current telemetry payload.
}

We identified a set of bugs that we could use help on here:
https://etherpad.mozilla.org/52byZfRPJk
These bugs don't really require changes in the core implementations. Especially the data migration bugs in phase 3 should be relatively straight-forward to do after the phase 2 bugs, re-using etc. existing implementations or adding slightly different new ones.

Georg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/fhr-dev/attachments/20150116/13275230/attachment.html>


More information about the fhr-dev mailing list