author John Schoenick <>
Wed, 07 Aug 2013 13:23:42 -0700
changeset 148423 19d4d4a860515ca0b1b62058864dcf73dd1cab0a
parent 134500 872cb5946d2f9b9232ba41df388e44564e0f619b
permissions -rw-r--r--
Bug 902375 - Actually use the optional parameter added explicitly for this purpose. r=bsmedberg, a=bajaj

Metrics Collection Framework

This directory contains generic code for collecting and persisting
metrics data for Gecko applications.


Metrics by itself doesn't do much. It simply provides a framework for
collecting data. It is up to users of this framework to hook up the
individual components into a system that makes sense for their purposes.
An example consumer of Metrics is Firefox Health Report (see

Relationship to Telemetry

Telemetry provides similar features to code in this directory. The two
may be unified in the future.

Type Overview

This directory defines a number of JavaScript *types*/*classes*:

  An entity that collects and manages data. A provider is typically
  domain-specific. e.g. AddonsProvider, SearchesProvider.

  Represents a collection of related pieces/fields of data. Instances of
  these are essentially data structure descriptors.

  Persistent SQLite-backed store for collected metrics data and state.

  High-level entity coordinating activity among several Metrics.Provider

SQLite Storage

*Metrics.Storage* provides an interface for persisting metrics data to a
SQLite database.

The storage API organizes values by fields. A field is a named member of
a Measurement that has specific type and retention characteristics. Some
example field types include:

* Last text value
* Last numeric value for a given day
* Discrete text values for a given day

See storage.jsm for more.

While SQLite is used under the hood, this implementation detail is
hidden from the consumer.

Providers and Measurements

The most important types in this framework are *Metrics.Provider* and
*Metrics.Measurement*, henceforth known as *Provider* and *Measurement*,
respectively. As you will see, these two types go hand in hand.

A Provider is an entity that *provides* data about a specific subsystem
or feature. They do this by recording data to specific Measurement
types. Both Provider and Measurement are abstract base types.

A Measurement implementation defines a name and version. More
importantly, it also defines its storage requirements and how
previously-stored values are serialized.

Storage allocation is performed by communicating with the SQLite
backend. There is a startup function that tells SQLite what fields the
measurement is recording. The storage backend then registers these in
the database. Internally, this is creating a new primary key for
individual fields so later storage operations can directly reference
these primary keys in order to retrieve data without having to perform
complicated joins.

A Provider can be thought of as a collection of Measurement
implementations. e.g. an Addons provider may consist of a measurement
for all *current* add-ons as well as a separate measurement for
historical counts of add-ons. A provider's primary role is to take
metrics data and write it to various measurements. This effectively
persists the data to SQLite.

Data is emitted from providers in either a push or pull based mechanism.
In push-based scenarios, the provider likely subscribes to external
events (e.g. observer notifications). An event of interest can occur at
any time. When it does, the provider immediately writes the event of
interest to storage or buffers it for eventual writing. In pull-based
scenarios, the provider is periodically queried and asked to populate


To use the code in this directory, import Metrics.jsm. e.g.


This exports a *Metrics* object which holds references to the main JS
types and functions provided by this feature.