FHR/Telemetry unification plan from Jan 28th meetin

[Vladan Djeric]

Meeting attendees: Vladan Djeric, Benjamin Smedberg, Georg Fritzsche, Mark
Reid, Roberto Vitillo, Brendan Colloran, Alessio Placitelli


   - Benjamin explained that the primary motivation behind unified pings is
   reducing latency of FHR submissions on release and beta channels, as well
   as eliminating existing data quality issues
   - We're still targeting Nightly 38 (uplift February 22) for merging FHR
   and Telemetry
   - We decided, as a temporary compromise, that Firefox will maintain two
   sets of Telemetry/FHR measurements during a session:
   - *One set* represents all the measurements gathered during the session
      (current Telemetry behavior). Only one such ping will be sent per session
      (no more idle-daily ping)
         - This session ping will be in the new, unified ping format
      - *Second set* of measurements is reset whenever a new ping is
      created because a midnight boundary is crossed (local time) or
because the
      environment has changed
         - These are the new sub-session pings
         - On the server there will be a stitching job that runs every
         morning and generates sessions & days from the subsession pings
      - The session pings are a temporary transition approach to prevent
   Mozilla losing the ability to do Telemetry analyses on the Nightly channel
   while the backend session-stitching code is being written and tested
   - Adapting about:telemetry is easy with the chosen approach. It will be
      messy when we exclusively have subsession pings
      - Note: session-stitching will be very tricky for some types of
      measurements, e.g. UITelemetry
   - We discussed recreating session pings on the client by doing
   client-side session stitching instead, but decided keeping two sets of
   measurements is simpler and the memory overhead on Nightly
   is probably acceptable
   - The Telemetry dashboard can easily be re-implemented using sub-session
   pings
      - Per-session measurements should not be reset when a new sub-session
      ping is created. The per-session measurements should *only* be
      reported in the last ping of the session
      - Most other Perf-team Telemetry dashboards can be fed from
      sub-session pings
      - We can maintain the current dashboard fed from session-pings for
      the time being
   - Mark explained the plans for the unified Telemetry/FHR server:
      - For Nightly & Aurora channels (low data volume), the server will
      store submissions from each client (clientID) in a separate file
         - This should make it straightforward to find all the subsessions
         belonging to the same session or to re-construct measurements
by calendar
         day
      - On Beta & Release, there are two options:
         1. Pick 1% of all users and store their pings per-ClientID, do the
         same for Experiments participants
         2. Track the storage locations of all pings on beta/release in a
         database and make it easy to get a list of locations by clientID

Todos:

   - *Vladan: *Estimate memory overhead of maintaining 2 sets of
   measurements in Telemetry
   - See my other message from today
   - *Mark Reid:* provide timeline for the by-ClientID server API
   - *Vladan and Georg:* figure out details of implementing the session
   ping (e.g. how to deal with mid-session environment changes in the session
   ping)
   - Open questions: how to deal with missing session fragments, session
   stitching rules by data type, FHR stitching rules, owners for the session
   and fhr-stitching rules/code
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/fhr-dev/attachments/20150128/bc25dc91/attachment.html>