Suggestions for the new unified FHR/Telemetry/Experiment ping

[Georg Fritzsche]

On 27 Jan 2015, at 10:48, Vladan Djeric <vdjeric at mozilla.com> wrote:

> I think we should try to land the client-side changes gradually. 
> 
> A rough sketch:
> Modify the server backend to accept Telemetry pings in the new JSON format (clientID, sessionID, sysinfo, env, etc). Bump version number.
> Also update the backend to parse E10S data from the Telemetry payload
> Update dashboard code
> Modify client to send Telemetry pings in the new JSON format. Rip out the obsolete "idle-daily" Telemetry ping.
> Continue submitting Telemetry saved-session ping
> Continue to upload FHR data separately
> Modify the Telemetry backend code to ignore all mid-session Telemetry pings.
> Modify Telemetry client-side to create new pings on 24-hour boundaries. Do not reset any measurements in the middle of a session. Indicate the last ping of a session explicitly. Bump version number.
> This is essentially my earlier proposal, but as a (hopefully) temporary measure.
> E10S child Telemetry code will have to be modified to create subsessions at the same time as parent
> Adapt Telemetry Experiments backend as needed
> Modify Telemetry code to create new pings on environment change. Update Experiments code as needed
> Modify backend to parse and store the new unified ping format. Stress test etc.
> All FHR backend functionality should be complete before the next step
> The FHR user-day stitching code should be finished and tested with realistic loads
> Switch FHR to use the Telemetry upload mechanism, and switch over FHR & Telemetry to the new unified ping format. Reset FHR measurements on new pings. Bump version number
> At this point, the people working on the FHR backend can stabilize and improve the backend
> After we have experience with handling the new ping semantics with FHR, we can move on to converting Telemetry in the next step
> Assuming success of step 7, write and test session stitching, extend FHR user-day stitching to Telemetry data, integrate new Telemetry subsession format with map-reduce and Spark analysis, dashboards, regression detector, etc.
> Lots of custom stitching rules, e.g. Background-Hang-Reporter data
> Change Telemetry to reset-on-new-ping semantics. Adapt existing probes. Bump version number.
> about:telemetry will be a pain to convert. It will have to do client-side stitching using saved local pings, or display the subsession separately. Both are bad
> fx-team's UITelemetry reporting will require some special attention. It's very much session-based and there are no clear rules for stitching it together from subsessions
> Identify and fix one-per-session histograms
> Document and publicize the new ping model for Telemetry probe authors
> I think this gradual approach would allows us to focus on converting one backend at a time and to use the experience gained with FHR to convert Telemetry.
> 
> What do you think?
> 
The plan on its own sounds reasonable, but i see two problems:
* The goal is to land the unification in 38. I don’t think this is realistic with this incremental approach. 
* We won’t plan on having a clear separation of the FHR data that we migrate to Telemetry (unless we would do some temporary separate implementation). E.g. some of the data is already in Telemetry.

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