Telemetry – Reboot, Firefox OS, Probe Expiration

Portland's famous food trucks

Telemetry has seen a resurgence of development of late due in large part to the reboot of the server side component. A group of us gathered in Portland last week to hack on Telemetry concepts (and code). I would like to share three updates: Telemetry project reboot, Telemetry for Firefox OS, and Telemetry probe expiration.

Telemetry project reboot

About six months ago the performance team kicked off an effort to reboot Telemetry’s server side, which went live on Oct 1, 2013. Taras described the reboot and the needs that it addresses in his post Telemetry Reboot. Mark started the week by describing the new server side architecture, which he has described in his post The Final Countdown. My key takeaways from this discussion are:

  • The solution is easily scalable.
  • The team is working to implement data processing using Amazon Web Services (AWS) spot nodes. These are the cheapest virtual machines that AWS provides and should result in a very low cost solution.
  • The generic architecture of this solution (simply a method of storing arbitrary JSON packets) should be reusable by other projects within and outside of Mozilla

Want to learn more? Initial Telemetry server side documentation is available in the telemetry-server GitHub repo.

Telemetry for Firefox OS

Firefox and Firefox OS are different enough from a technical and usage perspective that a single Telemetry client side solution does not make sense for both. Some of the issues are:

  • Telemetry must account for the Firefox OS multi-process architecture
  • Telemetry currently reports once for each Firefox session but Firefox OS usage has a different session model (users do not reboot their phones as often as they restart their browsers)
  • Mobile devices in the Firefox OS markets have limited data access for uploading Telemetry packets
  • Many of the existing probes were designed with single browser usage in mind and are not useful in an environment with multiple Web apps running without a browser container

The general consensus is that Telemetry will be useful on Firefox OS and that these issues are worth solving. Cervantes Yu has taken the reigns of implementing a JavaScript Telemetry client that will report on Mozilla applications via a Web API. His work is tracked in bug 918444.

Telemetry probe expiration

Telemetry probes are frequently added to Firefox test a specific feature or other piece of work. In many cases these probes are useful for a specific period of time after which they are no longer tracked but still collect and report on data. As it currently stands, these unused probes are rarely removed from Firefox. This poses two problems: we have unnecessary overhead in Firefox due to Telemetry collection and reporting and we are reporting information for which we have no use.

In order to address these problems, Telemetry will be updated with the capability to mark a probe as expired. To facilitate this, the Telemetry API will be updated to include a version parameter. This parameter represents the version of Firefox in which a Telemetry probe will expire (become inactive). For example, if a probe is specified with version 30, once Firefox 30 is installed, the probe will become inactive, no longer collecting or reporting data.

In order to make this change, all existing probes will be marked with version 28 (currently on Mozilla Central), which means that the probes will expire starting on March 4, 2014. Please open a bug if you require a different expiration date for a specific probe. The work to modify the Telemetry probe API is tracked in bug 742500.

Thank you to Vladan Djeric for reviewing the content of this post.


About Lawrence Mandel

Firefox program manager
This entry was posted in mozilla and tagged , , , , , . Bookmark the permalink.

2 Responses to Telemetry – Reboot, Firefox OS, Probe Expiration

  1. njn says:

    “Telemetry must account for the Firefox OS multi-process architecture”
    Firefox will soon be multi-process too!

    “all existing probes … will expire starting on March 4, 2014”
    Whoa, wait, what? That’s a terrible idea. For example, there are a bunch of memory-related probes (that mostly begin with MEMORY_) that we’ll want on for the foreseeable future. Will I really have to keep filing bugs every six weeks to keep these alive? Say it ain’t so.

    • 1. “Soon” is a relative term 🙂 but Telemetry will likely need to change to support multi-process desktop.

      2. It ain’t so. The API should support specifying any release version. For ex, you can specify Firefox 50. The Mar 4, 2014, date is a default date for all probes. If the MEMORY probes should live longer, please file a bug or comment in bug 742500. It would also be useful to understand the lifespan that you expect to be useful for the MEMORY probes. Perhaps we need to have a way to specify that a probe does not expire.

Comments are closed.